gamedevlists-linux — List for discussing game development on the linux platform

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> I use -export-dynamic or -Qoption,link,--export-dynamic for icc and it
> doesn't result in a meaningful backtrace. -rdynamic should be equivalent
> to -export-dynamic on Linux, right?

You have to have it for every dll and not just the main executeable - d'oh
:)

- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> I forgot to add, that you need to put the -rdynamic flag on you linker
> line, quite possible last on the line, to make it work.

I use -export-dynamic or -Qoption,link,--export-dynamic for icc and it
doesn't result in a meaningful backtrace. -rdynamic should be equivalent
to -export-dynamic on Linux, right?

- Daniel Vogel, Programmer, Epic Games Inc.

Re: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Fri, 16 Nov 2001, Steve Baker wrote:

> (Hmmm: There don't seem to be any 'man' pages for 'backtrace()'
> and 'backtrace_symbols()')

Bert Freudenberg posted an url to the man pages. Embarrisingly enough the
code I posted seems to have an error - I am not freeing the strings.

> 
> Is there any way to get the stack backtrace to show line numbers like
> gdb does?

Under Linux there are the two programs c++filt (to demangle c++ names) and
addr2line which is part of the binutils. I suppose you could use the
backtrace function that writes to a file descriptor, or write a script
that takes the data as input. Depends on your settings, really.

I have no experience under other platforms.

Since gdb can do this under all supported platforms (I believe) I suppose
there are code in gdb to handle this in an uniform way. One should be able
to build a library or similar to link into ones applications to get this
kind of information on demand/crashes. (For all I know, such a library may
already exist).

The above is enough for me at the moment though, so I will leave that to
someone else ;-)

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
The University of North Carolina has finally found a network server that,
although missing for four years, hasn't missed a packet in all that time.
Try as they might, university administrators couldn't find the server.
Working with Novell Inc. (stock: NOVL), IT workers tracked it down by
meticulously following cable until they literally ran into a wall. The
server had been mistakenly sealed behind drywall by maintenance workers.
                       - Techweb, 20010409

Re: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Fri, 16 Nov 2001, Bert Freudenberg wrote:

> On Fri, 16 Nov 2001, Steve Baker wrote:
> 
> > "D. Stimits" wrote:
> > 
> > > Would it be possible to see what is in the backtrace() and
> > > backtrace_symbols() functions?
> > 
> > They appear to be standard (but undocumented) glibc functions.
> 
> They're in the GLIBC manual:
> 
> http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_33.html

Great!

Note: Turns out that the code I posted has an error - it does not free the
strings...

Everybody interessted obviously should go read that url, and use the
(hopefully) correct code there.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
You may not use the Software in connection with any site that disparages
Microsoft, MSN, MSNBC, Expedia, or their products or services, infringe any
intellectual property or other rights of these parties, violate any state,
federal or international law, or promote racism, hatred or pornography. 
                                     - Part of MS Frontpage 2002 EULA

Re: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Thu, 15 Nov 2001, D. Stimits wrote:

> > I just compiled that code snippet as-is and called it from somewhere
> > deeply nested in my code - and it dumped out the filename, function
> > name and ugly hex offset into the function for the most recent 32
> > functions on the stack!
> 
> Can you tell me what compiler flags you used? I created a simple program
> to test this, I used "-Wall -g", but it seems to only give hex offsets:
> Traced: ./deleteme(__eh_alloc+0x1b2) [0x804896e]
> Traced: ./deleteme(__eh_alloc+0x2af) [0x8048a6b]
> Traced: ./deleteme(__eh_alloc+0x299) [0x8048a55]
> Traced: ./deleteme(__eh_alloc+0x27d) [0x8048a39]
> Traced: ./deleteme(__eh_alloc+0x261) [0x8048a1d]
> Traced: ./deleteme(__eh_alloc+0x14c) [0x8048908]
> Traced: /lib/i686/libc.so.6(__libc_start_main+0x93) [0x400ae177]
> Traced: ./deleteme(__eh_alloc+0x35) [0x80487f1]
> 
> My executable was named "deleteme" to remind me to remove it if I
> forget, so it obviously got the file name right for the executable, but
> the actual source was "db_display.cpp". All of my function calls are
> listed in stripped form. Was there something you used to get the name of
> functions rather than my uglier format?

I forgot to add, that you need to put the -rdynamic flag on you linker
line, quite possible last on the line, to make it work.

See my answer to Steve Baker for line stuff.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world.

                                        - Seen on Linux Kernel mailing list

Re: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Thu, 15 Nov 2001, D. Stimits wrote:


> > 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);
> 
> Would it be possible to see what is in the backtrace() and
> backtrace_symbols() functions?

Ehm, this is part of the glibc code. It should be quite easy to download
from e.g. www.gnu.org

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
When a single line of script in Linux can do things that'd keep you 
pointing-and-clicking forever in Windows, you have great motivation to learn 
that line of script.
                                        - Chris Worth on The Microsoft Matrix

Re: [GD-Linux] signals and exceptions

[Bert F. <be...@is...>]

On Fri, 16 Nov 2001, Steve Baker wrote:

> "D. Stimits" wrote:
> 
> > Would it be possible to see what is in the backtrace() and
> > backtrace_symbols() functions?
> 
> They appear to be standard (but undocumented) glibc functions.

They're in the GLIBC manual:

http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_33.html

> It's *magic*  :-)

Indeed :)

-- Bert

Re: [GD-Linux] watch/awatch?

[Ryan C. G. <ic...@cl...>]

(Said Steve Baker in an email presumably meant for the list:  :)  )
> It's a long-shot but yaybe the compiler optimised out all those
> useless assignments?


0x80483c6 <main+6>:	movl   $0x5,0xfffffffc(%ebp)
0x80483cd <main+13>:	movl   $0xa,0xfffffffc(%ebp)
0x80483d4 <main+20>:	movl   $0xf,0xfffffffc(%ebp)

They are definitely there.

I'm willing to believe that my GDB is old/buggy/miscompiled, since Daniel
is having more luck than I. I'll try a CVS version of GDB later and report
back. I remember having miseries with this when working on Descent3, too,
though...it will definitely be nice to be able to track an arbitrary chunk
of memory though a jazillion lines of code, though.

--ryan.

RE: [GD-Linux] watch/awatch?

[Daniel V. <vo...@ep...>]

Works fine here with GNU gdb 20010813 (MI_OUT) which comes with Mandrake
8.1.

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of Ryan
> C. Gordon
> Sent: Friday, November 16, 2001 1:55 AM
> To: gam...@li...
> Subject: [GD-Linux] watch/awatch?
>
>
>
> Has anyone actually gotten "watch", "rwatch" or "awatch" to work on
> GDB/Linux/x86?
>
> These commands seem to be to be broken/useless in gdb 5.0, but maybe I'm
> just using them wrong...?
>
> for example:
>
> #include <stdio.h>
>
> int main(void)
> {
>     int x;
>
>     x = 5;
>     x = 10;
>     x = 15;
>
>     return(0);
> }
>
> Compile:
>
>    gcc -g -o ./x ./x.c
>    gdb ./x
>
>
>    b main
>    r
>    watch x != 5
>    c
>
> Doesn't stop until main returns.
>
> (*shrug*)
>
> --ryan.
>
>
>
>
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>

[GD-Linux] watch/awatch?

[Ryan C. G. <ic...@cl...>]

Has anyone actually gotten "watch", "rwatch" or "awatch" to work on
GDB/Linux/x86?

These commands seem to be to be broken/useless in gdb 5.0, but maybe I'm
just using them wrong...?

for example:

#include <stdio.h>

int main(void)
{
    int x;

    x = 5;
    x = 10;
    x = 15;

    return(0);
}

Compile:

   gcc -g -o ./x ./x.c
   gdb ./x


   b main
   r
   watch x != 5
   c

Doesn't stop until main returns.

(*shrug*)

--ryan.

Re: [GD-Linux] signals and exceptions

[D. S. <st...@id...>]

Steve Baker wrote:
> 
> "D. Stimits" wrote:
> 
> > Would it be possible to see what is in the backtrace() and
> > backtrace_symbols() functions?
> 
> They appear to be standard (but undocumented) glibc functions.

So I see.

> 
> I just compiled that code snippet as-is and called it from somewhere
> deeply nested in my code - and it dumped out the filename, function
> name and ugly hex offset into the function for the most recent 32
> functions on the stack!

