Thread: RE: [GD-Linux] signals and exceptions
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-linux
|
From: Daniel V. <vo...@ep...> - 2001-11-14 19:46:51
|
> The problem is not the printf. The problem is that memory violations do > not generate exceptions, they generate a signal. Check man -a signal; > trap SIGSEGV. Yes, I'm painfully aware of that fact and am wondering whether there were a way to make that work cleanly. I thought about throwing an exception in a signal handler but doubt that'll work fine and I guess it's going to create weird side effects. At the moment we use setjmp/longjmp from within signal handlers to emulate exceptions and it's a considerable performance impact (I took it out for the UT Linux versions I worked on) whereof the exception equivalent is virtually free on Windows. BTW, I get a lot of email sent to me privately and I simply assume it's meant to be for the list in my replies so add a <private reply> or whatever somewhere to your replies if you don't want me to reply to your message to the list :) - Daniel Vogel, Programmer, Epic Games Inc. |
|
From: Daniel V. <vo...@ep...> - 2001-11-14 20:26:02
|
> The underlying memory violation is part of the glibc libraries, and does
> not originate from the application itself, so a general means of
> converting to an exception won't happen. How you deal with it might
> depend on whether you are using threads or not. In the case of threads,
> you'd mask all but one thread to not catch signals; likely the main
> thread would do signal handling. Regardless, you do not want to mix
> signal handling with exceptions without being very careful. So one
> question is whether you are using threads, and a second question is what
> you want to do when this signal is sent...can you live with abandoning
> the current thread or function? I see you're trying to catch and work
> with the exception within the sample function (which is just main() in
> this case), but in actual use, will that be needed? You could create a
> global or per-thread state object, have your signal handler set this,
> and instead of try/catch, just have your blocks:
> { // NOTE: no "try".
> ...general stuff that might have SIGSEGV...
> // if something goes wrong, signal handler sets oSigState.
> }
> oSigState.mRethrow();
>
> (where rethrow() does nothing if a mapping does not exist between a
> particular signal and a substitute exception; you could take it further
> and allow specification of signals, e.g., oSigState.mRethrow(SIGSEGV),
> which would ignore any signal state other than SIGSEGV)
>
> 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.
Thanks for all your suggestions (D.Stimits, Mark Collins) - I'll look into
this a bit further and let you know how it goes. I finally want to get rid
of all the ugly code in the Linux code and this and Unicode support are the
two things on my plate.
> My "reply-to" button just lists your address, not the list. Plus, I'm
> subscribed to the gd algo and opengl lists, and this is arriving and
> being sent to my general sourceforge box, since I don't have a rule for
> general "gamedevlists-linux" (I should, I love linux game dev, it's
> about all I do).
I'll simply keep sending my replies to the list.
> D. Stimits, st...@id...
- Daniel Vogel, Programmer, Epic Games Inc.
|
|
From: D. S. <st...@id...> - 2001-11-14 22:30:18
|
Daniel Vogel wrote:
>
> > The underlying memory violation is part of the glibc libraries, and does
> > not originate from the application itself, so a general means of
> > converting to an exception won't happen. How you deal with it might
> > depend on whether you are using threads or not. In the case of threads,
> > you'd mask all but one thread to not catch signals; likely the main
> > thread would do signal handling. Regardless, you do not want to mix
> > signal handling with exceptions without being very careful. So one
> > question is whether you are using threads, and a second question is what
> > you want to do when this signal is sent...can you live with abandoning
> > the current thread or function? I see you're trying to catch and work
> > with the exception within the sample function (which is just main() in
> > this case), but in actual use, will that be needed? You could create a
> > global or per-thread state object, have your signal handler set this,
> > and instead of try/catch, just have your blocks:
> > { // NOTE: no "try".
> > ...general stuff that might have SIGSEGV...
> > // if something goes wrong, signal handler sets oSigState.
> > }
> > oSigState.mRethrow();
> >
> > (where rethrow() does nothing if a mapping does not exist between a
> > particular signal and a substitute exception; you could take it further
> > and allow specification of signals, e.g., oSigState.mRethrow(SIGSEGV),
> > which would ignore any signal state other than SIGSEGV)
> >
> > 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.
A core dump will accomplish this as well, but has problems when there
are no debug symbols (stripped end user code), or when multiple threads
are in use and you need to distinguish threads. You might be interested
in your signal handler running ptrace within your signal handler if you
want customization.
D. Stimits, st...@id...
>
> Thanks for all your suggestions (D.Stimits, Mark Collins) - I'll look into
> this a bit further and let you know how it goes. I finally want to get rid
> of all the ugly code in the Linux code and this and Unicode support are the
> two things on my plate.
>
> > My "reply-to" button just lists your address, not the list. Plus, I'm
> > subscribed to the gd algo and opengl lists, and this is arriving and
> > being sent to my general sourceforge box, since I don't have a rule for
> > general "gamedevlists-linux" (I should, I love linux game dev, it's
> > about all I do).
>
> I'll simply keep sending my replies to the list.
>
> > D. Stimits, st...@id...
>
> - Daniel Vogel, Programmer, Epic Games Inc.
>
> _______________________________________________
> Gamedevlists-linux mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
|
|
From: Daniel V. <vo...@ep...> - 2001-11-15 00:16:55
|
> A core dump will accomplish this as well, but has problems when there > are no debug symbols (stripped end user code), or when multiple threads > are in use and you need to distinguish threads. You might be interested > in your signal handler running ptrace within your signal handler if you > want customization. Thanks for the pointer. I'll keep it in mind though at the moment I'll stick with our setjmp/longjmp solution for debugging as it outputs much more data than a normal backtrace provides. Still annoying that exceptions and signals don't work together - especially since this is so elegantly done on Windows. - Daniel Vogel, Programmer, Epic Games Inc. |
|
From: D. S. <st...@id...> - 2001-11-15 00:48:12
|
Daniel Vogel wrote: > > > A core dump will accomplish this as well, but has problems when there > > are no debug symbols (stripped end user code), or when multiple threads > > are in use and you need to distinguish threads. You might be interested > > in your signal handler running ptrace within your signal handler if you > > want customization. > > Thanks for the pointer. I'll keep it in mind though at the moment I'll stick > with our setjmp/longjmp solution for debugging as it outputs much more data > than a normal backtrace provides. Still annoying that exceptions and signals > don't work together - especially since this is so elegantly done on Windows. They could be made to work together, but then you'd really have to worry about whether you did it right, and the system of making various parts "atomic" would lead to a lot of overhead you already don't want. The thing is that the underlying libc of linux and all UNIX is old C-based, and did not have the concept of exceptions built in to it. It makes the system itself rather stable and low overhead (had linux been C++ based, bootup support would be massive in comparison with what it is now), but isn't very friendly to exceptions. D. Stimits, st...@id... > > - Daniel Vogel, Programmer, Epic Games Inc. > > _______________________________________________ > Gamedevlists-linux mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux |
|
From: Ryan C. G. <ic...@cl...> - 2001-11-15 01:37:14
|
> Thanks for the pointer. I'll keep it in mind though at the moment I'll stick > with our setjmp/longjmp solution for debugging as it outputs much more data > than a normal backtrace provides. Still annoying that exceptions and signals > don't work together - especially since this is so elegantly done on Windows. I've been tickering with throwing from a signal handler, and have decided that not only can it not be done, it probably shouldn't be done. glibc's throw_helper() function (where throws end up) fires SIGABRT if you try to throw inside a SIGSEGV handler. I presume they are trying to be helpful, but then again, I'm not sure that signals run in the same context (for lack of a better term) on all architectures; that is, a "backtrace" might be nonexistant on some platforms while in the signal handler. It's just a fact of life: there is not going to be a clean and portable way to do this. On Intel linux, I wonder if you could just work back from %%ebp from a signal handler in any sort of meaningful way? Did I mention there's no clean, portable way to do this? :) --ryan. |
|
From: Daniel V. <vo...@ep...> - 2001-11-15 01:54:58
|
> It's just a fact of life: there is not going to be a clean and portable > way to do this. C++, the object- oriented programming language of a pagan deity. > On Intel linux, I wonder if you could just work back from %%ebp from a I doubt that as the compiler is free to use EBP as it pleases - for example as an additional general purpose register for optimizations. > 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 ;) - Daniel Vogel, Programmer, Epic Games Inc. |
|
From: Ryan C. G. <ic...@cl...> - 2001-11-15 06:30:04
|
> 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. |
|
From: Mads B. D. <ma...@ch...> - 2001-11-15 08:30:58
|
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
|
|
From: Daniel V. <vo...@ep...> - 2001-11-15 08:39:59
|
> 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. |
|
From: Mads B. D. <ma...@ch...> - 2001-11-15 09:20:44
|
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.
|
|
From: Hal A. <ha...@cl...> - 2001-11-15 09:44:01
|
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
|
|
From: Mads B. D. <ma...@ch...> - 2001-11-15 10:02:20
|
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
|
|
From: D. S. <st...@id...> - 2001-11-15 23:56:05
|
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
|
|
From: Steve B. <sjb...@ai...> - 2001-11-16 00:41:05
|
"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 |
|
From: Mark C. <m.c...@co...> - 2001-11-16 00:46:58
|
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 |
|
From: D. S. <st...@id...> - 2001-11-16 05:28:59
|
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 |
|
From: Mads B. D. <ma...@ch...> - 2001-11-16 11:19:46
|
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
|
|
From: Bert F. <be...@is...> - 2001-11-16 08:49:15
|
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 |
|
From: Mads B. D. <ma...@ch...> - 2001-11-16 11:22:32
|
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 |
|
From: Mads B. D. <ma...@ch...> - 2001-11-16 11:09:30
|
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
|
|
From: Steve B. <sjb...@ai...> - 2001-11-16 00:31:53
|
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
|
|
From: Mads B. D. <ma...@ch...> - 2001-11-16 11:29:31
|
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
|
|
From: Jan E. <ch...@in...> - 2001-11-26 15:05:06
|
Hi all,
I have a small problem that my brain just can't work out. Being pretty
useless at maths I thought about asking here, maybe someone has done
something similar.
I have a 3D scene in which a "camera" glides over the terrain in normal
FPS mode. The terrain is a normal 2D matrix of y-values, with the x- and
z-coordinates spread evenly, i.e. a perfectly regular matrix. This works
fine, and I take the y-coordinate for the camera (height above the
terrain) from the matrix. So, if the camera is at (x,z) I get the camera
height from something like this:
=09height =3D map [int(x)][int(y)]
This of course gets me the height of the lower corner of the current
"tile". Some helpful ascii art:
|D |C |
--+--------+--------+--
| | |
| X | |
| | |
|A |B |
--+--------+--------+--
| | |
| | |
| | |
| | |
--+--------+--------+--
| |=A0 |
So if the camera is at X the idea above gives me that that camera should
have the height at point A in the map as long as the camera is in that
tile. If it moves on tile to the right it gets the height of point B. This
gives a camera that is jerky, especielly if the heights in A,B,C and D
differ even slightly. The correct way would thus be to interpolate the
heights of all the points somehow, so that the camera would "flow"
smoothly over the tile. Any ideas on how to do this? If the tiles were
much smaller that problem would not exist, but my tiles are quite big.
I've tried to STFW, but I don't really know what to look for. Anyone got
some pointers to some nice math that I could use, or have done this
before?
Regards,
Chakie
--=20
"Students?" barked the Archchancellor.
"Yes, Master. You know? They're the thinner ones with the pale faces?
Because we're a university? They come with the whole thing, like rats --"
-- Terry Pratchett, Moving Picture=
s
|
|
From: Eero P. <epa...@ko...> - 2001-11-26 18:08:29
|
Jan Ekholm wrote: > I have a 3D scene in which a "camera" glides over the terrain in normal > FPS mode. The terrain is a normal 2D matrix of y-values, with the x- and > z-coordinates spread evenly, i.e. a perfectly regular matrix. This works > fine, and I take the y-coordinate for the camera (height above the > terrain) from the matrix. So, if the camera is at (x,z) I get the camera > height from something like this: > > height = map [int(x)][int(y)] > ........... > So if the camera is at X the idea above gives me that that camera should > have the height at point A in the map as long as the camera is in that > tile. If it moves on tile to the right it gets the height of point B. This > gives a camera that is jerky, especielly if the heights in A,B,C and D > differ even slightly. The correct way would thus be to interpolate the > heights of all the points somehow, so that the camera would "flow" > smoothly over the tile. Any ideas on how to do this? If the tiles were > much smaller that problem would not exist, but my tiles are quite big. > > I've tried to STFW, but I don't really know what to look for. Anyone got > some pointers to some nice math that I could use, or have done this > before? If I understood you question correctly (and also the FLA).... The simplest solution I guess is to use bilinear interpolation. Google can help with the details. Eero |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X