Jay Blanchard wrote:

> [snip]
> You are right. It segfaults only if the virtual() call comes before
> creating the XSLTProcessor instance.
> [/snip]
>
> I cannot replicate the problem on Linux.
>

So you get the XSLT error messages instead? That's what you should be
seeing.

See also http://bugs.php.net/bug.php?id=42666


/Per Jessen, Zürich

> [snip]
> You are right. It segfaults only if the virtual() call comes before
> creating the XSLTProcessor instance.
> [/snip]
>
> I cannot replicate the problem on Linux.
>

So you get the XSLT error messages instead? That's what you should be
seeing.
{/snip]

Yep, no segfault. I do not have a windows box handy for testing.

Jay Blanchard wrote:

>> [snip]
>> You are right. It segfaults only if the virtual() call comes before
>> creating the XSLTProcessor instance.
>> [/snip]
>>
>> I cannot replicate the problem on Linux.
>>
>
> So you get the XSLT error messages instead? That's what you should be
> seeing.
> {/snip]
>
> Yep, no segfault. I do not have a windows box handy for testing.

I'm on Linux too, so never mind Windows for the moment.
So what's the difference between our two environments? Try putting
something in the problem-include file to verify that virtual is doing
what it's supposed to.


/Per Jessen, Zürich

On Fri, 14 Sep 2007 08:10:56 -0500, "Jay Blanchard" <jblanchard@pocket.com>
wrote:
> [snip]
> You are right. It segfaults only if the virtual() call comes before
> creating the XSLTProcessor instance.
> [/snip]
>
> I cannot replicate the problem on Linux.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

In one of the other messages i stated the script works fine on linux.
But PHP on windows seems to have a problem with virtual(). Even without
creating an instance of the XSLProcessor class.

But dropping virtual() for include() or require() solves the problem.

T.Lensselink wrote:

> In one of the other messages i stated the script works fine on linux.
> But PHP on windows seems to have a problem with virtual(). Even
> without creating an instance of the XSLProcessor class.
>
> But dropping virtual() for include() or require() solves the problem.

Getting rid of the symptoms is easy, solving the problem is not.

include/require are not replacements for virtual(). virtual() creates
an apache sub-request which I need for content-negotiation.


/Per Jessen, Zürich

Jay Blanchard wrote:

> [snip]
> A core dump or an strace or some debug output at the right time will
> have 99% of the information you need - provided you understand how to
> read it.
> I submit there is generally no need to reproduce a problem in order to
> diagnose it. To fix it, yes, it will undoubtedly if you can
> reproduce it, but once you've diagnosed it, reproducing it is a
> lot easier.
> [/snip]
>
> Wouldn't it be nice to have 100% of the information? That last 1% may
> be the code that caused the problem.

It would be nice, yes. In my previous professional life, I would
probably have asked the customer to set a SLIP trap to provide that
extra info. That trap would be triggered/detriggered given the right
set of circumstances and could give me either a systems trace, maybe a
stand-alone dump or something else to assist me in locating the
problem.

Right now I'm trying to debug what I think is a race condition in spamd
(spamassassin) when it reloads the config. Reproducing is out of the
question except by chance. To me debug, I now run an strace every
time the daemon is sighup'ed. It might be another couple of months
before it happens again.

> [snip]
> What's the purpose of a core dump if it does not provide the key
> information for solving a problem? If I still have to isolate and
> reproduce the issue in user code, there seems to be very little need
> for the core dump, right?
> [/snip]
>
> Not so. A core dump, as you stated before, gives you most of the
> information. Having the code that appeared to have caused the problem
> is definitely welcomed. It s to see what was occurring when the
> segfault happened. Would you not agree?

Oh, definitely. The complete code should always be available to you,
but that's not the same as being able to reproduce the problem.


/Per Jessen, Zürich

[snip]
I'm on Linux too, so never mind Windows for the moment.
So what's the difference between our two environments? Try putting
something in the problem-include file to verify that virtual is doing
what it's supposed to.
[/snip]

That worked fine. I am sure that there are many differences in our
environments. We are running Suse Linux, PHP 5.2.1, Apache 2.2.4.

Jay Blanchard wrote:

> [snip]
> I'm on Linux too, so never mind Windows for the moment.
> So what's the difference between our two environments? Try putting
> something in the problem-include file to verify that virtual is doing
> what it's supposed to.
> [/snip]
>
> That worked fine. I am sure that there are many differences in our
> environments. We are running Suse Linux, PHP 5.2.1, Apache 2.2.4.

That's close though - my workstation is openSUSE 10.2, PHP 5.2.4, Apache
2.2.4.


/Per Jessen, Zürich

[snip]
> That worked fine. I am sure that there are many differences in our
> environments. We are running Suse Linux, PHP 5.2.1, Apache 2.2.4.

That's close though - my workstation is openSUSE 10.2, PHP 5.2.4, Apache
2.2.4.
[/snip]

As this installation is on a development box it has nearly every
extension known loaded, if you have the same then we are nearly
duplicates. I am unsure of the differences in PHP 5.2.1 and 5.2.4 but I
would not think that it would touch virtual().