Index:
[thread]
[date]
[subject]
[author]
From: Julian v. Bock <JimProfit@t-online.de>
To : ggi-develop@eskimo.com
Date: Wed, 14 Jul 1999 16:38:08 +0200
Re: hacking methods to find out bugs
On Wed, 14 Jul 1999, teunis wrote:
> On Mon, 12 Jul 1999, Kien Pham wrote:
>
[...]
>
> 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.
no problem.
Try this function:
It takes the program name as argument and prints out the backtrace up to the
function that calls backtrace().
If one wants to use it in a library (ggiPanic ?) he could get the prog. name
from the entry in the proc filesystem.
One could also use this in a SIGSEGV handler.
void
backtrace( char* pn )
{
char bt[201];
char command[101];
sprintf( command, "echo backtrace | gdb %s %i 2>/dev/null", pn, getpid() );
FILE* gdb = popen( command, "r" );
do
{
fgets( bt, 200, gdb );
} while ( strncmp( bt, "#9", 2 ) );
do
{
printf( "%s", bt );
fgets( bt, 200, gdb );
} while ( strncmp( bt, "(gdb)", 5 ) );
pclose( gdb );
}
happy coding...
Julian
Index:
[thread]
[date]
[subject]
[author]