Can you tell me what compiler flags you used? I created a simple program
to test this, I used "-Wall -g", but it seems to only give hex offsets:
Traced: ./deleteme(__eh_alloc+0x1b2) [0x804896e]
Traced: ./deleteme(__eh_alloc+0x2af) [0x8048a6b]
Traced: ./deleteme(__eh_alloc+0x299) [0x8048a55]
Traced: ./deleteme(__eh_alloc+0x27d) [0x8048a39]
Traced: ./deleteme(__eh_alloc+0x261) [0x8048a1d]
Traced: ./deleteme(__eh_alloc+0x14c) [0x8048908]
Traced: /lib/i686/libc.so.6(__libc_start_main+0x93) [0x400ae177]
Traced: ./deleteme(__eh_alloc+0x35) [0x80487f1]

My executable was named "deleteme" to remind me to remove it if I
forget, so it obviously got the file name right for the executable, but
the actual source was "db_display.cpp". All of my function calls are
listed in stripped form. Was there something you used to get the name of
functions rather than my uglier format?

D. Stimits, st...@id...

> 
> It's *magic*  :-)
> 
> ----------------------------- Steve Baker -------------------------------
> Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
> URLs : http://www.sjbaker.org
>        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
>        http://prettypoly.sf.net http://freeglut.sf.net
>        http://toobular.sf.net   http://lodestone.sf.net

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

Awesome - so I can easily switch to use this approach on Linux. A little bit
different functionality but way better than nothing.

I already love this list :)

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Steve Baker
> Sent: Friday, November 16, 2001 1:35 AM
> To: st...@id...
> Cc: gam...@li...
> Subject: Re: [GD-Linux] signals and exceptions
>
>
> "D. Stimits" wrote:
>
> > Would it be possible to see what is in the backtrace() and
> > backtrace_symbols() functions?
>
> They appear to be standard (but undocumented) glibc functions.
>
> I just compiled that code snippet as-is and called it from somewhere
> deeply nested in my code - and it dumped out the filename, function
> name and ugly hex offset into the function for the most recent 32
> functions on the stack!
>
> It's *magic*  :-)
>
> ----------------------------- Steve Baker -------------------------------
> Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
> URLs : http://www.sjbaker.org
>        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
>        http://prettypoly.sf.net http://freeglut.sf.net
>        http://toobular.sf.net   http://lodestone.sf.net
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>

Re: [GD-Linux] signals and exceptions

[Mark C. <m.c...@co...>]

On Friday 16 November 2001  6:34 am, you wrote:
> "D. Stimits" wrote:
> > Would it be possible to see what is in the backtrace() and
> > backtrace_symbols() functions?
>
> They appear to be standard (but undocumented) glibc functions.
>
> I just compiled that code snippet as-is and called it from somewhere
> deeply nested in my code - and it dumped out the filename, function
> name and ugly hex offset into the function for the most recent 32
> functions on the stack!
>
> It's *magic*  :-)
>

Where as Windows has the *evil* StackWalk() function...

grrrrr

Nurgle

Re: [GD-Linux] signals and exceptions

[Steve B. <sjb...@ai...>]

"D. Stimits" wrote:

> Would it be possible to see what is in the backtrace() and
> backtrace_symbols() functions?

They appear to be standard (but undocumented) glibc functions.

I just compiled that code snippet as-is and called it from somewhere
deeply nested in my code - and it dumped out the filename, function
name and ugly hex offset into the function for the most recent 32
functions on the stack!

It's *magic*  :-)

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [GD-Linux] signals and exceptions

[Mark C. <m.c...@co...>]

On Friday 16 November 2001 12:10 am, Daniel Vogel wrote:
<snip>

A quick tip unrelated to the problem... if you add high-resolution timing, 
you can use those "guard" and "unguard" macros to add some very simple 
profiling to your app...

Nurgle

Re: [GD-Linux] signals and exceptions

[Steve B. <sjb...@ai...>]

Mads Bondo Dydensborg wrote:

> 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
> }
> 

Oooh!  That's *really* useful.  At work I'm working on a package where
one program exec's other programs - and they are all forking lots of
threads.  Debugging with GDB is *really* hard - but just getting a
stack backtrace 'on demand' is a very helpful debug aid.

(Hmmm: There don't seem to be any 'man' pages for 'backtrace()'
and 'backtrace_symbols()')

Is there any way to get the stack backtrace to show line numbers like
gdb does?

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

Okay, here's the Windows define for our "guard" code.

