After all the research, it seems the problem is LinuxThreads just has all
sorts of bugs between mishandling signals and deadlocking.
I'm dealing with a tight schedule and lots of code that works great until a
LinuxThreads threadmanager barfs.
I'm in one of those classic positions where I inherited a lot of code that
assumed pthreads worked as described, but have found otherwise.
There's no time or budget to rewrite the entire project to circumvent
I've built a newer cross-compiler using NPTL, and when compiling with it
(statically of course), I have the __libc_fork assertion problem due to some
Likewise, I can't easily modify my kernel for that workaround, because I
will continue to have to use the precompiled userland binaries in my system
that rely on the old glibc libs with LinuxThreads,
compiled in. When it comes to the userland apps that MontaVista supplies,
they don't provide the source and configuration for all the packages (at
least not with the CDs I have), and even if they did, I would probably
require more time than I have to get them all built as needed.
So, my questions to the helpful people on this list are:
1. Does anybody know if MontaVista has fixed these issues in their newer
releases/patches of Pro 3.1 or Pro 4.0? in other words,
would I be spending the company's money wisely to go back to MontaVista
for upgrades and service?
2. If the answer to #1 is NO, has anybody else out there come across this
same type of issue and found a decent solution?
// as for workarounds, I've blocked basically all signals in all threads,
created separate threads to wait on blocked signals, removed all the
calls, and when I debug, I find that ususally I'm deadlocked in some form of
timed_wait() or some other pthread related lockable/blockable call deep
inside another system call
such as syslog for example.