Duplicate entry errors - lots of them

What makes you think this is for the flexifilter module? This is clearly fr the views module, as it refers to views menu entries being inserted into the {menu_router} table. Moved over to that issue queue.

Views doesn't insert data directly into menu_router, that's entirely handled by core. It shouldn't be possible for *any* module to create an error like this.

I'm pretty sure it's Flexifilter because the problem came when flexifilter was installed and goes away when flexifilter is disabled.

So, let's just say it IS Flexifilter and that it appears that it throws these errors when Views (in it's current state) is installed.

And since these Duplicate Entry Errors only happen when Flexifilter is enabled, I think it should be in the Flexifilter issues pile.

m

Oh if you are on 6.x-dev as of a day ago in flexifilter, I accidentally left a menu_rebuild() in there, which would be why you are noticing it for the first time. However this still doesn't explain the error.

@cwgordon7: Hum. This looks like a race condition introduced by your call to menu_rebuild() on every init.

menu_rebuild() is not meant to be called at very page load. The DELETE call is far before the INSERT calls, which would explain why duplicate errors pop from time to time. I'm not sure what would be the implications of moving the DELETE call from menu_rebuild() to _menu_router_build(), just before the start of the insertions.

Yes, I realize menu_rebuild is not supposed to be called on every page load. However, it should not be a problem, and I think this problem would still exist on menu_rebuild's, it's just the debug code I left in there that's making it visible.

I agree. Actually, this hilites a very serious bug; on very busy sites, this race condition is bound to happen and anything that triggers a menu rebuild could cause ugliness.

I've already discussed with chx that the delete needs to be moved; but I think this means we also need to perform a LOCK TABLE prior to the delete and don't unlock until after the insert.

Until Drupal does support transactions (and until transaction-aware MySQL installations are more common), there is no other way than to LOCK the whole table.

Here is a starter patch (only quickly tested).

I guess i got the same issue here, i dont know what happend, just discovered it this morning after a long night drupalling :|

When i select Home › Administer › Site building › Modules this error message pops up 4x:

user warning: Data too long for column 'load_functions' at row 1 query: INSERT INTO menu_router (path, load_functions, to_arg_functions, access_callback, access_arguments, page_callback, page_arguments, fit, number_parts, tab_parent, tab_root, title, title_callback, title_arguments, type, block_callback, description, position, weight, file) VALUES ('gallery/%/%/%/%', 'a:4:{i:1;a:1:{s:12:\"gallery_load\";a:2:{i:0;s:4:\"%map\";i:1;s:6:\"%index\";}}i:2;a:1:{s:12:\"gallery_load\";a:2:{i:0;s:4:\"%map\";i:1;s:6:\"%index\";}}i:3;a:1:{s:12:\"gallery_load\";a:2:{i:0;s:4:\"%map\";i:1;s:6:\"%index\";}}i:4;a:1:{s:12:\"gallery_load\";a:2:{i:0;s:4:\"%map\";i:1;s:6:\"%index\";}}}', '', 'gallery_item_access', 'a:1:{i:0;i:4;}', 'gallery_menu_album', 'a:1:{i:0;i:4;}', 16, 5, '', 'gallery/%/%/%/%', '', 't', '', 4, '', '', '', 0, '') in C:\Inetpub\wwwroot\drupal\includes\menu.inc on line 2353.

Is the 248739-race-conditions-menu-router.patch the fix for me?

it looks like this might be a duplicate of http://drupal.org/node/238760

@pwolanin

it looks like this might be a duplicate of http://drupal.org/node/238760

Yeah, it is, I'll mark it as such.

@Richhh

Is the 248739-race-conditions-menu-router.patch the fix for me?

No.

I am just wondering whether we can use a variable-based lock instead? If variable_set would tell us whether it updated or inserted then we can have something here. and currently variable_set has no return value... Just thinking aloud here.

@chx: what you will need is a semaphore. Drupal variables are not meant for that (they are cached, and thus asynchronous).

I was thinking on while (variable_set('rebuild_lock', TRUE) == VARIABLE_UPDATED) sleep(1); as a semaphore followed by a variable_del after the build. This need variable_set amed with VARIABLE_UPDATED/VARIABLE_INSERTED constants. The while loop probably needs an upper time limit (20 seconds?) when it goes ahead anyways.

variable_set used to perform a lock; does it still? And if it does, why not just use whatever system it uses to perform a lock? I'd be a little concerned about having an extra layer in there.

can we move this (duplicate) discussion to the other issue? There is already a patch there to discuss.

variable_set does NOT perform a lock.

Back to duplicate. I've cross linked from the other issue. http://drupal.org/node/238760

I've encountered the same issue as Richhh on post #9 while working on Views page /admin/build/views/edit/calendar_view_events.

My setup:
Drupal 6.4
PHP 5.2.6
MySQL 5.0.67

If you go to MySQL Query Browser Tools and check field load_function for menu_router table it shows this field is VARCHAR(255) while the data function is trying to put inside is a way longer (in my case 312 characters).
MySQL just complaints. I've changed datatype of this field to VARCHAR(360) and Drupal doesn't complain any longer.

Note:
While having the same site deployed on MySQL 4.1.22 I don't get the nasty error but on inspection of database it turned out that the load_function field is just truncated to 255 characters.

Of course I don't believe this is the right solution as it might break somewhere else.

Any ideas for proper solution?

Proper duplicate link:
#333428: Duplicate entries in menu_router table (6.x branch)

Read more:
http://drupal.org/node/238760#comment-950563
http://drupal.org/node/238760#comment-1379898

hotblack's solution works for me!

(http://drupal.org/node/246653#comment-922486)