ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't
doing any creating, destroying or unsetting.
In any case, I've been running this morning's snapshot all day without
any problems. It seems to have been fixed (the POST problems went away
as well).
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2002-03-04 04:38:12] [EMAIL PROTECTED]
Can you please try a shapshot from snaps.php.net, my guess is that this
is already fixed.
Derick
------------------------------------------------------------------------
[2002-03-04 00:55:05] [EMAIL PROTECTED]
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
------------------------------------------------------------------------
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xbffff090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 <module_registry_cleanup>) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc "/usr/local/apache/htdocs/planworld/index.php")
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbffffaa4, inbufend=0x8048560 "U\211åSè",
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
------------------------------------------------------------------------
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
84 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 "
>ýÿþ>ýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ"...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xbffff090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
------------------------------------------------------------------------
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should NEVER
(okay this is my opinion) use the bundled MySQL libs. On your
configure line you should do
--with-mysql=/usr | --with-mysql=/usr/local
Just depends on where it put your libs, which you can find like so
[root@somemachine /]# ldconfig -p | grep mysql
libmysqlclient.so.10 (libc6) =>
/usr/local/lib/mysql/libmysqlclient.so.10
libmysqlclient.so (libc6) =>
/usr/local/lib/mysql/libmysqlclient.so
I think the RPM puts it in /usr.
-Chris
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14529
--
Edit this bug report at http://bugs.php.net/?id=14529&edit=1
