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]