ID: 31433 Updated by: [EMAIL PROTECTED] Reported By: dgrimes at scvl dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: SCO OpenServer 5 PHP Version: 4.3.10 New Comment:
Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Although that crash looks more like it's internal SCO bug in their libc.. Previous Comments: ------------------------------------------------------------------------ [2005-01-14 03:49:59] dgrimes at scvl dot com OK... Sorry for the delay... Here is the output from gdb: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-unknown-sco3.2v5.0.0elf"... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.2...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libresolv.so.1...done. #0 0x80021bb2 in getcwd () from /usr/lib/libc.so.1 (gdb) bt #0 0x80021bb2 in getcwd () from /usr/lib/libc.so.1 #1 0x80073cf0 in pathcanon () from /usr/lib/libsocket.so.2 #2 0x80073fd0 in realpath () from /usr/lib/libsocket.so.2 #3 0x80ccc70 in php_execute_script (primary_file=0x8047b3c) at /d/cdev/php-4.3.10/main/main.c:1703 #4 0x811c460 in main (argc=1, argv=0x8047b84) at /d/cdev/php-4.3.10/sapi/cgi/cgi_main.c:1592 (gdb) I hope this is more in line with what you're looking for. Thanks, Dean ------------------------------------------------------------------------ [2005-01-10 21:09:08] [EMAIL PROTECTED] Ok, awaiting that feedback then (as this back trace is quite useless) ------------------------------------------------------------------------ [2005-01-10 15:55:03] dgrimes at scvl dot com Actually I did use --enable-debug I just wrote my post to you wrong. I recompiled and it produced the same output: (carn700a:root)[/usr/local/bin] gdb /usr/local/bin/php /usr/local/bin/core GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-sco3.2v5.0.6"... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.2...done. Loaded symbols for /usr/lib/libsocket.so.2 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libresolv.so.1...done. Loaded symbols for /usr/lib/libresolv.so.1 #0 0x80021bb2 in getcwd () from /usr/lib/libc.so.1 (gdb) bt #0 0x80021bb2 in getcwd () from /usr/lib/libc.so.1 Cannot access memory at address 0x0 (gdb) I think the problem I'm having right now is getting gdb to work properly. We use the SCO UDK for Unixware debugger and I'm not sure how or even if I can do a back trace with that debugger. I'm working that right now. Also, I'm working on upgrading the server to SCO 5.0.7 and I'll install gdb from the SCO freeware CD once I have it up and running; hopefully later today. Sorry for the confusion, Dean ------------------------------------------------------------------------ [2005-01-07 21:00:55] [EMAIL PROTECTED] The configure option is --enable-debug (ENABLE!) And you need to delete config.cache first before reconfigure. ------------------------------------------------------------------------ [2005-01-07 20:31:25] dgrimes at scvl dot com I configured with --disable-all --with-debug but I guess that doesn't work like I thought it would. Anyway, I am recompiling and will have it to you shortly. TERMCAP was not defined previously. I found the issue during testing. When I log on with at telnet session I get coredumps but when I use an X session it would work. So compared the environments and found the difference to be the TERMCAP setting. I decided to set the TERMCAP variable to the value used in the X session for the telnet session and PHP then worked. Dean ------------------------------------------------------------------------ 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/31433 -- Edit this bug report at http://bugs.php.net/?id=31433&edit=1