RE: [GD-Linux] signals and exceptions

[Hal A. <ha...@cl...>]

That's a bit more elegant than the solution I came up with. I'm in a similar
situation to Daniel in that I'm porting a lot of "core" libraries from
Windows to Linux and I'm trying to replicate the functionality.

We do exactly the same as Daniel, we unwind the stack ourselves and output
extra debugging information.

I currently have (gcc only btw):
The CX_LINUXAPP is defined if the varius GCC or ICC symbols that we look for
are present.

#ifdef CX_LINUXAPP
	int level = 0;
	void* p = __builtin_return_address( 0 );
	while( isTracingStack_ and p and level < 20 )
	{
		outStream << p << " ";
		switch( ++level )
		{
			case 1: p = __builtin_return_address( 1 ); break;
			case 2: p = __builtin_return_address( 2 ); break;
			case 3: p = __builtin_return_address( 3 ); break;
			case 4: p = __builtin_return_address( 4 ); break;
			case 5: p = __builtin_return_address( 5 ); break;
			case 6: p = __builtin_return_address( 6 ); break;
			case 7: p = __builtin_return_address( 7 ); break;
			case 8: p = __builtin_return_address( 8 ); break;
			case 9: p = __builtin_return_address( 9 ); break;
			case 10: p = __builtin_return_address( 10 ); break;
			case 11: p = __builtin_return_address( 11 ); break;
			case 12: p = __builtin_return_address( 12 ); break;
			case 13: p = __builtin_return_address( 13 ); break;
			case 14: p = __builtin_return_address( 14 ); break;
			case 15: p = __builtin_return_address( 15 ); break;
			case 16: p = __builtin_return_address( 16 ); break;
			case 17: p = __builtin_return_address( 17 ); break;
			case 18: p = __builtin_return_address( 18 ); break;
			case 19: p = __builtin_return_address( 19 ); break;
			case 20: p = __builtin_return_address( 20 ); break;
		}
	}
#else

I then spawn addr2line to get a human readable form. As you can imagine this
is horrid - and the spawned process is not necessarily going to start if
this process is badly crashing.

There's other issues with it as well - __builtin_return_address will not
take a variable as an argument - it has to be a hardcoded magic number!
(hence the switch statment). Also, if you use this too many times it will
generate a segment fault all of its very own (i.e. I go too far) :)

Still there may be some mileage for some of you in this approach.


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Mads
Bondo Dydensborg
Sent: 15 November 2001 09:21
To: Daniel Vogel
Cc: gam...@li...
Subject: RE: [GD-Linux] signals and exceptions


On Thu, 15 Nov 2001, Daniel Vogel wrote:

> > Shouldn't you be able to do this from a signal handler as well? I do
that,
> > although very simplistic. It adds a few extra stackframes, but those can
> > be ignored.
>
> We already have all this "nice" code doing this and printing out extended
> backtraces (together with extra information we put on the stack) that
relies
> on unwinding the stack and I thought I could easily get that to work on
> Linux without our current setjmp/ longjmp approach.
>
> Mind sharing your code? I guess I'm just a bit too confused now to see
> obvious solutions :)

I do not mind, but I warn you, it is extremely simplistic:

#ifdef HAVE_EXECINFO_H
#include <execinfo.h>
#endif

#include <iostream>

/* Dump a backtrace to cerr */
void BackTrace() {
#ifdef HAVE_EXECINFO_H
  cerr << "Dumping stacktrace" << endl;
  void *aTrace[32];
  char **tString;
  int size, i;
  size = backtrace(aTrace, 32);
  tString = backtrace_symbols(aTrace, size);
  for (i = 0; i < size; i++) {
    cerr << "In " << tString[i] << endl;;
  }
#else
  cerr << "No stacktrace available" << endl;
#endif
}


I told you it was simple :-)

My signal handler is then setup to call this function for certain signals.

The first couple of lines will be references to the signal handler, but
below that, is the usual stackframes.

I may have misunderstood your needs, and this may be entirely unusable for
you. It does help me though.

Mads

P.S. The HAVE_EXECINFO_H is define by autoconf for me - should be present
     on any system that uses glibc.

--
Mads Bondo Dydensborg.                               ma...@ch...
UNIX always presumes you know what you're doing. You're the human being,
after all, and it is a mere operating system.


_______________________________________________
Gamedevlists-linux mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux