Query log displays dreaded Fatal error: Exception thrown without a stack frame in Unknown on line 0 on Views pages

Issue confirmed. I experienced the same thing just now, but wasn't seeing this fatal error two days ago.

Still happenning with HEAD? I can't reproduce it.

I just did a clean install of D7 HEAD this morning to fix another devel bug, and didn't notice this error. I surely would have noticed a Fatal Error, cause devel was the only non-core module I enabled post-installation.

We're good on this one. No longer reproducible, I say.

Moshe,

I started to get this same error after installing Devel module.

I'm developing Web Services module for D7 and i was trying to use AHAH functionality. Even with very basic AHAH/AJAX implementation was giving me these errors. Its probably new info for you. Also, i enabled some Devel settings, like showing memory consumption...

regards,

massa

Moshe,

I placed a bug description that is not related to the error message. Well, Devel do inject information into the output in a way that is not AJAX/WebServices friendly, but I will open another issue for it.

The problem that appears the Fatal error: Exception thrown without a stack frame in Unknown on line 0 is when Performance Logging module is enabled. Testing AHAH shows this message.

regards,

massa

Moving to performance logging module. I've not seen this though, can you provide steps to reproduce?

I installed today's HEAD and today's devel and enabled performance, enabled detail and summary database logging and it is working fine.

So, this seems specific to the environment of the original reporter.

I didn't have this probleme either but it just appeared after the DBTNG patch committed earlier today. It happens when detailed logging is enabled and the insertion fails in performance_log_details().

In my case the query was failing because the schema did not match the query (my fault: half-applied ms patch), but in the more general case, it is probably because having an unhandled exception in a PHP exit handler is not supported.

Causing the error to reappear voluntarily, I could make it disappear with this:

  try {
  db_insert('performance_detail')
    ->fields($fields)
    ->execute();
  } catch (Exception $e) {
    echo $e->getMessage();
  }

...which displays a proper exception message. However, this probably needs something cleaner/more general.

I'm getting this message with the latest code on all Views pages if I try to display the query log.

To expand my earlier message, which was a little unclear, that is one place this error shows up. I imagine there is a Views bug that is causing the problem, but the message is pretty unhelpful.

I just tried using the current HEAD of core and the current HEAD of devel, did a fresh install of D7, enabled the performance module, enabled detailed and summary logging, and then created an article and then browsed.

I don't see an error at all doing this. Mind you, no views, ...etc. just core.

So can't reproduce it.

You can see it if you install views and try to turn on query logging (latest HEAD of core, Devel, and Views). It shows up on every views page. That's the only place I am seeing it now and that's how you can reproduce it. As I said, I'm sure the underlying problem is some kind of bug in Views, but we're not getting a very helpful error message.

Are you sure you are using views from HEAD? That version says it is not compatible with Drupal 7.x. Or is it under another tag in CVS?

The 7.3 version of Views. I thought that was HEAD, I guess it was branched, http://drupal.org/node/608852. But anyway, I have the right, latest, version of Views. I have been debugging various Views issues.

Reading up I see referenced to using the performance module. In my case I'm just trying to display the query log at the bottom of the page, and I get that error message on every page.

Fatal error: Exception thrown without a stack frame in Unknown on line 0 

I can't see any errors originating from the performance.module so far.

If I install Views 7.3, then enable the frontpage view, it works fine. No errors. If I go to comments/recent, I get an error originating from views.

Here it is:

Debug: 'Exception: SQLSTATE[42000]: Syntax error or access violation: 1064
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near
\'***CURRENT_USER*** AND ***CURRENT_USER*** <> 0) OR ***ADMINISTER_NODES*** = 1 = \'
at line 2' in views_plugin_query_default->execute() (line 1134 of ../modules/views/plugins/views_plugin_query_default.inc).

This error appears even of performance.module is disabled.

Please advice exact steps to reproduce after views and performance are installed.

My error message is not from the performance module, it is from trying to display the query log. I set up the devel settings to display the query log and I get that error at the bottom of every view.

- Install Views.
- Enable the frontpage view.
- Go to Devel configuration and check the box to 'Display the query log'.
- Go to the view and the error is at the bottom of the page where the query log should be.

Ah ... finally!

That is the wrong component then ... It is devel proper, not performance.

Moshe, back to you ...

Goose chase ...

Sorry about the confusion! I probably wasn't clear enough.

Just confirming KarenS's bug report. Re-titling. #19 has steps to reproduce.

I did some crude debugging, which was to surround:

      $queries = Database::getLog('devel', 'default');
      $output .= devel_shutdown_summary($queries);
      $output .= devel_shutdown_query($queries);

in a try/catch block, as per http://www.drupal4hu.com/node/222 (which should really be on drupal.org somewhere, mutter mutter...)

The actual error is:

You cannot serialize or unserialize PDO instances file: /Users/webchick/Sites/drupal-7.x-dev/sites/all/modules/devel/devel.module on line 959

This is referring to this code:

  // Save queries as a serialized array.
  file_put_contents($path, serialize($queries))

I thought what might be happening is one of the queries views is passing in is a PDO object instead of a string. But putting this at the top of devel_query_put_contents():

foreach ($queries as $query) {
  if (gettype($query['query']) != 'string') {
  var_dump($query['query']);
  }
}

... no results return. Hrm.

If you use drupal_register_shutdown_function then _drupal_shutdown_function will fire the callback wrapped in try-catch. Does devel use it? If yes, how come...? Every time I see this error I wonder, do we have a core bug?

@webchick. nice debugging. i can't reproduce this though. do i need any special modules or config?

@chx - I am using drupal_register_shutdown_function() to register a shutdown callback for devel. But in that callback, I simply call register_shutdown_function() again in order to assure that I am called at rthe very end of all shutdown functions. This is my way of ensuring that ALL queries get shown on the query log. SO yu can see now why I lose the try/catch protection you speak of. Guess I should try to copy that code.

er, i should really read before speaking. once needs to run Views to see the error. bah - maybe someone else can figure out the problem. i'm on Views hiatus.

it occurs to me that devel casts the PDO object to a string in order to convert the mega array to a SQL string. If Views is not using DBTNG objects, it needs to implement a __to_string method like DBTNG

This is not the case. Views uses DBTNG

It seems to be a problem for EntityFieldQuery, too: #903746: EntityFieldQuery breaks the query logger

I just found http://e-mats.org/2008/07/fatal-error-exception-thrown-without-a-stack-f...

So you cannot serialize an object with a reference to a PDO object which is the case for both EntityFieldQuery and Views

Hm. So does this then become an issue for any time we use a query object that is saved as a property in another object? The saving object is on the stack and gets tracked by the backtrace, which in turn has a reference to the query object, which in turn references the connection object.

Crazy thought: I wonder if putting a __toString() on DatabaseConnection itself would work.

Committed - I fixed this by switching from serialize() to json_encode(). I have no idea how json_encode represents the recursion but it does not matter for our purposes.

i have copy paste a drupal site at my local machine when i want to run that site showing this error message "Fatal error: Exception thrown without a stack frame in Unknown on line 0"

#31 possibly related to #2267407: Error suppression on json_encode() causes silent fail (no query log, no error message) when there is a memory error

adding a missing try/catch statement would allow you to see the real error...