Could you please add a URL for the tarball, or send the  
tarball to php-dev@lists.php.net (if it is smaller then  
100k).  
  
Or make a small script to reproduce it..  

Okay, you can get the tarball from here:

http://www.gnqs.org/people/stu/xslt-crashes.zip

It's about 1.5Mb in size.  Sorry it's not smaller, but the 2000+ XML files in there are necessary to make Sablotron crash.

Unzip into c:/devel, and add c:/devel/php to your php.ini include_path.  Then, go into c:/devel/tools, and run

<where-you-put-it>/cli/php.exe ./reproduce.php

First time you run it, you may not get a crash.  Simply remove all the HTML files from c:/devel/htdocs/localdocs/, and re-run.  Remember to leave the c:/devel/htdocs/localdocs/xml directory intact, or you can't rerun the code!

I haven't tested that this code will work when unzipped into another directory.

Best regards,
Stu

Just adding a quick note/analysis here:
It may still be a bug in Sablotron, since using 'sabcmd', doesn't use the 'args' syntax. Either we are not freeing something we should, or the Sablotron library isn't.
If we're not freeing something, it shouldn't be windows specific.

SablotFreeResultArgs comes to mind, but the docs say:
"This call frees all memory associated with the output of the most recent transformation. You don't have to make this call, destroying the processor takes care as well as new transformation invocation. " and we do destroy the processor, in xslt_free().

Assigning to Dave, since he's got the windows setup to test this in.

I've downloaded the zip file and am trying it now.  I've run the "reproduce" program three times so far, with no crashes.  

I had two comments about the tests.  First, the test program is not really isolated to just XSLT transformations.  So even if the crash is reproducible, it'd be quite challenging to isolate the problem to Sablotron.  Of course, the problem could _be_ in Sablotron, but a lot of things are happening in this script.  It might be easier to redact the script such that only XSLT processing is happening.  
Second, with some minor changes, this script should be usable on UNIX. I think it'd be good to test it there as Melvyn pointed out eariler.  The only changes required are the hardcoded paths as far as i can tell.

Stuart, can you take a stab at changing the test script to perform only the series of XSLT transformations that cause a crash on your hardware?  And can you change the hardcoded paths to be parameters so that the UNIX folks can test it as well?

thanks
dave

Dave et al,

Have a look at http://www.gnqs.org/people/stu/xslt-crashes2.zip.  There's a new 'reproduce.php' script, and then just the XML/XSL file pairs that make it crash locally.  Should run on UNIX too.

What I've done is cached all the XML/XSL that was being fed into Sablotron by my earlier script.  The new reproduce.php simply works through these until a crash occurs, or you run out of files.

When I run and re-run this new script, I get crashes at *different* values of $l_iCount.  It doesn't crash on the same XML/XSL pair each time.

This new download is much larger because of increase in size of the XML/XSL file pairs.

Thanks for looking at this,
Stu

I can't reproduce the crash.
Altho, I do get this error:
Warning: fopen(4794.xml) [http://www.php.net/function.fopen]: failed to create s
tream: No such file or directory in C:\devel\reproduce\reproduce.php on line 26

Is anyone else able to reproduce this?
dave

I have actually had the same problem on linux.
Debian, 2.4 kernel, Apache 1.3.26-1.1, PHP 4.1.2-6
(these are all from debian packages)

by default, there are no changes for the php.ini file for php4-xslt (sablotron) install. This results in "Call to undefined function" errors.

If i try to do: dl('xslt.so'); 
I get: [notice] child pid 7797 exit signal Segmentation fault (11)
many times for each attempt to run the php script (this is the sample script provided on the xslt_create document page)

When I add the following to php.ini
extension: extension=xslt.so
I get the same error whenever I try to run this XSLT script.

Unless someone else can verify this bug, i'm going to close it.  This has worked repeatedly on my system.

dave

Can you make a debugging build available - something that'll produce a crash dump that you can actually use to get a useful stack trace?

you should be able to build php with debugging symbols turned on.  

i am still unable to reproduce this on my windows machine.

Hrm ... depends on which compiler is used for the Windows builds.  If it's Cygwin, or MinGw, then maybe.  If it's Visual C++, then no chance.

A stock debugging build for download for Windows would make it a lot easier to debug PHP when it goes belly up, don't you think? ;-)

Thanks,
Stu

Have you tried compiling "php4ts Win32 Debug" project in vc++?  that should have all the win32 debugging symbols you want.  

dave

Dave,

I don't *have* Visual C++ - if I did, then don't you think I'd have compiled my own debugging build *months* ago? ;-)

Best regards,
Stu

Hi Stuart,
  Sorry, I must have misread your message.  I thought you had vc++.  I'll try to compile a debug version of php and send it to you.

dave

I've sent you (in a private email) a zip file with a debugging build of php.exe and php_xslt.dll which properly passed your example zip file.  Please give this a try and let us know if it works for you.

dave

Hi Dave,

Sorry - there was nothing at all attached to your email :(  Could you try again please?

Thanks,
Stu

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

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.