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

[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

[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

[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

[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

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

Daniel Vogel wrote:
> 
> > 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.
> 
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux

If I recall correctly, rdynamic is symbol support for relocateable code
in general. Normally you wouldn't need it except when dynamically
linking; I suspect it performs some kind of utility aid for the
debugging functions that works in just the same way as dlopen would use
it.

Now maybe someone could answer this; I added -rdynamic and it improved
the output by naming functions, but the arguments to the function were
still not useful, they still look like offsets rather than what my
sample had (like calling a function with an int of 1, then 2, then 3, so
on...and showing up as something far different). Is there some way to
expand on this debugging to get even more information, such as local
variable values and formatted (meaningful) argument call values?

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

Re: [GD-Linux] signals and exceptions

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

On Fri, 16 Nov 2001, D. Stimits wrote:

> Now maybe someone could answer this; I added -rdynamic and it improved
> the output by naming functions, but the arguments to the function were
> still not useful, they still look like offsets rather than what my
> sample had (like calling a function with an int of 1, then 2, then 3, so
> on...and showing up as something far different). Is there some way to
> expand on this debugging to get even more information, such as local
> variable values and formatted (meaningful) argument call values?

I am sorry I do not know the answer to your question. gdb can do this, so
I suppose there is a way to do it, although I do not know if there are any
built in functions you can use.

I did write a simple perl script to demangle c++ names and get file:line
information, which follows here:

#!/usr/bin/perl -w
 
# Get the program name for the addr2line program
$program = shift(@ARGV);
 
if (!defined $program || "" eq $program) {
    print STDERR "Usage: $0 <program>\n";
    exit 1;
}
 
while(<>) {
    if (m/\((.+)\+0x[[:xdigit:]]+\) \[(0x[[:xdigit:]]+)\]/) {
        $function = `c++filt $1`;
        chop($function);
        $line = `addr2line -e $program $2`;
        chop($line);
        print "$function ($line)\n";
    } else {
        print STDERR "Warning: No match for $_";
    }
}

Maybe it can be useful to you (or someone else).

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
A few months ago, I was talking to Raymond on the phone, when I called a
computer criminal a "hacker" instead of a "cracker." He hung up on me.

                               - John Marcotte

RE: [GD-Linux] signals and exceptions

[Michael R. <mi...@sw...>]

I suspect what is needed may be found in GNU binutils, but you'll have to do
some hunting.

See demangle.h for cplus_demangle, anyhow.

regards,

~m

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of Mads
> Bondo Dydensborg
> Sent: Saturday, November 17, 2001 2:55 AM
> To: D. Stimits
> Cc: gam...@li...
> Subject: Re: [GD-Linux] signals and exceptions
>
>
> On Fri, 16 Nov 2001, D. Stimits wrote:
>
> > Now maybe someone could answer this; I added -rdynamic and it improved
> > the output by naming functions, but the arguments to the function were
> > still not useful, they still look like offsets rather than what my
> > sample had (like calling a function with an int of 1, then 2, then 3, so
> > on...and showing up as something far different). Is there some way to
> > expand on this debugging to get even more information, such as local
> > variable values and formatted (meaningful) argument call values?
>
> I am sorry I do not know the answer to your question. gdb can do this, so
> I suppose there is a way to do it, although I do not know if there are any
> built in functions you can use.
>
> I did write a simple perl script to demangle c++ names and get file:line
> information, which follows here:

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.