One of our customers signaled a problem when we upgraded from PHP 5.3.1 to 5.3.2 : he was no longer able to login to his Gallery2 installation (running version 2.3.1).
After some checks we found out that browsing to a different page (image, etc) before logging in allowed to login and returns to the image. Clicking the admin link again requires another login ("the admin session has timed out"), but finally allows access to the admin interface.
We have rollbacked to PHP 5.3.1 for now.
We are also experiencing this severe issue in PHP 5.3.2. Gallery2 is not useable in this state. Please fix this issue ASAP.
Rollback to PHP version 5.3.1 is definitely not an option for us because of significant security flaws in that version.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I have this problem, too! Direct Login starts download of an empty PHP file since PHP 5.3.2. My current workaround is a note to users that explains how to click to be able to log in. Please provide a fix!
Last edit: Anonymous 2014-03-23
gdb back-trace of the crash, reproduced using php-cli:
# Details: (gdb) bt
#0 zval_mark_grey (pz=<value optimized out>) at /usr/src/debug/php-5.3.2/Zend/zend_gc.c:360
#1 0x00000000005be8e5 in gc_mark_roots () at /usr/src/debug/php-5.3.2/Zend/zend_gc.c:417
#2 gc_collect_cycles () at /usr/src/debug/php-5.3.2/Zend/zend_gc.c:628
#3 0x00000000005a1bc5 in zend_deactivate () at /usr/src/debug/php-5.3.2/Zend/zend.c:900
#4 0x00000000005500d5 in php_request_shutdown (dummy=<value optimized out>) at /usr/src/debug/php-5.3.2/main/main.c:1633
#5 0x0000000000629ba4 in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/src/debug/php-5.3.2/sapi/cli/php_cli.c:1373
Here's two PHP bugs entries that are related to this:
http://bugs.php.net/50382
http://bugs.php.net/50519
Sadly, a fix for #50519 is included in PHP 5.3.2, and so this shouldn't happen in 5.3.2 or later. But it does happen; my gdb backtrace shows I'm using php-5.3.2.
The workaround given in #50382 works for me:
Add to .htaccess: php_value zend.enable_gc off
Another hack that prevents the crash is to add a
exit();
at the end of main.php, just before the line with ?>
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
In my case, the workaround as pointed out by mouton_io does not work. The problem seems to be somewhere else.
The crash occurs just after the redirect to: https://server/mediadb/main.php?&g2_GALLERYSID=c2da2c59ae632951370cfb688eee4c32
Apache log reads: [Thu Apr 08 02:17:03 2010] [notice] child pid 22988 exit signal Segmentation fault (11)
I let apache write a core dump and analyzed it with gdb:
(gdb) bt
#0 0x043c97e0 in zend_hash_find () from /etc/httpd/modules/libphp5.so
#1 0x044376fe in ?? () from /etc/httpd/modules/libphp5.so
#2 0x043e241a in execute () from /etc/httpd/modules/libphp5.so
#3 0x043bc47d in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#4 0x04365cc8 in php_execute_script () from /etc/httpd/modules/libphp5.so
#5 0x04448790 in ?? () from /etc/httpd/modules/libphp5.so
#6 0x00a95a4d in ap_run_handler () from /usr/sbin/httpd
#7 0x00a993f8 in ap_invoke_handler () from /usr/sbin/httpd
#8 0x00aa550e in ap_process_request () from /usr/sbin/httpd
#9 0x00aa22af in ?? () from /usr/sbin/httpd
#10 0x00a9d92d in ap_run_process_connection () from /usr/sbin/httpd
#11 0x00a9da2c in ap_process_connection () from /usr/sbin/httpd
#12 0x00aa9eb4 in ?? () from /usr/sbin/httpd
#13 0x00aaa1c1 in ?? () from /usr/sbin/httpd
#14 0x00aaa29a in ?? () from /usr/sbin/httpd
#15 0x00aaadfb in ap_mpm_run () from /usr/sbin/httpd
#16 0x00a81157 in main () from /usr/sbin/httpd
Another core dump produced this backtrace:
(gdb) bt
#0 0x02abb076 in _zval_copy_ctor_func () from /etc/httpd/modules/libphp5.so
#1 0x02af1e98 in ?? () from /etc/httpd/modules/libphp5.so
#2 0x02ae141a in execute () from /etc/httpd/modules/libphp5.so
#3 0x02abb47d in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#4 0x02a64cc8 in php_execute_script () from /etc/httpd/modules/libphp5.so
#5 0x02b47790 in ?? () from /etc/httpd/modules/libphp5.so
#6 0x00af9a4d in ap_run_handler () from /usr/sbin/httpd
#7 0x00afd3f8 in ap_invoke_handler () from /usr/sbin/httpd
#8 0x00b0950e in ap_process_request () from /usr/sbin/httpd
#9 0x00b062af in ?? () from /usr/sbin/httpd
#10 0x00b0192d in ap_run_process_connection () from /usr/sbin/httpd
#11 0x00b01a2c in ap_process_connection () from /usr/sbin/httpd
#12 0x00b0deb4 in ?? () from /usr/sbin/httpd
#13 0x00b0e1c1 in ?? () from /usr/sbin/httpd
#14 0x00b0e29a in ?? () from /usr/sbin/httpd
#15 0x00b0edfb in ap_mpm_run () from /usr/sbin/httpd
#16 0x00ae5157 in main () from /usr/sbin/httpd
Don't know how to go on from here!
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
My issue was related to the other bug described here:
http://gallery.menalto.com/node/95444#comment-340983
The provided workaround (using 'mysql' instead of 'mysqli' did work for me.
Shouldn't we file a seperate bug report for that? How can I help you to hunt that bug down?
Matt: Yes, you should probably open a new issue in the sf tracker for your GalleryStorageExtras problem.
Mention the error you had, the var_dump you added (what, where), the result you got with it, and the result of the grep command I posted in the thread you mention. You should also include the work-around you used to fix, in case other are looking for a solution and find your issue.
Problem now reported as http://bugs.php.net/bug.php?id=51624 via Ubuntu. Dev suggests trying http://snaps.php.net/php5.3-latest.tar.gz.
I had the same version of Gallery and the same 500 error. Although it was not on my own server so I didn't have access to the server logs...
There is a space (!) at the end of line 1276 which is the problem. When I removed the space everything worked like before.......
For me this is not a Gallery problem but a php problem but it's very easy to solve in Gallery.
Rgds, BvdB