printf or sprintf causing threads to hang on LynxOS 4.2 (PowerPC) ?
JJ
have a tendency to throw in quick printfs to help diagnose problems.
We have noticed an intermittent problem which causes some threads to
hang. Since this problem never seems to occur when logging is
disabled, we were wondering if the hang conditions might be caused by
either printf or sprintf.
We are running LynxOS 4.2 on PowerPC. Any comments or suggestions
appreciated.
Steve Watt
Are you attempting to call printf() and/or sprintf() inside of signal
handlers? If so, that's a recipe for trouble, because the thread that
took the signal might be inside stdio (perhaps even doing a printf())
and try to lock something that it already holds (with the data in some
indeterminite state because the lock is held).
Note that the above-guessed failure mode is not unique to LynxOS - any
thread-aware OS will likely have trouble with it.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
Trevor Taylor
We had what seems like the same symptoms with LynxOS 4.0, x86, gcc
3.2.2 toolchain. Our solution was not to use buffered stdout or stderr
(which means no printf, cout <<, fprintf(stdout). LinuxWorks did not
fix - from memory I think the explanation was something like threads+C+
+=not supported. We rewrote our logging utilities to use write(0, ...)
for stdout and write(1, ...) for stderr and trained our developers
(with varying degrees of success :-) to only use these. We also had to
regularly search the source code to weed out misuse.
In no case were we ever doing stdout/std::cout from signal handlers (I
agree with Steve that would not work on any unix I know).
ScottM
> > appreciated.
I (just today) started porting code to LynxOS 4.2.0, and have been
greeted by an endless series of board lockups - sometimes during
fprintf(stderr...), sometimes, bizarrely, calling nanosleep(). What is
essentially the same code, runs fine on other systems. Tool is gcc
3.2.2 crosscompiled from Solaris, board is powerPC. Code is
multithreaded C++, and not very complicated, either.
I'll try getting rid of buffered output, but frankly that sounds
crazed. I've never used a system that didn't support fprintf()
properly from threads; no vendor could survive the hollow, mocking
laughter that would cause. And as for a board lockup when calling
nanosleep with verified, correct arguments...
Is it always this much fun? Excuse the bitterness, but it's been a
long day.
Steve Watt
Just plain ol' buffered stuff should work just fine, assuming you've
compiled the compiler correctly, and are building against the threaded
libs.
That stuff was fine back in 2.2 days, seems rather highly improbable
to be broken now.
It sounds like you've got some kind of toolchain problem underneath.
ScottM
board and running test code. One of my threads ran at a high priority
and for a long time, causing telnetd to starve for CPU. I assumed the
board had hung. Adjusting thread priorities was all it took.
Steve Watt
Heh. All of us step in that hole once. The lesson usually sticks.
One of the hazards and features of hard real-time kernels is that
when you tell it something's high priority, it believes you. If
that thread is ready, it'll run. Non-blocking forever loops in
high priority code is somewhat deletrious to the remainder of
the system. ;)