Object of class stdClass could not be converted to int in _menu_router_build() - line 3370

Hopefully, to help narrow down the problem, I noticed that the error only occurred when the 'Smartqueue taxonomy' and 'Nodequeue generate' Module-elements were enabled. As soon as I disabled them the problem disappeared.

I was adding a new Content Type when I originally noticed the error.

Patch works for me...

I often get this when enabling/disabling modules in 7.0-rc3. So, it appears not to be just a nodeque generate or smartque issue.

Exact error: Notice: Object of class stdClass could not be converted to int in _menu_router_build() (line 3458 of /includes/menu.inc).

Marked #1026140: Receiving Error Notice after updating Token and Pathauto to 7.x-1.0-beta1 as a duplicate of this issue.

Here goes nothing...

Edit: There's another similar array_multisort in _menu_navigation_links_rebuild().

Subscribing (patch in #10 helped - thanks!)

If somebody is looking to write a test... the way to trigger this is to create a test module, implement hook_menu() and have some of the items return 'access arguments' or 'page arguments' that are of type stdClass. For example:

David Rothstein: The root cause is documented in #972536-9: Object of class stdClass could not be converted to int in _menu_router_build() - line 3370. Essentially array_multisort() keeps sorting by all dimensions of the array, and if any of the (sub)-children are objects it will complain that it cannot compare them to other types.

Exact steps to reproduce are difficult, as you have to guarantee a comparison several dimensions into $menu, however the serialized version of the variables provided in the original post do give a good indication of what is going on.

I have also been experiencing this. Since I don't really understand the solutions provided, except that they seem to offer only cosmetic solutions, and since I am not yet using nodequeue, my stopgap solution was to disable nodequeue. This seems to have stopped the error messages. But I am looking forward to a real solution...

I'm still getting this error with nodequeue.

So, this patch now takes the work from #10, and adds the test from #23 and then fixes _menu_navigation_links_rebuild() too. If this works, then it'll be a small miracle.

EDIT: If you're reading this issue then you can skip on past the testbot madness right to comment #35.

The last submitted patch, 972536-24.patch, failed testing.

#24: 972536-24.patch queued for re-testing.

It definitely passed when set to 7.x. With your permission I'd like to switch it back to 7.0 to see if #1093682: 7.0 testing doesn't work (Major version testing doesn't work, just X.x testing?) is a valid bug...

@rfay, yeah, do what you want.

#24 passes OK now with version = 7.0, although it's still testing against latest. So #1093682: 7.0 testing doesn't work (Major version testing doesn't work, just X.x testing?) was a red herring. Thanks for your support :-)

#23: 972536-23.patch queued for re-testing.

#24 seems to work for me.

subscribing.

@Jerome F please document what steps you took to reproduce the error.

subscribing, #24 works here

Add a backport tag.

#24 tested again - removes the notice for me in Drupal 7.x.dev

Patch in #49 was not applied to D7 last Dev 2011-Apr-17 and is not up to date. I updated it.

EDIT see #53 - sorry for that

Please ignore the patch in #52. I've re-uploaded the patch in #24, which is the agreed upon RTBC patch.

A side note: Are the argument parameters cached? If so, this would lead to massive performance issues with the menu cache holding potentially huge class objects (like the entire $theme cache from #9 code). Also, if these objects change latter, does the resulting code use the cached, potentially stale, object or do they reload the class instance?

So, IMHO, a primary key should be stored and the object reloaded (a wildcard loader for #9 code). And without strong arguments against, I would mark this issue as "won´t fix" and have the documentation updated.

Subscribe.

I have written a little script that tries to reproduce this to no avail. So I am uploading the test from the RTBC'd patch to see whether it fails.

So yes, the tests do capture the bug. :)

chx: See #35 for a simple way to reproduce the bug. I've attached it as a PHP script for your convenience.

@chx or pwolanin
I'm asking you too directly as you are both listed as the main maintainers and will have the best knowledge to answer these two simple questions.

Is passing in and (presumably) using cached objects via the access arguments, etc a good idea? Should this be fixed?

I.e: This could result in clogging up the cache and strange bugs due to the use of stale data.

Two real life examples for the reasons why I'm concerned with this practice.

Lightbox2 had an innocence looking array of settings stored in the cck cache, but since this was based on # content types * imagecache settings * another parameter, we soon got MySQL errors on our local AND production servers due to the excessive packet size being thrown around.

I was involved in another project that mistakenly used cached objects, and we ended up with very strange errors when the trail of the cached object was obscured and it was used where it shouldn't have been, [updated and UOW pattern kicked in and saved the changes in the background]. Only a few sales were lost, but being the jewelry industry, this amounted to a few thousand dollars worth of sales missing, leading to some headaches with the book-keepers!

bfroehle check my bug report on php.net, the error is dependent on the first array which makes me think it's a PHP bug. Ie. the second array is not always sorted.

I never read anything to say that the menu system could handle complex data structures. Similar to the field system that doesn't tell you that it can not handle primary keys that are not integers.

It's sad not to have a response about the potential side effects of this. I guess that I will have to manually check every module before installation for crappy practices. Even if performance issues are seen, due to changes in the uninstall process, does this mean that we must do manual db removal of the left over menu items in the menu tables too? (i.e: hook_menu() is not longer called to remove the menu items there). :(

I added an issue summary.

#63: 972536-63.patch queued for re-testing.

Patch needs to be adjusted for changes from #1010480: Optimize _menu_navigation_links_rebuild() in _menu_navigation_links_rebuild(); the first hunk doesn't apply.

Performance implications of this patch:

Firstly, changes are in code that is only called when doing a menu rebuild, so this doesn't effect every page load, only when rebuilding the menu cache.
We replace two calls to array_multisort to asort but we are now essentially sorting less data, so these calls should be faster, not slower.
Instead of additionally sorting the second array, we are looping over the first array to give us the iteration order of the second. This means that we've added a call to array_keys which will use more memory, and consume some CPU. I would suspect that the effect of this is minimal though. I don't think we need a benchmark here.

Ouch, that was a lot of exceptions. We'll try that again, after I've re-rolled properly.

Subscribe.

Attached a backport to Drupal 7.

The last submitted patch, drupal-menu-int-972536-83-D7.patch, failed testing.