if you filter by php errors on d.o right now, there are a bunch of errors from user.module:

http://drupal.org/admin/logs/event/16408814

array_keys() [<a href='function.array-keys'>function.array-keys</a>]: The first argument should be an array in /var/www/drupal.org/htdocs/modules/user/user.module on line 361.

which causes:

http://drupal.org/admin/logs/event/16408815

implode() [<a href='function.implode'>function.implode</a>]: Bad arguments. in /var/www/drupal.org/htdocs/modules/user/user.module on line 361.

which leads to:

http://drupal.org/admin/logs/event/16408816

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 &#039;)&#039; at line 1 query: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /var/www/drupal.org/htdocs/includes/database.mysql.inc on line 172.

user.module is running with local modifications (the {user_access} split patch), but it's not clear if that's the source of the errors. this particular line of user.module appears to be unmodified. however, it wasn't changed for the 5.1 release, either. i don't have time to investigate more closely, but i figured i should post it here for others to look into and hopefully resolve. i sure hope this isn't a bug in 5.1 itself.

CommentFileSizeAuthor
#9 114074_user_session_fix.patch.txt729 bytesdww

Comments

incom’s picture

incom commented

I am using 5.1 and get the following error 

    * warning: array_keys() [function.array-keys]: The first argument should be an array in /home/incom123/public_html/website/modules/user/user.module on line 361.

    * warning: implode() [function.implode]: Bad arguments. in /home/incom123/public_html/website/modules/user/user.module on line 361.

    * user warning: 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 ')' at line 1 query: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/incom123/public_html/website/includes/database.mysql.inc on line 172.

I removed all contributed modules - error disappear - when enabling bio module, it appears - not tested with other modules -

Anonymous’s picture

Anonymous (not verified) commented

Hi,

