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

Reply via email to