#define guard(func)			\
	{static const TCHAR __FUNC_NAME__[]=TEXT(#func); try{
#define unguard				\
	}catch(TCHAR*Err){throw
Err;}catch(...){appUnwindf(TEXT("%s"),__FUNC_NAME__); throw;}}
#define unguardf(msg)			\
	}catch(TCHAR*Err){throw Err;} \
	catch(...){appUnwindf(TEXT("%s"),__FUNC_NAME__); appUnwindf msg; throw;}}

and here is a sample function that uses it.

void SomeFunction()
{
	guard(SomeFunction);
	INT SomeVariable = 0;
	// Do something with SomeVariable
	unguardf(( TEXT("SomeVariable = %i"), SomeVariable ));
}

So you can get all sorts of extra information and text messages with this
approach which is nice as it is part of release builds and you therefore get
very precise crash reports from artists. This is a powerful tool if you hook
it up to a bug tracking system though sometimes it can lead to very
confusing (for non programmers) bug reports :)

http://www.shacknews.com/screens.x/iotd//9/thumbs/deuserror.jpg


- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of D.
> Stimits
> Sent: Thursday, November 15, 2001 6:53 PM
> Cc: gam...@li...
> Subject: Re: [GD-Linux] signals and exceptions
>
>
> 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.
>
> I am curious what kind of extra information you were dumping, aside from
> stack frame and arguments? And what means you were using to track these
> extra items (beyond function names)?
>
> D. Stimits, st...@id...
>
> >
> > Mind sharing your code? I guess I'm just a bit too confused now to see
> > obvious solutions :)
> >
> > - Daniel Vogel, Programmer, Epic Games Inc.
> >
> > _______________________________________________
> > Gamedevlists-linux mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
>

Re: [GD-Linux] signals and exceptions

[D. S. <st...@id...>]

Mads Bondo Dydensborg wrote:
> 
> 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);

Would it be possible to see what is in the backtrace() and
backtrace_symbols() functions?

D. Stimits, st...@id...

>   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

Re: [GD-Linux] signals and exceptions

[D. S. <st...@id...>]

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.

I am curious what kind of extra information you were dumping, aside from
stack frame and arguments? And what means you were using to track these
extra items (beyond function names)?

D. Stimits, st...@id...

> 
> Mind sharing your code? I guess I'm just a bit too confused now to see
> obvious solutions :)
> 
> - Daniel Vogel, Programmer, Epic Games Inc.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

RE: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Thu, 15 Nov 2001, Hal Angseesing wrote:

> That's a bit more elegant than the solution I came up with. 

Thanks, but I copied from somewhere on the web, so credit should go
somewhere else (lost the reference though).

> 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.

I didn't know about that prog. I did know about c++filt - but I have
choosen not to try and be too clever, precisly because the program may be
in a very bad state. 

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

Definitly. 

"Someone" should build a library to make this kind of debugging
easier. Obviously the code is in the binutils...

Hmm.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
A series on the annoying idiosyncrasies of popular programs such as Windows, 
Word and Excel features irritating or irritated animals. Word 97 Annoyances 
sports a decidedly miffed opossum, while Windows 98 Annoyances gets a European
common toad, covered with warts.
                         - Elizabeth Weise, USA TODAY, on O'Reilly bookcovers

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

RE: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

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. 

RE: [GD-Linux] signals and exceptions

[Daniel V. <vo...@ep...>]

> 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 :)

- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-Linux] signals and exceptions

[Mads B. D. <ma...@ch...>]

On Wed, 14 Nov 2001, Daniel Vogel wrote:

> > It depends a lot on what you want to accomplish and whether you are
> > using threads.
> 
> We just use exceptions to print out a meaningful stack backtrace when the
> game crashes and it relies on unwinding the stack as every function has it's
> name in ASCII on the stack.

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.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
In a stinging rebuke, a federal judge Monday ruled Microsoft Corp. violated
the nation's antitrust laws by using its monopoly power in personal computer
operating systems to stifle competition.
                        - CNN Financial News April 03, 2000: 7:53 p.m. ET

RE: [GD-Linux] signals and exceptions

[Ryan C. G. <ic...@cl...>]

> I doubt that as the compiler is free to use EBP as it pleases - for example
> as an additional general purpose register for optimizations.

gcc -fno-omit-frame-pointer

> > signal handler in any sort of meaningful way? Did I mention there's no
> > clean, portable way to do this?  :)
>
> Ah, I'm really looking forward to add Unicode support ;)

I'm always for hire.  :)

--ryan.