php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22147 PHP crashes when processing XSLT files
Submitted: 2003-02-10 05:30 UTC Modified: 2003-08-14 01:49 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: stuart at myrddraal dot demon dot co dot uk Assigned: dviner (profile)
Status: No Feedback Package: XSLT related
PHP Version: 4.3.0 OS: Windows XP
Private report: No CVE-ID: None
 [2003-02-10 05:30 UTC] stuart at myrddraal dot demon dot co dot uk
Here's the information reported by Windows:

AppName: php.exe
AppVer: 4.3.0.0
ModName: msvcrt.dll
ModVer: 7.0.2600.1106
Offset: 00033e05

I have reproduced the crash on two machines - one Intel, one AMD, both running XP Pro.

I have a tarball which reproduces the crash.  Happy to make it available to a PHP maintainer.  Also happy to install a debugging build of PHP, if someone can make one available, to capture more information.

Crash only happens when all the following circumstances are true:

1) Passing XML/XSL as strings through $args array into xslt_process

If Sablotron is told to process files on disk instead, no crash occurs.

2) The same running instance of PHP has been used to process a large number of XML/XSL files.

Number varies from a few hundred to a few thousand.

You can take the individual XML/XSL pair being processed at the time of the crash, and Sablotron can process them just fine on their own.

3) Using Sablotron to perform XSL processing.

Calling a command-line processor, or driving one via the Java Extension, results in no crash at all.

Best regards,
Stu

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-10 06:14 UTC] magnus@php.net
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..  
 [2003-02-10 09:37 UTC] stuart at myrddraal dot demon dot co dot uk
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
 [2003-02-10 11:12 UTC] msopacua@php.net
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.
 [2003-02-10 11:53 UTC] dviner@php.net
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


 [2003-02-10 12:47 UTC] stuart at myrddraal dot demon dot co dot uk
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
 [2003-03-18 18:32 UTC] dviner@php.net
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
 [2003-06-07 18:50 UTC] crtn at users dot sourceforge dot net
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.
 [2003-06-17 13:43 UTC] dviner@php.net
Unless someone else can verify this bug, i'm going to close it.  This has worked repeatedly on my system.

dave

 [2003-06-17 15:22 UTC] stuart at myrddraal dot demon dot co dot uk
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?
 [2003-07-07 15:54 UTC] dviner@php.net
you should be able to build php with debugging symbols turned on.  

i am still unable to reproduce this on my windows machine.
 [2003-07-07 16:19 UTC] stuart at myrddraal dot demon dot co dot uk
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
 [2003-07-07 16:32 UTC] dviner@php.net
Have you tried compiling "php4ts Win32 Debug" project in vc++?  that should have all the win32 debugging symbols you want.  

dave
 [2003-07-08 03:14 UTC] stuart at myrddraal dot demon dot co dot uk
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
 [2003-07-21 11:17 UTC] dviner@php.net
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
 [2003-07-21 12:51 UTC] dviner@php.net
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
 [2003-07-24 13:17 UTC] stuart at myrddraal dot demon dot co dot uk
Hi Dave,

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

Thanks,
Stu
 [2003-08-14 01:49 UTC] sniper@php.net
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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC