Just tried lastest SNAP (200112131200), here's the backtrace:
Starting program: /usr/local/apache/intranet/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x814abff in zend_hash_get_current_key_ex (ht=0x829e664, str_index=0xbfbff5c8, str_length=0xbfbff5c4, num_index=0xbfbff5c0, 
    duplicate=0 '\000', pos=0xbfbff5bc) at zend_hash.c:1035
1035                    if (p->nKeyLength) {
(gdb) bt
#0  0x814abff in zend_hash_get_current_key_ex (ht=0x829e664, str_index=0xbfbff5c8, str_length=0xbfbff5c4, num_index=0xbfbff5c0, 
    duplicate=0 '\000', pos=0xbfbff5bc) at zend_hash.c:1035
#1  0x80bd7ea in php_session_save_current_state () at session.c:575
#2  0x80c0114 in php_session_flush () at session.c:1447
#3  0x80c0149 in zm_deactivate_session (type=1, module_number=12) at session.c:1464
#4  0x8147457 in module_registry_cleanup (module=0x8267180) at zend_API.c:1165
#5  0x8149f23 in zend_hash_apply (ht=0x821f580, apply_func=0x8147418 <module_registry_cleanup>) at zend_hash.c:669
#6  0x8144115 in zend_deactivate_modules () at zend.c:581
#7  0x808ba68 in php_request_shutdown (dummy=0x0) at main.c:724
#8  0x8150475 in apache_php_module_main (r=0x8284034, display_source_mode=0) at sapi_apache.c:96
#9  0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 "/home/www/intranet/htdocs/test.php")
    at mod_php4.c:575
#10 0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590
#11 0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517
#12 0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307
#13 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323
#14 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209
#15 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008284307) at http_main.c:4313
#16 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395
#17 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683
#18 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010


My configure line is:

./configure \
        --with-apache=../apache_1.3.20 \
        --prefix=/usr/local/apache/intranet \
        --with-config-file-path=/home/www/intranet/php \
        --enable-debug \
        --enable-session \
        --with-exec-dir=/home/www/intranet/php/bin \
        --with-pgsql

That's strange. I guess you are using session handler written by me.
I don't have such problem at all.

Do you get any error messages in your apache/php/postgresl error logs?
If there is, please provide error messages.

Next time, could you write your PostgreSQL server(backend) version AND libpq version that you use?

PostgreSQL 7.1.3 (latest FreeBSD port - downloaded from PostgreSQL website on Monday)

Errors from Apache:
[Thu Dec 13 14:24:54 2001] [notice] child pid 93032 exit signal Bus error (10)
[Thu Dec 13 14:24:54 2001] [notice] child pid 93008 exit signal Segmentation fault (11)

Errors from PHP: None

Messages in PostgreSQL error log:
pq_recvbuf: unexpected EOF on client connection


FWIW, there have been a couple other people with similar problems, one mentioned he was using MySQL, so I don't think it's a PostgreSQL problem, but something to do with cleanup.  I don't have any problems whatsoever with 4.0.6 under the same configurations.

Errors from Apache:
[Thu Dec 13 14:24:54 2001] [notice] child pid 93032 exit signal Bus error (10)
[Thu Dec 13 14:24:54 2001] [notice] child pid 93008 exit signal Segmentation fault (11)

SIGBUS  shouldn't happen....
Do you use SSL, Java? It seems bus error could heppen for some configuration even without PHP with FreeBSD.

http://www.mail-archive.com/openssl-dev%40openssl.org/msg09701.html
http://www.phpbuilder.com/mail/php-general/2001072/2008.php

There may be other causes. You'll find more if you search.
You should also search Apache and/or ModSSL bug database see if there is similar problem is reported.

We can not tell if this is PHP's fault or not, unless you provide backtrace. 

[This is not related to session after all. Changed status = Reproducible crash]

