Bug Trace, as best as I can get...

root@dev:/usr/local/apache/bin# gdb /usr/local/apache/bin/httpd 
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 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 "i386-redhat-linux"...(no debugging symbols 
found)...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 12186)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12186)]
0x400a3f62 in Situation::generateMessage (this=0x6e617473, type=578643299, 
code=1667846974, 
    arg1=@0x662f3c6b, arg2=@0x3e746e6f, theMessage=@0x68742f3c) at 
situa.cpp:279
279	    if (messenger && !(flags & SAB_NO_ERROR_REPORTING))
Current language:  auto; currently c++
(gdb) bt
#0  0x400a3f62 in Situation::generateMessage (this=0x6e617473, 
type=578643299, code=1667846974, 
    arg1=@0x662f3c6b, arg2=@0x3e746e6f, theMessage=@0x68742f3c) at 
situa.cpp:279
#1  0x6e49646f in ?? ()
Cannot access memory at address 0x6d247b64
(gdb)  

I am getting this as well, driving me nuts. Copy of email sent to Sablotron list as well. Also: could this be due to PHP's bundled expat possibly at all? Something to look at I guess, but then again, I'm not that technical on the PHP internals.

The machine is Redhat Linux 7.1, PHP 4.1.1, Sablotron 0.82, Apache 1.3.23. I have followed the directions every match of a segfault+php+sablotron+apache on google matched - recompile apache WITHOUT it's expat_lite.

Well, I've done that. I renamed the expat_lite dir AND used the --disable-rule=EXPAT, and did a "strings httpd | grep -i expat" and grepped for xml as well, and did an "nm" on the binary as well - no trace of any of that. I also removed the whole apache hierarchy to install it fresh. However, my calls to xslt_process() still give me:

[Sat Feb 16 01:46:55 2002] [notice] child pid 6871 exit signal Segmentation fault (11)
[Sat Feb 16 01:46:56 2002] [notice] child pid 6894 exit signal Segmentation fault (11)
[Sat Feb 16 01:46:58 2002] [notice] child pid 6867 exit signal Segmentation fault (11)
[Sat Feb 16 01:47:01 2002] [notice] child pid 6868 exit signal Segmentation fault (11)

in fact, now each page load reports TWO errors. the "sabcmd" command works fine, and is able to understand these. technically this shouldn't be a Sablotron bug, but I was hoping someone there would have more pointers to fix this, or find more information about it on their side... but I think the fix will be from the PHP team.

php configure:

./configure  --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-track-vars --with-curl
--with-openssl --enable-sockets --enable-shmop --enable-sysvsem
--enable-sysvshm --with-jpeg-dir=/usr/local --with-png-dir=/usr/local
--with-gd --with-zlib-dir=/usr --enable-xslt --with-expat-dir=/usr/local
--with-xslt-sablot

checking for XML support... yes
checking external libexpat install dir... yes
checking for XMLRPC-EPI support... no
checking libexpat dir for XMLRPC-EPI... yes
checking whether to enable xslt support... yes
checking whether to enable the XSLT Sablotron backend... yes
checking libexpat dir for Sablotron XSL support... yes
checking for Sablotron libraries in the default path... found Sablotron in
/usr/local
checking for iconv_open in -lc... yes
checking for SablotSetEncoding in -lsablot... yes
checking for YAZ support... no

^^ i believe that's as good as it can look. it found my system expat, and sablotron. apache doesnt even care about expat. everything seems to be reading from this central expat, so why doesn't it work?

actually, i was using the function incorrectly. i was providing it strings when it was wanting filenames.

i wound up using the variable substitution (from php.net examples) and it worked, feeding it strings.

still this is a nasty bug that should be more graceful.

Making this critical because: 1. It's an easy fix 2. Documentation should be made better 3. I got bitten by it too :)

Derick

assigning to Sterling as he seems to know this best (might be because he wrote it).  Any chance we can get this fixed for the next RC process?

don't assign this to me...  :)

sterling, take care of you bugs please :)

NO BUG
NO BUG
NO BUG
NO BUG

<hartmut> sterling: IT SHALL NOT SEGFAULT, FOR WHATEVER STUPID REASON ...
<hartmut> sterling: IT SHALL NOT SEGFAULT, FOR WHATEVER STUPID REASON ...
<hartmut> sterling: IT SHALL NOT SEGFAULT, FOR WHATEVER STUPID REASON ...

No longer the XSLT maintainer.  And hartmut, I'm not putting in a stat() call for every XSLT transformation - if you don't want it to segfault, contact the Sablotron folks, or make the fix yourself, I'm no longer the maintainer, so do what you like ;)

No longer the XSLT maintainer.  And hartmut, I'm not putting in a stat() call for every XSLT transformation - if you don't want it to segfault, contact the Sablotron folks, or make the fix yourself, I'm no longer the maintainer, so do what you like ;)

Has already been fixed in Sablotron 0.95+.

Current documentation may be a bit desceptive describing 'string xml / string xsl' as arguments, but is in essence correct, if you read on.

The buffers in Sablotron library expected filenames and only reserved 512 bytes. Discussed with Derick, during 4.2.1 QA, whether PHP should guard against it, and that is not preferred.

Not a bug in php -> bogus