strange segfault with pthreads in 0.9.28
Peter S. Mazinger
ps.m at gmx.net
Mon May 15 19:21:06 UTC 2006
On Mon, 15 May 2006, Rupert Mazzucco wrote:
> > > upgraded make from 3.80 to 3.81 because of some dubious problem with vm
> > > exhaustion,
> > was this 'memory exhausted' maybe? Do you have disabled
> > MALLOC_GLIBC_COMPAT per chance?
> Yes and yes. I' not a big fan of gnuisms, and occasionally having to go
> through config.h's and removing #define malloc rpl_malloc lines seemed a
> small price to pay.
that is not enough, most of GNU apps will fail, sed/grep/diff, many that
use own regex (unpatched to support the non-glibc-malloc version)
> Hmm, malloc ... segmentation fault ... you don't think? ... but surely
> uClibc would know how to handle its own malloc's return values?
I have built some time ago many apps against .28 w/ that option disabled,
but it is not worth it, you never know where it will fail next time.
> > I can't recall anyone having problems w/ make-3.80
> I can, it's even in the list archive ;) along with the information that
> switching to 3.81 solves them. In fact, strace showed that make-3.80 under
> some circumstances croaked while trying to mmap all 4GB of virtual memory.
> This was clearly a bug, and now that you mention it, sounds like something
> that could happen if one didn't heed the old C commandment "thou shalt not
> follow the NULL pointer, for chaos and madness await thee at its end."
> What bothers me though is the make-3.81 release note that says they have
> introduced some incompatibilites. I sincerly hope this is meant to be a
> joke. But it was the reason I tried 3.80 first. After all, I didn't need
> new "features", I wanted to compile existing software packages.
> > well, if you want to switch between 2.4 and 2.6, I would suggest you use
> > 2.4 kernels to build everything
> But will that work correctly under 2.6? My current plan is to rebuild
it should better work then the other way
> everything under 2.6 and hope for the best. After all, my shiny new system
> boots and the toolchain works (minus pthreads).
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
More information about the uClibc