Hi, I'm no Solaris expert, but my 2 cents:
On Mon, 2008-05-26 at 06:04 -0700, UNIX admin wrote: > On Solaris 10 5/08 however, the same binaries cause Apache > child processes to crash with SIGSEGV (httpd`php_handler > causes the crash). Always or in some random situations? > The same PHP revisions compiled on Solaris 10 5/08 do not > run on Solaris 10 1/06 (being newer) with "cannot find > libresolv.so" error, even though libresolv.so is present on > the system. PHP might use linker magic, like gcc's -Wl,--rpath switch to set a custom resolve path for finding shared objects. So maybe PHP found libresolve.so in a non-standard location and tries to use that locaiton on the other box, too. You might check with truss or similar where it looks for the lib. > To the best of my knowledge and belief, I thought we were > GUARANTEED that binaries compiled on all previous revisions > of SunOS will continue to work on newer revisions of SunOS. > > Is this correct? Again, no Solaris expert but: Yes and no, the binary itself should work, but you might dynamically link to other libraries and their ABIs might be incompatible depending on the library version, and PHP uses quite a lot external libraries so it's extremely likely that one lib has a little different ABI... > Further, is anyone familiar with this particular scenario of > httpd`php_handler causing Apache children to coredump? > > And if so, what is the solution? Depends on the exact reason, see my first question, a backtrace might help, if you can reproduce it best would be to compile using --enable-debug configure switch so the binary holds more debugging information which gives a more verbose backtrace. If it is a "random" segfault the usual reason is a too deep recursion inside PHP which PHP doesn't handle and the system terminates the process due to a stack overflow. In a backtrace you'd see many calls to execute or zend_execute in that case. In every other case it's hard to say without more information. johannes
