[gccsdk] libapr

[Lee Noar]

Peter Naulls wrote:

[SNIP crash]

> This is a static binary, and I have turned off threading and other
> things which might be causing a problem.   This seems to be triggered
> by, or around the "writev" test in testall.

The static binaries contain PIC code and it's this that causes them to 
crash, so this is a build problem. The dynamic binaries also contain PIC 
code, but that doesn't seem to be as much of a problem. The fact that 
they are already registered to SOManager and the mechanisms for shared 
library code are in place no doubt help a lot here, but I'm not 100% 
certain that it's bulletproof.

> Apart from that, in some of its other tests, John and I have seen
> instabilities in running shared library versions of some of the
> tests in a taskwindow, where other applications would be taken
> out with an abort - e.g, testshmconsumer.

Yes, hopefully my last two commits to UnixLib will fix these problems 
and they may make dynamically linked Firefox more stable too (but don't 
quote me on that ;-)

> Also in the shared library library version of the 'testall' with debug
> off, it would first crash with a segmentation fault, and then
> a repeat run would give a much earlier crash with an illegal
> instruction - this is cleared by reloading the SOManager module.
> However, this might be a side effect of the memory problems seen
> in the first case above, but does suggest some unhelpful state
> stored by SOManager.

Those symptoms match my findings; it turned out that the call back 
registers were being dumped into UnixLib's PLT, so when it jumped to a 
corrupted PLT entry you got an illegal instruction.

testall still crashes in testfile, it could be related to the PIC in 
executable issue, but I wouldn't expect it to get this far if that were 
the case.

Lee.