Any interest for stack_trace?
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below: /***** sample.cpp *****/ #include <boost/stack_trace.hpp> #include <iostream> #include <sstream> using namespace boost; using namespace std; class exception_with_stack_trace : public exception { private: std::string what_; public: exception_with_stack_trace(const char* file, unsigned int line, const char* func) { stringstream ss; ss << "exception occurred at " << func << " (" << file << ":" << line << ")\n"; vector<stack_trace::element const *> const & st = stack_trace::get(); for(size_t i = st.size(); --i != 0; ) { ss << "\tfrom " << st[i]->tag() << " (" << st[i]->file() << ":" << st[i]->line() << ")\n"; } what_ = ss.str(); } virtual exception_with_stack_trace::~exception_with_stack_trace() throw (){} virtual const char * what() const throw () { return what_.c_str(); } }; void foo(int a) { BOOST_STACK_TRACK_CALL; cout << stack_trace::to_string() << endl; if(a == 1) { throw exception_with_stack_trace(__FILE__, __LINE__, __FUNCTION__); } } void foo() { BOOST_STACK_TRACK_CALL; foo(0); foo(1); cout << stack_trace::to_string() << endl; } void bar() { BOOST_STACK_TRACK_CALL; foo(); cout << stack_trace::to_string() << endl; } int main() { BOOST_STACK_TRACK_CALL; try { BOOST_STACK_TRACK_TAG("try"); foo(); cout << stack_trace::to_string() << endl; bar(); cout << stack_trace::to_string() << endl; } catch(exception& e) { cerr << e.what() << endl; } } /***** sample.cpp *****/ And run it to print below: 1> stdout sample.cpp 54 main sample.cpp 57 try sample.cpp 41 foo sample.cpp 32 foo sample.cpp 54 main sample.cpp 57 try sample.cpp 41 foo sample.cpp 32 foo 2> stderr exception occurred at foo (sample.cpp:36) from foo (sample.cpp:32) from foo (sample.cpp:41) from try (sample.cpp:57)
On 04/20/2007 12:04 PM, Atry wrote:
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below:
The trace_scope_stk template here: http://boost.cvs.sourceforge.net/boost-sandbox/boost-sandbox/boost/utility/trace_scope_stk.hpp?revision=1.1&view=markup is related. I've not used it in quite a while; so, the following description may not be entirely accurate. To use it, us must declare an instance of the template at each scope entry. When the program runs, it prints an indented message when entrying the scope and again when exiting the scope. The indentation reflects the depth of the call stack. The elements in the call stack are also stored in a stack which, I'd expect, you can print out somehow. Just from a brief glance at your code, it looks like you also have to put some code at the start of each scope entry and I guess the code pushes something onto the stack (line and file number) which can then be printed when an exception is thrown. It would be nice to merge these two.
Larry Evans 写道:
On 04/20/2007 12:04 PM, Atry wrote:
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below:
The trace_scope_stk template here:
is related. I've not used it in quite a while; so, the following description may not be entirely accurate. To use it, us must declare an instance of the template at each scope entry. When the program runs, it prints an indented message when entrying the scope and again when exiting the scope. The indentation reflects the depth of the call stack. The elements in the call stack are also stored in a stack which, I'd expect, you can print out somehow. Just from a brief glance at your code, it looks like you also have to put some code at the start of each scope entry and I guess the code pushes something onto the stack (line and file number) which can then be printed when an exception is thrown.
It would be nice to merge these two.
------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have seen trace_scope_stk, and I think it is another function. I did not print so many message at each entry/exit of each scope. I just record the call stack instead of writing anything. I am not care how user use these record. So I wrote exception_with_stack_trace in sample.hpp, assuming someone would use stack track information with exception. In my macro at start of each scope entry, it declare an static element. once the program enter the scope, it only push the pointer of the static element on the element stack. The element stack is a tss pointer, so it would work with multi-thread.
I upload it on vault http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Debug
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Atry Sent: Friday, April 20, 2007 10:05 AM To: boost@lists.boost.org Subject: [boost] Any interest for stack_trace?
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below:
Yes, I like it. It'd be very useful
/***** sample.cpp *****/ #include <boost/stack_trace.hpp> #include <iostream> #include <sstream> using namespace boost; using namespace std;
class exception_with_stack_trace : public exception { private: std::string what_; public: exception_with_stack_trace(const char* file, unsigned int line, const char* func) { stringstream ss; ss << "exception occurred at " << func << " (" << file << ":" << line << ")\n"; vector<stack_trace::element const *> const & st = stack_trace::get(); for(size_t i = st.size(); --i != 0; ) { ss << "\tfrom " << st[i]->tag() << " (" << st[i]->file() << ":" << st[i]->line() << ")\n"; } what_ = ss.str(); } virtual exception_with_stack_trace::~exception_with_stack_trace() throw (){} virtual const char * what() const throw () { return what_.c_str(); } };
void foo(int a) { BOOST_STACK_TRACK_CALL; cout << stack_trace::to_string() << endl; if(a == 1) { throw exception_with_stack_trace(__FILE__, __LINE__, __FUNCTION__); }
} void foo() { BOOST_STACK_TRACK_CALL; foo(0); foo(1); cout << stack_trace::to_string() << endl; } void bar() { BOOST_STACK_TRACK_CALL; foo(); cout << stack_trace::to_string() << endl; }
int main() { BOOST_STACK_TRACK_CALL; try { BOOST_STACK_TRACK_TAG("try"); foo(); cout << stack_trace::to_string() << endl; bar(); cout << stack_trace::to_string() << endl; } catch(exception& e) { cerr << e.what() << endl; } } /***** sample.cpp *****/
And run it to print below:
1> stdout sample.cpp 54 main sample.cpp 57 try sample.cpp 41 foo sample.cpp 32 foo
sample.cpp 54 main sample.cpp 57 try sample.cpp 41 foo sample.cpp 32 foo
2> stderr exception occurred at foo (sample.cpp:36) from foo (sample.cpp:32) from foo (sample.cpp:41) from try (sample.cpp:57)
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting. On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
Neal Becker wrote:
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
A stacktrace is helpful even without the demangling. In the worst case, one would have to run c++filt manually, which isn't that bad in a debugging scenario. Regards, m
Martin Wille writes:
Neal Becker wrote:
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
A stacktrace is helpful even without the demangling. In the worst case, one would have to run c++filt manually, which isn't that bad in a debugging scenario.
FWIW, GCC provides an API call that demangles names: something like "abi::__cxa_demangle", I don't remember the details. ---------------------------------------------------------------------- Dave Steffen, Ph.D. Fools ignore complexity. Software Engineer IV Pragmatists suffer it. Numerica Corporation Some can avoid it. ph (970) 461-2000 x227 Geniuses remove it. dgsteffen@numerica.us -- Alan Perlis
Dave Steffen wrote:
Martin Wille writes:
Neal Becker wrote:
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
A stacktrace is helpful even without the demangling. In the worst case, one would have to run c++filt manually, which isn't that bad in a debugging scenario.
FWIW, GCC provides an API call that demangles names: something like "abi::__cxa_demangle", I don't remember the details.
Yes. When we first discussed this, that function was missing, and we got bogged down trying to work around it, but as I said, this should no longer be an issue.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Martin Wille
A stacktrace is helpful even without the demangling. In the worst case, one would have to run c++filt manually, which isn't that bad in a debugging scenario.
There is no need to do that. Any platform that supports the Common Vendor ABI allows this via ::abi::__cxa_demangle. On gcc versions earlier than 3.x there used to be a function 'cplus_demangle'. I don't know whether that was supported on all OS's though. A long time ago, when this ML was still hosted on Yahoo, I uploaded example code for Solaris & Linux to do stack back traces (in mangled form). Steve Shammah also uploaded a version for Win32. http://tech.groups.yahoo.com/group/boost/files/StackTraces/ On a side-note, but related if you need to obtain a stack trace at the point of an exception, the CVABI also allow getting hold of the current exception type within a catch(...) block using ::abi::__cxa_current_exception_type.
Neal Becker wrote:
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
There's some code from long ago as well: http://tech.groups.yahoo.com/group/boost/files/StackTraces/ Jeff
On 4/20/07, Neal Becker <ndbecker2@gmail.com> wrote:
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
A couple of us were just looking into stack-traceing today! Both Visual Studio and gcc have helper functions for stack-tracing (without instrumenting). I want to use it when debugging threaded queuing and 'consumer/producer' patterns - I want (in debug only!) to attach a stack-trace to an item added to a queue - when the item is later picked up by another thread, I can look at the stack-trace to see 'who' queued it. I could just add a string-id to the queue items to give some idea of where it comes from, but the code is already written (ie same problem as instrumenting), and a stack-trace is what I really want anyhow. It really helps handle the general problem of tracing interactions between multiple threads. Tony
"Neal Becker" <ndbecker2@gmail.com> wrote in message news:f0atqv$t49$1@sea.gmane.org...
We discussed a couple of years back code to do tracebacks that did not require instrumenting, which IMO is much more interesting.
On linux/glibc, there is a function 'backtrace' that can help (libc manual, sec 33.1). We did talk about some code. Discussion bogged down on demangling symbols. At the time, the demangling code was not free (IIRC), but I think that is no longer a problem.
I've got the implementation almost ready as part on new portable debugging features of execution monitor. It wraps stck walking functionality of 3 different native interfaces. I am planning to put it into cvs and post an anouncement somewhere after BoostCon 2007 and 1.34.0 is out. Gennadiy
Gennadiy Rozental wrote:
"Neal Becker" <ndbecker2@gmail.com> wrote in message news:f0atqv$t49$1@sea.gmane.org...
I've got the implementation almost ready as part on new portable debugging features of execution monitor. It wraps stck walking functionality of 3 different native interfaces. I am planning to put it into cvs and post an anouncement somewhere after BoostCon 2007 and 1.34.0 is out.
Are you planning on submitting it as a library or is the plan to just leave it as an implementation detail in boost.test? Just asking b/c maybe the others will want to forge forward making this into a standalone lib. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:462A7368.6090408@crystalclearsoftware.com...
Gennadiy Rozental wrote:
"Neal Becker" <ndbecker2@gmail.com> wrote in message news:f0atqv$t49$1@sea.gmane.org...
I've got the implementation almost ready as part on new portable debugging features of execution monitor. It wraps stck walking functionality of 3 different native interfaces. I am planning to put it into cvs and post an anouncement somewhere after BoostCon 2007 and 1.34.0 is out.
Are you planning on submitting it as a library or is the plan to just leave it as an implementation detail in boost.test? Just asking b/c maybe the others will want to forge forward making this into a standalone lib.
For now this is implemented as separate header/implementation files and interfaces are used by the execution monitor. Depending on responce from the community we may consider to split it away. Gennadiy
AMDG Atry <pop.atry <at> gmail.com> writes:
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below:
When I wrote a stack_trace I had to use malloc/free because I was replacing global new/delete. I also wrote a perl script that inserts the macro at the beginning of every function. Also, is it possible to make it work with coroutines? http://tinyurl.com/362uv4 In Christ, Steven Watanabe
We are using sort of stack strace library in our project, and I think it would be great to have something like that in boost. Many responses talk about using build-in compiler's capabilities. IMHO they don't always help. As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs 1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request"); The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack. IMPLEMENTATION NOTES: 1) When exitting a function, the stack trace should be automatically notified. We did it by wrapping stack info with special class. 2) For multi-threaded application, separate stack should be kept for each thread. There need to be a way to initialize per-thread structures before using it. "Atry" <pop.atry@gmail.com> wrote in message news:f0arrv$lpp$1@sea.gmane.org...
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below: ...
I've also uploaded our version to Vault (same location: Debug). Maybe we can incorporate those versions together. The code on Vaulnt is not based on Boost libraries yet, and can't be compiled as stand-alone, but the concept should be clear. "Michael Gopshtein" <mgopshtein@gmail.com> wrote in message news:f1a64c$ce9$1@sea.gmane.org...
We are using sort of stack strace library in our project, and I think it would be great to have something like that in boost.
Many responses talk about using build-in compiler's capabilities. IMHO they don't always help.
As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs
1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request");
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack.
IMPLEMENTATION NOTES: 1) When exitting a function, the stack trace should be automatically notified. We did it by wrapping stack info with special class. 2) For multi-threaded application, separate stack should be kept for each thread. There need to be a way to initialize per-thread structures before using it.
"Atry" <pop.atry@gmail.com> wrote in message news:f0arrv$lpp$1@sea.gmane.org...
Java programs are easy to debug, one who catch an exception can print the stack trace, and when it crash, it would print the stack, too. It is useful, so I wrote some code of stack_trace for C++, see the sample below: ...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Many responses talk about using build-in compiler's capabilities. IMHO they don't always help.
As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs
1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request"); At least in gcc, you don't need to have an executable compiled in debug to use backtrace(). However with optimizations turned on, inline function might not appear on stack, of course. And omitting frame
On 5/2/07, Michael Gopshtein <mgopshtein@gmail.com> wrote: pointer would optimization would also make the tracing impossible.
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack. All you need to do, is collect the stack trace and the exception throw site, not in catch site. I.e. you could make an exception class, that will retrieve a stack trace in its constructor. The advantage on a native approach - is that it has zero overhead. Otherwise you introduce fairly heavy overhead into every function call, plus you can't get a stack entries in third-partly libs.
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :) -- Best regards, Zigmar
Pavel Antokolsky aka Zigmar wrote:
On 5/2/07, Michael Gopshtein <mgopshtein@gmail.com> wrote:
Many responses talk about using build-in compiler's capabilities. IMHO they don't always help.
As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs
1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request");
At least in gcc, you don't need to have an executable compiled in debug to use backtrace(). However with optimizations turned on, inline function might not appear on stack, of course. And omitting frame pointer would optimization would also make the tracing impossible.
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack.
All you need to do, is collect the stack trace and the exception throw site, not in catch site. I.e. you could make an exception class, that will retrieve a stack trace in its constructor. The advantage on a native approach - is that it has zero overhead. Otherwise you introduce fairly heavy overhead into every function call, plus you can't get a stack entries in third-partly libs.
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :)
Is it something like va_start/va_end?
"Pavel Antokolsky aka Zigmar" <zigmar@gmail.com> wrote in message news:b9e625b70705020806l1f5d8427ua4d7938596b89a4a@mail.gmail.com...
Many responses talk about using build-in compiler's capabilities. IMHO they don't always help.
As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs
1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request"); At least in gcc, you don't need to have an executable compiled in debug to use backtrace(). However with optimizations turned on, inline function might not appear on stack, of course. And omitting frame
On 5/2/07, Michael Gopshtein <mgopshtein@gmail.com> wrote: pointer would optimization would also make the tracing impossible.
When compiled in non-debug mode, I think that you can't get all context info. For example, using custom stack trace you can "change" the context in some locations inside the function. Besides, those "locations" can be given descriptive names, making it easy to understand the trace.
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack. All you need to do, is collect the stack trace and the exception throw site, not in catch site. I.e. you could make an exception class, that will retrieve a stack trace in its constructor.
This is a good solution, I agree, and can be incorporated with "custom" stack trace too.
The advantage on a native approach - is that it has zero overhead. Otherwise you introduce fairly heavy overhead into every function call, plus you can't get a stack entries in third-partly libs.
The overhead is no heavy, you also don't need to put trace functions at every place in the code, just in major functions. In our product the stack trace didn't cause any noticable regression in performance (and preformance is very important for us).
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :)
That could be interesting too, you can also handle cases of pointer parameters - by storing the data.
-- Best regards, Zigmar _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 02/05/07, Pavel Antokolsky aka Zigmar <zigmar@gmail.com> wrote:
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :)
How would you make that work properly with calling conventions that place a number of, or all of, the arguments in registers? Regards, Peter
Peter Bindels wrote:
On 02/05/07, Pavel Antokolsky aka Zigmar <zigmar@gmail.com> wrote:
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :)
How would you make that work properly with calling conventions that place a number of, or all of, the arguments in registers?
DWARF can describe that, so a tool that reads DWARF will have no problems. - Volodya
On 03/05/07, Vladimir Prus <ghost@cs.msu.su> wrote:
DWARF can describe that, so a tool that reads DWARF will have no problems.
I don't see how knowing the location of the arguments helps you retrieve it at the exit point or at the point of handling an exception. For that matter, the stack may have been changed as well.
Peter Bindels wrote:
On 03/05/07, Vladimir Prus <ghost@cs.msu.su> wrote:
DWARF can describe that, so a tool that reads DWARF will have no problems.
I don't see how knowing the location of the arguments helps you retrieve it at the exit point or at the point of handling an exception. For that matter, the stack may have been changed as well.
The part of Pavel's post you replied to did not say anything about where the stack trace is captured. I think it's only reasonable to capture stack trace at the point where it exists -- for example when throwing an exception, not when catching it. - Volodya
On 02/05/07, Michael Gopshtein <mgopshtein@gmail.com> wrote:
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack.
That's a neat idea. I'm guessing you keep an iterator into the container of calls, then on a return just decrement that iterator so you can see the full trace even after stack unwinding, then be able to throw away those calls when you next call a function? (Or something like that.) ~ Scott McMurray
me22 写道:
On 02/05/07, Michael Gopshtein <mgopshtein@gmail.com> wrote:
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack.
That's a neat idea.
I'm guessing you keep an iterator into the container of calls, then on a return just decrement that iterator so you can see the full trace even after stack unwinding, then be able to throw away those calls when you next call a function? (Or something like that.)
~ Scott McMurray _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Just dump the stack at the exception's constructor.
Just dump the stack at the exception's constructor. _______________________________________________
Yes, that's what Pavel Antokolsky has suggested too. I agree that it can be a good solution. The only limitation - you have to make sure all exceptions are derived from some special class, which is not possible for exceptions thrown from 3rd party libraries.
Michael Gopshtein 写道:
Just dump the stack at the exception's constructor. _______________________________________________
Yes, that's what Pavel Antokolsky has suggested too. I agree that it can be a good solution. The only limitation - you have to make sure all exceptions are derived from some special class, which is not possible for exceptions thrown from 3rd party libraries.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Try to catch the exception thrown from 3rd party libraries, and throw another one.
"Atry" <pop.atry@gmail.com> wrote in message news:4638E19D.7080408@gmail.com...
Michael Gopshtein ??:
Just dump the stack at the exception's constructor. _______________________________________________
Yes, that's what Pavel Antokolsky has suggested too. I agree that it can be a good solution. The only limitation - you have to make sure all exceptions are derived from some special class, which is not possible for exceptions thrown from 3rd party libraries.
Try to catch the exception thrown from 3rd party libraries, and throw another one.
Sure, but I didn't mean it's impossible, the whole intend is making the process easier. When in many places in the code you call external functions, you will need to have try-cach block in lot of functions. Sometimes you do want to catch specific types of exceptions, and to handle them properly. But if all you want is printing a stack trace when exception occurs, you'd ideally have single try-catch block in the 1st frame of each thread. Using custom stack trace, which remembers "history" of recent calls makes it possible.
"me22" <me22.ca@gmail.com> wrote in message news:fa28b9250705020844x39fb51e7s11356a63ef184436@mail.gmail.com...
On 02/05/07, Michael Gopshtein <mgopshtein@gmail.com> wrote:
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack.
That's a neat idea.
I'm guessing you keep an iterator into the container of calls, then on a return just decrement that iterator so you can see the full trace even after stack unwinding, then be able to throw away those calls when you next call a function? (Or something like that.)
Yes, that's exactly what it does. It basically keeps a list of call stacks, and 2 iterators: "current" and "maximal". When entering a function: current++; maximal=current. When leaving a function: current-- only. When exception is caught, the whole stack is printed, until the "maximal". The main problem with it to distinquish between the case where you return from the function normally, and the case of exception. On of solutions is Atry's and Pavel's suggestion: storing tha stack info in the constructor of exception object. Other option is to just set the "maximal" iterator in exception's constructor, to make sure we don't print extra functions.
~ Scott McMurray _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (16)
-
Atry -
Dave Steffen -
Gennadiy Rozental -
Gottlob Frege -
Jeff Garland -
Larry Evans -
Martin Wille -
me22 -
Michael Gopshtein -
Neal Becker -
Pavel Antokolsky aka Zigmar -
Peter Bindels -
Schalk_Cronje＠McAfee.com -
Steven Watanabe -
Suman Cherukuri -
Vladimir Prus