I mean provide backtrace with SIGBUS, if you can. (I'm not sure if you can take the backtrace or not)
See "man 7 signal" for signals.

The bus error would only happen maybe one out of 50 times or so, but looking at my error logs for the last 3 months, I haven't had EITHER error on any of my web servers.

From what I can gather, a bus error can still be an attempt to access memory that is nonexistent.  I've tried to reproduce the sig10 error in gdb but have been unable to thus far.  I think the 2 (3) backtraces I've already given are a good start though.

I do have an SSL server, but the backtraces I sent you were from Apache 1.3.20 along PHP 4.1.0 or 200112131200.  I did not see any errors in my logs for the SSL server, but that's not surprising since I hadn't upgraded my SSL server until AFTER I built my temporary workaround.  (Which, btw, is compiling PHP without session support and including my own session.php code which duplicates all the built-in session code.  The only thing I don't have is the global $_SESSION that can be used without a global statement.  I think I can deal with that.)

I don't have Java on any of the systems.   Base Apache with no other modules except PHP.  I cannot reproduce the problem under 4.0.6.  As soon as I upgraded to 4.1.0 I started having the problems.  (Without changing anything else)

Regardless, whether or not it's a session problem (From the backtraces it looks like its closer to something in the Zend internals, but I don't know enough about the code to offer a suggestion of the type), the problem only comes out when I have the session code enabled in PHP.  So far I have not had a single problem once I removed session support (--disable-session) from PHP and started using my own code.

Since I wrote my session code to duplicate the internal support, it'll be easy enough for my to recompile PHP with session support and not have to change anything in my code itself.  (I use a conditional include based on whether or not session_start() exists as a function)

Another update.  If I have the following in the script:

session_register("onevar");

And then don't set the variable to anything, I get the crash on zend_hash_get_current_key_ex

If I have the following in my script:

session_register("onevar");
$_SESSION["onevar"] = "";  //Anything in the quotes.

Or just:

$_SESSION["onevar"] = "";

I get the crash at _zend_is_inconsistent


Next, if I have the following:

session_register("onevar");
session_unregister("onevar");

I get an entirely different crash.  Here's the bt.

Program received signal SIGSEGV, Segmentation fault.
0x81497bc in zend_hash_del_key_or_index (ht=0x829e7e4, arKey=0x829d6a4 "onevar", nKeyLength=7, h=4009320036, flag=0)
    at zend_hash.c:484
484             p = ht->arBuckets[nIndex];
(gdb) bt
#0  0x81497bc in zend_hash_del_key_or_index (ht=0x829e7e4, arKey=0x829d6a4 "onevar", nKeyLength=7, h=4009320036, flag=0)
    at zend_hash.c:484
#1  0x80bfb74 in zif_session_unregister (ht=1, return_value=0x82ae5a4, this_ptr=0x0, return_value_used=0) at session.c:1279
#2  0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598
#3  0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#4  0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310
#5  0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at sapi_apache.c:90
#6  0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 "/home/www/intranet/htdocs/test.php")
    at mod_php4.c:575
#7  0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590
#8  0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517
#9  0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307
#10 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323
#11 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209
#12 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008341402) at http_main.c:4313
#13 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395
#14 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683
#15 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010

Next, if I have the following:

$_SESSION["onevar"] = "Test";
session_unset();

I get the following (yet another bt):

Program received signal SIGSEGV, Segmentation fault.
0x81482f9 in _zend_is_inconsistent (ht=0x84003038, file=0x81e01e4 "zend_hash.c", line=558) at zend_hash.c:84
84              if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x81482f9 in _zend_is_inconsistent (ht=0x84003038, file=0x81e01e4 "zend_hash.c", line=558) at zend_hash.c:84
#1  0x8149b31 in zend_hash_clean (ht=0x84003038) at zend_hash.c:558
#2  0x80bff90 in zif_session_unset (ht=0, return_value=0x82ae5e4, this_ptr=0x0, return_value_used=0) at session.c:1384
#3  0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598
#4  0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#5  0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310
#6  0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at sapi_apache.c:90
#7  0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 "/home/www/intranet/htdocs/test.php")
    at mod_php4.c:575
#8  0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590
#9  0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517
#10 0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307
#11 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323
#12 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209
#13 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008342128) at http_main.c:4313
#14 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395
#15 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683
#16 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010

Finally, if I do the following:

session_register("onevar");
// No initialization on $onevar or $_SESSION["onevar"]
session_unset();

I get this:  (Last bt)

Program received signal SIGSEGV, Segmentation fault.
0x8149b5d in zend_hash_clean (ht=0x829e764) at zend_hash.c:565
565                     p = p->pListNext;
(gdb) bt
#0  0x8149b5d in zend_hash_clean (ht=0x829e764) at zend_hash.c:565
#1  0x80bff90 in zif_session_unset (ht=0, return_value=0x829d564, this_ptr=0x0, return_value_used=0) at session.c:1384
#2  0x816af2e in execute (op_array=0x82944a4) at ./zend_execute.c:1598
#3  0x81448e9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#4  0x808caad in php_execute_script (primary_file=0xbfbff894) at main.c:1310
#5  0x8150426 in apache_php_module_main (r=0x8284034, display_source_mode=0) at sapi_apache.c:90
#6  0x808919e in send_php (r=0x8284034, display_source_mode=0, filename=0x8284b14 "/home/www/intranet/htdocs/test.php")
    at mod_php4.c:575
#7  0x80891f2 in send_parsed_php (r=0x8284034) at mod_php4.c:590
#8  0x8175311 in ap_invoke_handler (r=0x8284034) at http_config.c:517
#9  0x81899b4 in process_request_internal (r=0x8284034) at http_request.c:1307
#10 0x8189a1e in ap_process_request (r=0x8284034) at http_request.c:1323
#11 0x8180a1f in child_main (child_num_arg=0) at http_main.c:4209
#12 0x8180bdd in make_child (s=0x8226034, slot=0, now=1008342253) at http_main.c:4313
#13 0x8180d56 in startup_children (number_to_start=5) at http_main.c:4395
#14 0x8181360 in standalone_main (argc=2, argv=0xbfbffbbc) at http_main.c:4683
#15 0x8181b78 in main (argc=2, argv=0xbfbffbbc) at http_main.c:5010


I apologize for the large amount of bt's, but I figured they'd all be helpful with tracking down the problem.

(BTW, all my recent testing has been under the snap version I downloaded yesterday)

After reading other similar problems, looking at PHP/Zend source code and tracking down all the different crashes, I believe I found the problem.  I went back to the internal session code and for the past 2 hours or so things are working ok.  (No faults)

My session_read function had a "return false;" when there was no data available.  Obviously, the lower-level functions treat this "false" as data and try and manipulate it as such.  (Perhaps even trying to unserialize it?)

Regardless, switching to "return '';" eliminated the crashes for me.

Whether or not this is some other bug popping up (freeing the memory for a false incorrectly) or just a documentation issue I really don't know.  At the very least, since many of the tutorials on user-defined session handlers have "return false;" (I just checked PHPBuilder and the code there has it), if there's a way to fix it in the code then great!  If not, maybe put it in a FAQ somewhere or put it up in the documentation under the set_handler function.

Comments?

Could you take a look at my user session handlers using PostgreSQL.
You'll see what kind of values should be returned.
Please report the result.

http://www.zend.com/codex.php?id=456&single=1

I had already tried out your user handlers (as you can see from the bug report).  Your handlers weren't causing the crash but were helping in making the crash happen. (I would guess that the initialization of the internal data structures from your handlers allowed the invalid "return false;" pointer to be fubar'd in such a way to cause a segfault.)