I posted a Bug report on 22.01.2007 (http://drupal.org/node/111754) with the same error message. I've got also the problem now with 5.1...

I tried to deactive some modules but i didn't find the error. My Drupal isn't modified...

cu tb.

flanderz’s picture

flanderz commented

Experiencing this problem with the comment module as well. (Drupal 5.1)

BioALIEN’s picture

BioALIEN commented

Just came across this error also. My scenario is somewhat strange though. I tried to login to another Drupal powered website using my Drupal ID and despite the successful login, I was presented with this error.

Southpaw’s picture

Southpaw commented

I also have this error, but only on the Comment > Settings page.

Drupal 5.1

rHOnDO’s picture

rHOnDO commented

I'm getting this error with a default install of 5.1 (PHP 5.2.1 MySQL 5.0.27)

dww’s picture

dww
we/he/they
commented
Title: php errors from user.module on d.o » php errors from user.module
Project: Drupal.org infrastructure » Drupal core
Version: » 5.x-dev
Component: Other » user.module

ok, this is clearly not specific to d.o, but apparently a bug in core itself. moving to the more appropriate issue queue.

rHOnDO’s picture

rHOnDO commented

This was solved for me using the code from this post:

http://drupal.org/node/121679#comment-203549

Thanks ravx.

- at file /includes/bootstrap.inc after line

case DRUPAL_BOOTSTRAP_SESSION:

insert this code

if ( session_id() ) {
    session_write_close();
}
dww’s picture

dww
we/he/they
commented
Title: php errors from user.module » session.auto_start = 1 can create session hell and php errors
Component: user.module » user system
Status: Active » Needs review
StatusFileSize
new 114074_user_session_fix.patch.txt729 bytes

ok, very interesting. after reading http://drupal.org/node/20397 and http://drupal.org/node/6696 in some detail, it looks like our previous session-related fixes for calling 'session_write_close' at the right time are failing for sites with session.auto_start = 1 in some cases. so, right when we're first bootstrapping the session, if there's already a session open, we need to close it. otherwise, all sorts of bad things befall us. forcing php into session.auto_start == 0 mode might be a greater evil than this work-around for cases where it's set to 1. of course, this is critical-path bootstrap.inc time, so i suppose every new if clause counts. however, i'll take correctness over performance any day. ;)

p.s. same patch applies with offset to D6, but i'm leaving this as a D5 bug for now, since that's where it's easily and frequently confirmed, and also since that's what d.o is still running.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Needs review » Needs work

session.auto_start is PHP_INI_ALL, so we can set it in settings.php with similar variables.

If we can not for some reason, then we just need some comments in that code.

dww’s picture

dww
we/he/they
commented

Ahh, interesting. So, we rely on .htaccess to set php_value session.auto_start 0. However, not all hosts use apache and .htaccess, so I bet this is a big nasty problem on non-apache sites, where we're just not setting auto_start 0 at all. :(

Sadly, the CVS history on this point is pretty spotty:

revision 1.61
date: 2005-02-18 18:44:33 +0000;  author: dries;  state: Exp;  lines: +3 -6;
- Patch #17303 by tangent: moved the session settings into /sites/default/settings.php
 so that subsites can have better control over them. One of the advantages
 of the site specific settings.php file is that it will never get overwritten during
upgrades and having these settings here should prove to be more friendly.

followed by:

revision 1.64
date: 2005-03-12 10:42:48 +0000;  author: dries;  state: Exp;  lines: +31 -31;
- Patch #18641 by Morbus: .htaccess improvements.  Modified a bit by me.

and finally:

revision 1.65
date: 2005-03-15 21:07:49 +0000;  author: dries;  state: Exp;  lines: +10 -14;
- More improvements by Morbus, Goba, TDobes et al:
...
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
...

Sadly, revision 1.65 has no issue nid, so there's no telling where "Per Goba's comments" can be found. There's no mention in http://drupal.org/node/18641 nor http://drupal.org/node/17303. :( All I could find was http://drupal.org/node/17303#comment-317527 but that doesn't deal with auto_start.

Seems like we need Gabor to come back here and try to remember why it's the way it is. However, IMHO, we really should be declaring these PHP settings in settings.php where they'll work on all configurations, not just apache, especially for things as critical as session.auto_start.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Oh, the feedback is that it is pointless to set session auto starting in settings.php, as by the time PHP reaches running settings.php code, it already started the session or not, depending on that setting. The point of the auto start setting is to start the session before any PHP code is run. So while PHP code already runs, there is no point fiddling with that setting.

dww’s picture

dww
we/he/they
commented

@Gabor: Ahh, right. ;) Makes sense.

Yucky problem, though. :( Now what? I'd hate to think my patch above is really the best approach -- it's certainly cruft in a very performance-critical code path just to handle non-Apache configs. But, if we have to define auto_start in .htaccess for it to work, and not everyone's got .htaccess, I'm not sure what else we can do to avoid the bugs.

@drumm: given all this info, where do you think a code comment is needed? A comment next to my evil if() clause in the patch? A comment in settings.php that you can't put auto_start there? Both?

Thanks, all.

Aleet’s picture

Aleet commented

Is this issue still being worked on? The patch didn't work for me. I'm getting this error:

* warning: array_keys() [function.array-keys]: The first argument should be an array in /home/ihea/public_html/multicultural_health_education/modules/user/user.module on line 361.
* warning: implode() [function.implode]: Bad arguments. in /home/ihea/public_html/multicultural_health_education/modules/user/user.module on line 361.
* user warning: 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 ')' at line 1 query: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/ihea/public_html/multicultural_health_education/includes/database.mysql.inc on line 172.

Running 5.1.

diego.banchero’s picture

diego.banchero commented
Version: 5.x-dev » 6.19
Status: Needs work » Needs review

I found the same problem with latest drupal.

I used this workaround:

- in settings.php
- put session_destroy(); before ini_set(..) section.

This seems to work.

thedavidmeister’s picture

thedavidmeister commented
Status: Needs review » Needs work

Unfortunately the patch in #9 is not for D6, there's no patch in #15 and nobody has confirmed/denied whether this is an issue in the latest version of Drupal (8).

Setting to needs work.

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.