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

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

The compile failure should at least be fixed now.

That version compiled just fine but I still have the original problem. PHP 4.0.6 compiles and doesn't have this issue. It's the version were using now. I can open an issue with SCO if you think it's a bad libc. Can you give me more information that supports that conclusion?

Dean

Can you provide the above backtrace but using the snapshot?

You could ask SCO support why the realpath() function is called from libsocket.so.2 and not from libc.so.1..

See also bug #23665

SCO sent this to me:

Dean, Please have a look at this TA and let me know if you think this will help your situation. It appears that this is applicable to OSr5.0.0 to 5.0.6.

Thanks,
Todd

*********************** TA # 100815 **********************************

Calling realpath(S) from within my program causes a core dump.

KEYWORDS: v5 5.0.0 osr5 openserver dev sys development system ds getcwd realpath memory fault coredump core dump ENGREF LTD-246-807

RELEASE:  SCO OpenServer Development System Release 5.0.0

PROBLEM:  If I make a call to realpath(S) from within my source I find 
          that, when compiled, the resulting binary will terminate with 
          the error:

                Memory fault(coredump)

CAUSE:    The character buffer passed to realpath(S) is being passed to
          a function called pathcanon().  This function is calling getcwd(S) 
          with a buffer size of 4096 bytes.  getcwd(S) clears this buffer 
          and overruns the stack causing the core dump.

SOLUTION: This problem has been reported to SCO Engineering.

          To work around this problem, make sure that the character 
          buffer passed to realpath(S) is 4096 bytes in size:

                char buff[4096];

                realpath(filename, buff);

          where 'filename' is the name of the file whose path you wish 
          to resolve.
--------------------------------------

Thanks,
Dean

Here is the fix:

main/php.h

set MAXPATHLEN from 256 to 1024


diff -c php.h.org php.h    
*** php.h.org   Thu Jan 27 20:54:04 2005
--- php.h       Thu Jan 27 20:56:13 2005
***************
*** 250,256 ****
  # ifdef PATH_MAX
  #  define MAXPATHLEN PATH_MAX
  # else
! #  define MAXPATHLEN 256    /* Should be safe for any weird systems that do no
t define it */
  # endif
  #endif
  
--- 250,256 ----
  # ifdef PATH_MAX
  #  define MAXPATHLEN PATH_MAX
  # else
! #  define MAXPATHLEN 1024    /* Should be safe for any weird systems that do n
ot define it */
  # endif
  #endif

After additional testing I found that MAXPATHLEN needs to be increased to 4096. Although 1024 kept PHP from core dumpping, certain functions like shell_exec would not execute properly.

Dean

I have opted to close this issue. After applying the change to MAXPATHLEN, the problem no longer exists.