Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Odd php error..

Credits go to BAF, bamccaig, and Matthew Leverton for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Odd php error..
Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

eventually maintenance might outweigh the benefits of keeping code now.

Won't be my problem. :P Neither I or my friend will likely have anything more to do with the people that hired him/us.

I also don't know that much php, so uh, yeah...

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Onewing
Member #6,152
August 2005
avatar

I found out about thedailywtf from a.cc. In fact, the majority of the sites I know now came as a reference from a.cc, like askaninja.com (which has apparently become really popular lately).

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

[Thu Mar 29 20:42:06 2007] [error] [client 192.168.1.20] PHP Catchable fatal error:
Object of class stdClass could not be converted to string in
var/www/.../htdocs/chat/chat.php on line 345, referer: http://.../chat

I would bet that some MySQL result is trying to be used as an array index somewhere. Something like:

$foo = mysql_foo(); // returns an object
$array[$foo] = 'boom';

It tries to call $foo->__toString() and it doesn't exist, so something bad happens. From your code, I don't see why it would happen. But my instincts say that is the problem.

It's possible that "mysql_foo()" is returning some sort of error (as an object), instead of some expected value as a string. No error detection of course, so everything goes to hell.

For example:

<?php
        $foo = (object)'Error!';
        $bar['test'.$foo] = 'Hello.'; // won't work
?>

"Catchable fatal error: Object of class stdClass could not be converted to string in foo.php on line 3"

Thomas Fjellstrom
Member #476
June 2000
avatar

I'll look into it. Though its a LOT of php code to dig thorough. All of the Moodle api, the bits of code done by the genius that coded the function above, and ADODB itself.

Is there a way to get php and ADODB to actually print out a backtrace like you get in C? I need to see the context of what was called from where. That ADODB error is absolutely useless since It makes me guess where it originated from.

Thanks

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

You could try throwing an Exception. I think that dumps out the function stack.

throw new Exception("foo");

I also wouldn't mind taking a look at it via SSH. But that offer is only valid for the next few hours while I'm waiting to get sleepy...

Thomas Fjellstrom
Member #476
June 2000
avatar

I'm not sure you want to... But ok. PM ahoyhoy.

edit:
Oh my, more problems:

[Fri Mar 30 17:32:17 2007] [error] [client 192.168.1.20] PHP Notice:
Trying to get property of non-object in /var/www/.../htdocs/chat/chat.php
on line 436, referer: http://.../chat/

here's the output from dumping $user:

object(stdClass)#213 (6) {
  ["id"]=>
  string(1) "4"
  ["isteacher"]=>
  string(1) "1"
  ["isloggedin"]=>
  string(1) "1"
  ["logindate"]=>
  string(19) "2007-03-29 20:02:49"
  ["lastactivity"]=>
  string(19) "2007-03-29 20:02:49"
  ["temporary"]=>
  NULL
}

bool(false)

And this is the line:
if (isset($user) && $user->isloggedin == "1") && (isset($user->lastactivity))) {

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

The bool(false) would probably be from a second var_dump indicating the user isn't set. I'd try this:

if (isset($user) && $user && $user->isloggedin == "1") && (isset($user->lastactivity))) {

Thomas Fjellstrom
Member #476
June 2000
avatar

Woot. That worked great, and eventually I got the stupid thing working. A nice little Ajax chat thing.

Now I'm trying to mess with the css, but the css doesn't seem to be cascading. Or somehow Firefox is caching the css even when I clear the cache and restart :o I look at the code with firebug, and nowhere does it see my modified items. Then again, konqueror won't notice them at all either :(

Of course a lot of the stuff thats not changing is all generated in javascript.. Could that be the reason? I dunno, it sees the original css fine :o

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Matthew Leverton said:

if (isset($user) && $user && $user->isloggedin == "1") && (isset($user->lastactivity))) {

The only time I've ever had a use to check if a variable was set in PHP was when I was checking for GET and POST variables from a Web page. And when I did, I avoided the ugly use of isset() and just went straight to a boolean condition:

    if($_POST['btnSubmit'])
    {
        // Do stuff
    }

Maybe there is something wrong or unreliable about doing that? It seems you had to check that anyway...

    // Why bother checking isset($user)...
    if(isset($user) && ...)

    // If you have to also evaluate just $user...
    if(... && $user && ...)

    // Might this work instead?
    if($user && (bool)$user->isloggedin && $user->lastactivity)

Thomas Fjellstrom
Member #476
June 2000
avatar

It might, but its working now, and cleaning up the code really isn't a priority. Whats left now are a few feature additions, and its out of my hands.

Thanks for the help :)

