To properly diagnose this bug, we need a backtrace to see what is
happening behind the scenes. To find out how to generate a backtrace,
please read http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open".

Backtrace (running in gdb with -X) is:
(gdb) bt
#0  0x8ed44 in php_set_session_var (name=0x3364f0 "ses_login", namelen=9, 
    state_val=0x328dd0, var_hash=0xefffcfb0) at session.c:290
#1  0x8f588 in ps_srlzr_decode_php (
    val=0x339128 "ses_login|s:8:\"theodore\";ses_id|s:19:\"PMwwKgoAADwAADKfkFU\";ses_timestamp_ultimo|i:1020014634;ses_timestamp_inicio|i:1020014634;ses_ip|s:9:\"10.0.0.64\";ses_url|s:13:\"/contar.phtml\";ses_valor|i:1;", vallen=193)
    at session.c:441
#2  0x8f87c in php_session_decode (
    val=0x339128 "ses_login|s:8:\"theodore\";ses_id|s:19:\"PMwwKgoAADwAADKfkFU\";ses_timestamp_ultimo|i:1020014634;ses_timestamp_inicio|i:1020014634;ses_ip|s:9:\"10.0.0.64\";ses_url|s:13:\"/contar.phtml\";ses_valor|i:1;", vallen=193)
    at session.c:490
#3  0x93454 in zif_session_decode (ht=1, return_value=0x3360d0, this_ptr=0x0, 
    return_value_used=0) at session.c:1339
#4  0x1a2080 in execute (op_array=0x323440) at ./zend_execute.c:1598
#5  0x169e48 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at zend.c:810
#6  0x4e270 in php_execute_script (primary_file=0xeffff7f0) at main.c:1381
#7  0x17c1fc in apache_php_module_main (r=0x30a420, display_source_mode=0)
    at sapi_apache.c:90
#8  0x48b8c in send_php ()
#9  0x48bf8 in send_parsed_php ()
#10 0x1ad4e4 in ap_invoke_handler ()
#11 0x1bf494 in process_request_internal ()
#12 0x1bf4ec in ap_process_request ()
#13 0x1b7d84 in child_main ()
#14 0x1b7f38 in make_child ()
#15 0x1b8084 in startup_children ()
#16 0x1b866c in standalone_main ()
#17 0x1b8df4 in main ()

(gdb)

As an explanation to the backtrace I posted:

The backslashes that appear before some of the double quotes in the backtrace are due to gdb.  The file that is read (and the string that's processed) do _not_ contain the backslash.

The variable "ses_login" is the first of the session variables that are stored as part of the session data.

The backtrace says that it's dying in session.c, line 290.  This is in function php_set_session_var(), at the point where it's trying to call zend_set_hash_symbol().

The PHP setting "register_globals" is set to "On" in both the local and master contexts.

The script that causes this error is calling session_decode without having called any kind of session_start or session_name beforehand.

(Again, this works as I expected it to in 4.1.2; the SEGV is in 4.2.0).

I can reproduce this bug on:
Linux 2.4.7-10
Apache 1.3.24
PHP 4.2.1

.... when using session_decode to decode session data strings read from /tmp/sess_* session files.

I can also reproduce this bug:

Linux 2.4.19-pre4 SMP
Apache 1.3.24
PHP 4.2.1

Forgot to mention, I have an example script including all session data which crashes it:

http://neo.zero-gravity.org/bug16859.txt

Recompiled with --enable-debug on FreeBSD 4.5, and I'm getting  a considerably different backtrace:

(gdb) bt
#0  0x8082108 in set_default_charset_by_name (cs_name=0x818d0cc "signature",
    flags=9) at charset.c:416
#1  0x8082879 in zm_info_pcre (zend_module=0x818200c) at php_pcre.c:88
#2  0x8082a25 in pcre_get_compiled_regex (
    regex=0x818200c "signature|s:8:\"Damn\\'..\";!daheader|!daHeaderRandom|!daIndexTop|!daMenuDeviations|daTaglines|s:2:\"no\";!daNewLimit|!daNewDevs|daBuddyList|N;daBuddyStatus|s:6:\"online\";!daNewDisplay|daSortBy|s:4:\"date\";d"...,
    extra=0x81b, preg_options=0x8151044) at php_pcre.c:164
#3  0x8084c72 in preg_replace_impl (ht=1, return_value=0x818d0ac,
    this_ptr=0x0, return_value_used=0, is_callable_replace=8 '\b')
    at php_pcre.c:1009
#4  0x80fdf48 in tsrm_strndup (s=0x817f88c "\002", length=2)
    at tsrm_virtual_cwd.c:161
#5  0x80e37b8 in zif_xml_parser_set_option (ht=8, return_value=0x0,
    this_ptr=0x3, return_value_used=0) at xml.c:1519
#6  0x8061242 in php_module_startup (sf=0xbfbffc10) at main.c:971
#7  0x805f180 in main (argc=3, argv=0xbfbffc78) at cgi_main.c:649
#8  0x805e54d in acos ()

I can also reproduce a Segmentation Fault with session_decode() on:

RedHat 7.3
Apache 1.3.23
PHP 4.2.1

session_decode() consistently causes a page fault using PHP 4.2.2 on three development PCs -- two with WIN98 SE and one with WINDOWS 2000

I should have added that we are using Apache 1.3.20 and that session_decode() worked fine with PHP 4.1.2, but not with either PHP 4.2.1 or PHP 4.2.2.

Thanks.

reproduced with 4.3.0-dev

Derick

update versions.

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.