Read the bug report, it's all there, including on how I was reproducing the crash.

Your session handlers have a few problems when there is concurrent access for the same session id.  (It *DOES* happen, especially with AvantGo clients, trust me on this one)  You also do not check for expiration in your session_read.  Since garbage collection doesn't happen on every single access, there's a possibility that stale data would get loaded.

Also, since your session handlers aren't mentioned anywhere on the PHP website under the session documentation, as well as not stressing the fact that returning false will cause data corruption, it still doesn't really address the issue.  

Personally I don't think the doing something in a script language should cause a low-level crash. I believe there was another recent bug dealing with the xslt extension that explained this issue well: "But PHP generating nice corefiles is not ok."

At most I think PHP should return an error when the data isn't what was expected, not segfault, or core, or crash.

Is this fixed?
Anyone mind if I fix this and commit?
--
Yasuo Ohgaki

Assigned to myself. By the I updated this bug report, I know the fix, but I forgot what is was now :(  
I'll work on this after I finish things have to do....

I've not committed the fix for this bug yet, but you can work around the segfault. 

Return string when there is no data to read or failed to write. (i.e. return '';) User session save handler expect string data, if you return other than string, it segfualts.

This bug has been fixed in CVS.

Since ver 4.1.2 was released Feb 27 and the post of Feb 2 says the fix has been commited to the CVS and because of this line in the NEWS: 'Fixed a crash in the session module (Yasuo)', I'm assuming the fix was commited in ver 4.1.2. If not, then this is probably a moot post.

Nonetheless, I'm still having this problem. I'm currently using the work around (return '') and httpd no longer seg faults but returning php booleans does cause the crash.

My server info: linux 2.2.19, apache 1.3.24, php 4.1.2 and Ying Zhang's mysql session handlers.

This is the backtrace I've gotten from it:

Program received signal SIGSEGV, Segmentation fault.
0x81ace4a in _zend_is_inconsistent (ht=0x0, file=0x82905e4 "zend_hash.c", 
    line=975) at zend_hash.c:84
84              if (ht->inconsistent==HT_OK) {

--
Thanks.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

No feedback, should be fixed in that snapshot..