Index:
[thread]
[date]
[subject]
[author]
From: teunis <teunis@computersupportcentre.com>
To : ggi-develop@eskimo.com
Date: Tue, 13 Jul 1999 20:12:24 -0700 (MST)
Re: hacking methods to find out bugs
On Mon, 12 Jul 1999, Kien Pham wrote:
>
>
[clip]
> > Note the \n is important in some cases -- it flushes a
> > line-mode
> > tty output stream, so if you leave it off, you may think
> > your
> > segfault is occuring earlier than it actually is.
> >
> > --
> > Brian
> I haven't really been following this thread, but how about
> stepping through the code with a debugger?
Hah! I haveto debug my code with printfs all the time. I can't find a
-working- gdb that supports threads!
(It's -time-consuming- to find bugs in message-tossing multithreaded
code... If ya have a valid message sent and a null message received and
your code has a thread-based GC collecting messages simultaneously to all
of this... finding a message dissappear is a pain! (turns out the GC was
too agressive - adding a "time last accessed" to messages stablized things
lots :)
Also Java has built-in segfault handling that spits out whole debug traces
(code lines, variable conditions and everything) on SIGSEGV's. I tried
to write something similar (and even to hunt down the code in Java) and
had no luck.
Lesson : If ya are debugging and have a Java-engine linked in, you'll
have -real- nice debug traces in a SEGV. Just don't install yer own
handler *sigh* (actually there's a way but I can't remember it at the
moment. I added it to restore screen on a crash :)
G'day, eh? :)
- Teunis
Index:
[thread]
[date]
[subject]
[author]