php5 segfault

[Mel]

On Thursday 09 October 2008 12:00:47 Jeremy Chadwick wrote:
> On Thu, Oct 09, 2008 at 11:53:11AM +0200, Laszlo Nagy wrote:
> >>> There are no options to configure in php5-pgsql.
> >>>
> >>> I tried to change the order or module in extensions.ini, no success so
> >>> far.
> >>
> >> Then my recommendation is to build PHP with DEBUG enabled (see "make
> >> config"), reproduce the situation, and provide a backtrace here.
> >
> > Problem solved. I put pgsql.so on top of all other modules and now there
> > is no segfault. Thank you!
>
> I thought you said you changed the order and it didn't work?  *confused*
>
> > Although I do not understand why it has not been fixed. The same
> > problem  existed two years ago, right?
>
> What "problem" are you referring to?  The extension ordering issue?
>
> If so: it should be obvious why it hasn't been fixed.  It doesn't appear
> to affect everyone -- for example, we have never seen this problem in
> the 4-5 years we've been using PHP on FreeBSD -- and the solution
> doesn't really make much sense anyway.

Just browse the archive of this list to see how many times it came up. 
Everyone is quite arbitrary. Just cause you never hit it, doesn't mean it's 
random. I've traced it to zend_module_shutdown, but then hit stuff I don't 
understand, namely, dlclose(3), specifically _fini() and how the zend engine 
uses it and why it's not working right. I hit ENOTIME, when trying to unwrap 
the code there.

These two notes are in my extensions.ini:
; NOTE: spl makes php coredump if loaded after pspell
; NOTE 2: simplexml makes php coredump if loaded after pspell

I don't have pspell anymore, since I stopped using it, but maybe you can then 
reproduce it. If not, I can provide you with a full extensions.ini that will 
coredump on shutdown 100% of the time (for me at least).

What I remember from my tracing attempts is that extensions are expected to 
clean up their recourses (as in php resources, the library context handlers). 
At the same time, modules are unloaded in reverse order as they are loaded. 
In the case where Module A needs Module B, module B needs to be loaded first, 
but is unloaded last. My prime suspect was that Module A frees it's 
resources, but Module B still has a ref to it in it's own resource. However, 
I dind't find that criminal.
For me it was a matter of "I can spend a few days tracking it down or just 
re-order my extensions". Where the culprit is is hard to tell, since people 
report this doesn't happen on other platforms, it can be a FreeBSD specific 
problem with how it handles dlclose() and/or garbage collection magic, or 
it's a problem within php that is as you suspect, being worked around on 
other platforms by package managers.

> It smells of a missing symbol 
> problem (e.g. libxx.so wants a symbol named "hello_bob", but the symbol
> is available in libyy.so, which has to be loaded first; however, ld.so
> and dlopen(3) have explicit handling for this scenario (see RTLD_NOW vs.
> RTLD_LAZY), so I'm at a loss).

Missing symbols happen also, but then no segfaults, simply php won't start 
(obviously). Easily traceable by module dependencies.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.