Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

I can't give you the code, as it's more like thousand lines with dependancies.
I sent you privately a core dump.

As far as I identified, it seems it's a running schema like this ->

uksort (data, function_a)

function_a(a,b) 
{
  return function_b(a) < function_b(b)
}

with 
function_b(x)
{
    (code)
    //in come cases
    include_once("morefunctions.inc.php");
}

commenting the include_once, let it work flawless.
Included functions are just sql code without uksort.
So this currently seems from include_once. Also debugging gives me that the referenced user function is out of bounds.

The last lines of strace output:

rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
read(7, 0x8b84aa8, 8192)                = -1 EAGAIN (Resource temporarily unavailable)
fcntl64(7, F_SETFL, O_RDWR)             = 0
write(7, "\1\0\0\0\1", 5)               = 5
shutdown(7, 2 /* send and receive */)   = 0
close(7)                                = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++

I don't have the error on Athlon/2.6.15. Error comes on a Xeon/2.6.12. First I thought about a stat_64 flaw, but the include and the 2.6.15 trace shows the right next instructions are to load the file (the included_once one).

include_once causes too much locking ?

Don't send coredumps, they are useles. Please, provide a short reproducable script - no more than 25 lines.

And don't forget to disable all zend_extensions like APC, Zend Optimizer, IonCube etc. before that.

no can't do sir :(
I can't isolate a subset of calls wich creates crash.
I'm only able to produce it with full data & code.

Well, as far as I've gone, I've fixed my php code.

I use a global class which handles mysql connections.(no reconnects each time, but without persistent connexion)
The sigsev comes when I use the existing sql connection from inside the uksort user_functions.

Creating a new class from there make it works :(

We still need a reproduce code.

Again, it's impossible to isolate a reproduce code, as it loads and initialize a really complex system.
Code does not reproduce crash on my other computer (2.6.15).
So it may not work elsewhere :(

The only thing I can do, it to give ssh access to browse code & run debugger. All with non-disclosure agreement.

Then we can't help. Please reopen if you can provide a reproducing script. We will not debug a whole application, and definitely not under an NDA.

We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.