Fatal error: Exception thrown without a stack frame in Unknown on line 0
While Christer were updating his profile on one of our current projects, he suddenly got this rather cryptic message. We tossed a few ideas around, before just leaving it for the day. We came back to the issue earlier today, and I suddenly had the realization that it had to have something to do with the session handling. Changing our session handler from memcache to the regular file based cache did nothing, so then it had to be something in the code itself.
The only thing we have in our session is an object representing the currently logged in user, so it had to be something in regards to that. After a bit of debugging I found the culprit; a reference to an object which contained a reference to a PDO object. PDO objects cannot be serialized, and this exception was being thrown after the script had finished running. The session is committed to the session storage handler when the script terminates, and therefor is run out of the regular script context (and this is why you get “in Unknown on line 0″. It would be very helpful if the PHP engine had been able to provide at least the message from the exception, but that’s how it currently is.
Hopefully someone else will get an Eureka!-moment when reading this!
The solution we ended up with was to remove the references to the objects containing the unserializable structures. This was done by implementing the magic __sleep method, which returns a list of all the fields that should be kept when serializing the object (we miss the option of instead just unsetting the fields that needs to be unset and then let the object be serialized as it would have if the __sleep method wasn’t implemented). We solved this by implemeting the __sleep method and removing our references, before returning all the fields contained in the object:
-
public function __sleep()
-
{
-
$this->manager = null;
-
-
return array_keys(get_object_vars($this));
-
}
And there you have it, one solved problem!
Tags: exceptions, pdo, PHP, serializable, sessions

March 11th, 2009 at 14:35
Thanks, you’ve saved my day !
June 12th, 2009 at 19:02
In my case I resolved without implementation of the __sleep method.
At the end it was my error (in the definition of the db management block for the class HTTP_Session2), so the error was gone after the correction.
Framework: PHP 5.2.6, Pear::HTTP_Session2
July 29th, 2009 at 15:04
similar problem, solved quickly thanks to you guys
October 3rd, 2009 at 20:14
THX, Your solution saved my day :]
May 17th, 2010 at 19:39
Thanks so much! I read so much about this error in regards to exceptions in destructors/exception handlers, it didn’t even occur to me to check sessions/serialization. You saved my week!
May 21st, 2010 at 15:01
Thanks, that’s really helpful and probably saved me hours of debugging!
November 18th, 2010 at 18:11
[...] Fatal error: Exception thrown without a stack frame in Unknown on line 0 [...]
April 6th, 2011 at 21:45
OK.
This may help someone else. I did a little more research because I am unable to change the class because I am accessing the values via XML/PHP API. I knew the value coming back was an integer, so I converted the value to an integer using the intval() command. Here is what I did.
Instead of this:
$_SESSION['id'] = $xml_doc->data; //This line gave me a: Fatal error: Exception thrown without a stack frame in Unknown on line 0.
I changed it to:
$_SESSION['id'] = intval($xml_doc->data); //This corrected the problem for me.
I am just trying to help others who may have the same issue as me.
April 13th, 2011 at 15:36
The xml fatal error, was succesfully fixed with intval($xml_doc->data) function, thanks!
May 11th, 2011 at 04:07
Thank you!!! I had spent several hours on this problem, it was easy to solve using a var_dump on a suspicious object I was loading on the SESSION array.
Thank you again for posting the solution!
June 1st, 2011 at 14:55
I simply add (string) to convert my data. Example: $_SESSION[FOO] = (string)$s->Foo;
Thank you, anyway! Your explanation about the problem saved my day! =)
August 16th, 2011 at 19:57
This is just mysterious, but it helped. Thanks a million.
September 20th, 2011 at 09:30
The problem could also be a disk full problem !!!
October 7th, 2011 at 10:39
but i got this isseue due to database query.