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]