I still would like to figure out why the page is ignoring css changes, even with !important tagged on them. :(

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

// Why bother checking isset($user)...

Because it is a horrible programming practice to assume a variable exists when you don't know if it does. It triggers an E_NOTICE in PHP, which every responsible developer cares about.

Thomas Fjellstrom
Member #476
June 2000
avatar

I agree. You should see the notices I get from the Syntax Highlighting plugin for mediawiki :o

edit: Clutter in the logs is a pain.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

BAF
Member #2,981
December 2002
avatar

Quote:

edit: Clutter in the logs is a pain.

Why is php logging to your log files? And why don't you use error_reporting(E_NONE);?

Quote:

The only time I've ever had a use to check if a variable was set in PHP was when I was checking for GET and POST variables from a Web page. And when I did, I avoided the ugly use of isset() and just went straight to a boolean condition:

if($_POST['btnSubmit'])
{
// Do stuff
}

$_REQUEST works great for that. Also, as ML said, you shouldn't assume variables are set. Much better to just check if the variable isset().

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Why is php logging to your log files? And why don't you use error_reporting(E_NONE);?

Because many php coders are inexperienced at best... Using error_reporting willy nilly in their source.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

BAF said:

$_REQUEST works great for that. Also, as ML said, you shouldn't assume variables are set. Much better to just check if the variable isset().

I wasn't assuming the variables are set. I was checking them with a simple boolean condition. If the form wasn't submitted, for example, the following if statement's boolean condition would result in false and never execute:

    if($_POST['btnSubmit'])
    {
        // Do stuff...
    }

Alternatively, if the form was submitted it should result in true and execute.

That might be bad example, being that I think the submit button only transmits as POST data if the button is pressed - at least I think that is true for ASP's Response.Form() (haven't done PHP in months). Alteratively, though, you should be able to check any field that doesn't result in 0 or empty (which would result in false). For example:

    if($_POST['txtUsername'] && $_POST['pwdPassword'])
    {
        // Query User table...
    }
    else
    {
        // Handle bad login...
    }

I know about the $_REQUEST[] superglobal. The use of $_POST[] had nothing to do with what I was referring to. Besides, if your application wasn't designed to accept GET data there's really no point using $_REQUEST[].

In fact, the risk of name collisions is greater if you do use $_REQUEST[] than if you specify the transmission method.

It could also theoretically be easier to attempt malicious activity on your site if you use $_REQUEST because instead of creating a Web page (or using software) to transmit POST data to your site they can simply try appending to the query string...

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

Why is php logging to your log files? And why don't you use error_reporting(E_NONE);?

Errors, warnings, and notices are good indicators that something is going wrong. Silently ignoring them doesn't make your code magically better.

Quote:

If the form wasn't submitted, for example, the following if statement's boolean condition would result in false and never execute:

It would also trigger an E_NOTICE; thus it's a bad practice.

Thomas Fjellstrom
Member #476
June 2000
avatar

Unfortunately you get a warning if you access a array/hash index that doesn't exist. Mainly because you shouldn't be accessing undefined variables ;)

In my perl code, I specifically use the most anal warning/error mode: use warnings; use strict;
Which help cut out a lot of possible errors with using references, undefined variables, and whatnot.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Matthew Leverton said:

It would also trigger an E_NOTICE; thus it's a bad practice.

Which can be limited by only storing necessary data in session variables. On your live server you can limit error reporting to serious errors, excluding the maybes such as E_NOTICE that can occur during normal execution.

If it shouldn't be done that way then PHP shouldn't allow it. I agree it's not pretty, but then neither is isset(). Besides, what scripting language is pretty?

That's why I prefer programming in C++ to any kind of Web development. 8-)

Today I attempted to test some PHP theory and realized that PHP isn't being processed by my Apache Web server... Now I have to figure out what's wrong and how to fix it. I was sure that I had run PHP scripts on this system before... Why not anymore!? :'( To make it worse I've been drinking Canadian beer so I'm not at my best...

BAF
Member #2,981
December 2002
avatar

Quote:

I wasn't assuming the variables are set.

Quote:

    if($_POST['btnSubmit'])
    {
        // Do stuff...
    }

Looks like an assumption to me. You are assuming $_POST['btnSubmit'] is set and contains a boolean value. The proper solution here is to run it through isset. It will return true if the form was submitted, false otherwise (unless the button press was spoofed).

bamccaig
Member #7,536
July 2006
avatar

BAF said:

Looks like an assumption to me. You are assuming $_POST['btnSubmit'] is set and contains a boolean value. The proper solution here is to run it through isset. It will return true if the form was submitted, false otherwise (unless the button press was spoofed).

If $_POST['btnSubmit'] isn't set it won't execute the if block. If it is set it will, unless maybe you set the value (the label) to an empty string or 0. Feel free to try it. I wrote a shopping cart project like that and it worked fine.

In other words, I'm not assuming that $_POST['btnSubmit'] is set. I'm acknowledging that if it's not set the condition will fail. $_POST['btnSubmit'] doesn't contain a boolean. It's been a while since I've done PHP, but I believe it will contain either 'btnSubmit' or whatever the value attribute was set to ('Submit', for example)(btnSubmit was an <input type="submit" .../>).

It may or may not require the error reporting to be configured lightly forgivingly in order to avoid displaying error messages on the page. If so, it's not really a problem since the errors displayed are more like 'maybe errors' (not a problem) and for a live server you should have errors turned off anyway (users don't need to see PHP warnings/errors, and they shouldn't exist on your live system anyway, right? ::)).

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

In other words, I'm not assuming that $_POST['btnSubmit'] is set.

You are so! If it's not set, an E_NOTICE will be triggered. No one is saying that your assumption is changing the logic at all. However, your logs will be flooded with bogus E_NOTICEs, and you won't be able to spot when an E_NOTICE really is trouble. By using isset(), you avoid generating the E_NOTICE.

Quote:

users don't need to see PHP warnings/errors, and they shouldn't exist on your live system anyway, right?

You're absolutely right on the first half. Users shouldn't see the errors. The errors should go to log files.

You're partially right on the second half, but your conclusion is incorrect. Errors shouldn't occur on the live system, but if they do, you better be able to track it! By programming in such a way that all E_NOTICEs indicate problems, it's so much easier to debug problems.

Purposely writing code that triggers E_NOTICE is simply bad practice.

bamccaig
Member #7,536
July 2006
avatar

** PREPEND **

Matthew Leverton said:

You are so!

I'm not assuming that the variable is set. I'm just using a non-standard way of checking it. If only PHP was properly installed on my Web server I would write some test scripts and reply with more confidence. :-/

** END PREPEND **

Matthew Leverton said:

You're partially right on the second half, but your conclusion is incorrect. Errors shouldn't occur on the live system, but if they do...

That's what the ::) was for. Geeez, a week of [semi-]emoticon freeness and people stop interpretting them.

There are obviously gonna be errors that slip through our VIGOROUS testing processes. However, more often than not they'll be logical errors anyway and an E_NOTICE in the log probably won't point you to those.

In any case, my argument is at a loss because I agree it's better to follow good practice, which in this case would have to be using isset(). I just find it such an ugly construct. I prefer compiler errors when a variable isn't declared. You know?

Maybe if there was a block of code near the top that checked for isset()s and handled missing variables right away. At least then it would group them together... Whatever. As I've said in other threads, I'm not a fan of Web development as it is today.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Purposely writing code that triggers E_NOTICE is simply bad practice.

Oh man did I learn that with perl. Perl lets you do things in almost any way imaginable. More complex scripts can get down right confusing, even for a perl maniac, and without "use strict" strict type checking isn't enabled and all sorts of very "interesting" things are possible, like mixing undefined stuff, all types of symbol references that should almost never happen, and things along those lines.

Its the same reason I use -W -Wall with GCC, and make sure all warnings are gone. I don't need them getting in the way of finding an actual problem.

Theres a reason warnings exist, to tell you you're doing something WRONG. It may not be a fatal error by default, but its still an error, wether you like it or not.

Quote:

I just find it such an ugly construct.

# perl:
if(!defined $var) { ... }
... if !defined $var;

Which is worse do you think?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Thomas Fjellstrom said:

Which is worse do you think?

I'd say they're about the same, but I might actually prefer the defined/!defined syntax. Maybe not. Scripting languages are just evil to begin with. :P

** APPEND **

I can honestly say that in my little PHP writing that I've done I've never relied on a log to tell me where my errors are. I plan my script and test it extensively to be sure it's working as I intended.

What are some examples of hard to notice logic errors that will trigger E_NOTICEs?

BAF
Member #2,981
December 2002
avatar

Quote:

I'm not assuming that the variable is set. I'm just using a non-standard way of checking it. If only PHP was properly installed on my Web server I would write some test scripts and reply with more confidence. :-/

So you're telling me that I can do the following in C++ to see if a variable exists:

if(myMagicBitmap)
{
    oh it exists!
}

I think not. You ARE assuming it exists. You explicitly reference it.

 1   2   3 


Go to: