#22147 [Asn]: PHP crashes when processing XSLT files

From: Date: Tue, 17 Jun 2003 18:44:00 +0000
Subject: #22147 [Asn]: PHP crashes when processing XSLT files
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-42149@lists.php.net to get a copy of this message
ID: 22147 Updated by: dviner@php.net Reported By: stuart at myrddraal dot demon dot co dot uk Status: Assigned Bug Type: XSLT related Operating System: Windows XP PHP Version: 4.3.0 Assigned To: dviner New Comment: Unless someone else can verify this bug, i'm going to close it. This has worked repeatedly on my system. dave Previous Comments: ------------------------------------------------------------------------ [2003-06-07 18:50:43] 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-03-18 18:32:20] 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-02-10 12:47:48] 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-02-10 11:53:58] 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 11:12:13] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22147 -- Edit this bug report at http://bugs.php.net/?id=22147&edit=1

« previous php.bugs (#42149) next »