Does it crash on the 1st page of gallery (index.php) or later?  If later, what's
the URL previous the crash and what button/link do you press?

Could you make your gallery version available for download so I can try to
replicate too?

Thanks

A "backtrace full" with php-debuginfo and httpd-debuginfo installed would be
useful.  Do

echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/coredump.conf

and restart the server and you'll get cores in /tmp, which is easier to deal with.

Created attachment 114286 [details]
gdb session

"backtrace full" stopped after the first frame for some reason.  Anyway, here
the locals from each frame.

Core file is:

 http://cyberelk.net/tim/tmp/core.18737

I'll look at making a test case available.  It's not the first page on gallery,
but is only one click away (click on an album).  It's an older version of
gallery, though, and I may well have altered it since release.

Here is a test case:

 http://cyberelk.net/tim/tmp/phpsegv.tar.bz2

mkdir /tmp/var-www
cd /tmp/var-www
tar jxf ~/phpsegv.tar.bz2
mount --bind /tmp/var-www /var/www/html
mozilla http://localhost/phpsegv

If it doesn't happen the first time, try again, or click on the 'login' link.

I'm seeing 
[notice] child pid 15204 exit signal Segmentation fault (11)
when calling session_ungerister() from php
and the file in /var/lib/php/session created is of 0 bytes

For the record: happens on i386 too.

I recompiled php with "optflags: i386 -g" and found that php_add_session_var was
getting called with *ps_globals.http_session_vars.value corrupted.  I ran gdb
against a running httpd and set a hardware watchpoint and found this:

Breakpoint 1, php_add_session_var (
    name=0xa10d78c "gallery_session_d1484fb089b961bc3938efd0679de2ad",
    namelen=48) at /usr/src/redhat/BUILD/php-5.0.4/ext/session/session.c:267
267             zval **sym_track = NULL;
(gdb) watch (*ps_globals.http_session_vars).value
Hardware watchpoint 2: (*ps_globals.http_session_vars).value
(gdb) c
Continuing.
Hardware watchpoint 2: (*ps_globals.http_session_vars).value

Old value =
    {lval = 166148036, dval = 2.204083827676867e-314, str = {val = 0x9e737c4
"\b", len = 1}, ht = 0x9e737c4, obj = {handle = 166148036, handlers = 0x1}}
New value =
    {lval = 0, dval = 2.1219957909652723e-314, str = {val = 0x0, len = 1}, ht =
0x0, obj = {handle = 0, handlers = 0x1}}
0x010fb7aa in zend_do_fcall_common_helper (execute_data=0xbfaf6728,
    opline=0xa10a69c, op_array=0xa09a79c)
    at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_execute.c:2710
2710                    INIT_ZVAL(*(EX_T(opline->result.u.var).var.ptr));
(gdb) c
Continuing.
Hardware watchpoint 2: (*ps_globals.http_session_vars).value

Old value =
    {lval = 0, dval = 2.1219957909652723e-314, str = {val = 0x0, len = 1}, ht =
0x0, obj = {handle = 0, handlers = 0x1}}
New value =
    {lval = 0, dval = 0, str = {val = 0x0, len = 0}, ht = 0x0, obj = {handle =
0, handlers = 0x0}}
0x010fb7ab in zend_do_fcall_common_helper (execute_data=0xbfaf6728,
    opline=0xa10a69c, op_array=0xa09a79c)
    at /usr/src/redhat/BUILD/php-5.0.4/Zend/zend_execute.c:2710
2710                    INIT_ZVAL(*(EX_T(opline->result.u.var).var.ptr));
(gdb)
Continuing.
Hardware watchpoint 2: (*ps_globals.http_session_vars).value

Old value =
    {lval = 0, dval = 0, str = {val = 0x0, len = 0}, ht = 0x0, obj = {handle =
0, handlers = 0x0}}
New value =
    {lval = 0, dval = 6.7903865310888714e-313, str = {val = 0x0, len = 32}, ht =
0x0, obj = {handle = 0, handlers = 0x20}}
0x0103884f in php_if_md5 (ht=1, return_value=0xa10886c, this_ptr=0x0,
    return_value_used=1)
    at /usr/src/redhat/BUILD/php-5.0.4/ext/standard/md5.c:66
66                      RETVAL_STRING(md5str, 1);

So php_if_md5() is getting called with return_value=0xa10886c.  But
ps_globals.http_session_vars==0xa10886c.

This seems to correspond to the PHP fragment:

if (is_array($_SESSION) && !empty($_SESSION)) {
        foreach($_SESSION as $key => $value) {
                $$key =& $_SESSION[$key];
        }
}

Does that shed any more light on this?

bug 160480 is another crash in the session hash manipulation.

That fragment of code is indeed key.  It's a refcounting issue: when that
foreach loop ends, the refcount of the http_session_vars hash table is
prematurely dropped to zero and so the memory gets reused.

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Doesn't seem to segfault now (but the original php script fails).