Is there interest in a collection of call stack utilities?
Hello, I have a collection of debugging/diagnostic utilities to inspect the run-time call stack and to resolve symbol information. The tools are currently C++11 code and support GNU-Linux and Windows. An overview is available at https://freeshell.de//~amelinte/call_stack_usage.html Is there interest for potential inclusion in boost? Thanks, Aurelian
Hello, This thread reminds me the following thread I had started: http://thread.gmane.org/gmane.comp.lib.boost.devel/209982 Also the code had improved since than: https://sourceforge.net/p/cppcms/code/2238/tree/framework/trunk/booster/boos... https://sourceforge.net/p/cppcms/code/2238/tree/framework/trunk/booster/lib/... Several notes: bfd library is GPL license which would be a major drawback. Also I noticed that you use mostly glibc's backtrace. I don't know at what level your code is gblic specific but backtrace is avalible on many platforms like Solaris and latests Mac OS X's You can also use _Unwind_Backtrace function that is much widely supported. Also on some platforms backtrace provided by libexec (like FreeBSD) is quite broken. Additionally I noticed that you use ::StackWalk64 AFAIK it is not thread safe function. I see that you wrap everything with a mutex which makes the library much slower. I'd suggest to use RtlCaptureStackBackTrace instead. You can also utilize function like backtrace_symbols. AFAIR not every platform has dladdr (Solaris if I recall correctly) Generally it is very interesting topic and very useful stuff (from my experience in deploy with CppCMS). I'd suggest: 1. Take a look on my code, you probably can improve platform support 2. Try to integrate the code with throwing an exception which would make it much more useful. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/ ----- Original Message -----
From: Aurelian Melinte <ame01@gmx.net> To: boost@lists.boost.org Cc: Sent: Sunday, March 3, 2013 3:21 AM Subject: [boost] Is there interest in a collection of call stack utilities?
Hello,
I have a collection of debugging/diagnostic utilities to inspect the run-time call stack and to resolve symbol information. The tools are currently C++11 code and support GNU-Linux and Windows. An overview is available at https://freeshell.de//~amelinte/call_stack_usage.html
Is there interest for potential inclusion in boost?
Thanks, Aurelian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Artyom Beilis <artyomtnk@yahoo.com> writes:
Hello,
This thread reminds me the following thread I had started:
http://thread.gmane.org/gmane.comp.lib.boost.devel/209982
Also the code had improved since than:
https://sourceforge.net/p/cppcms/code/2238/tree/framework/trunk/booster/boos... https://sourceforge.net/p/cppcms/code/2238/tree/framework/trunk/booster/lib/...
Ready for inclusion in Boost yet? ;) I've been looking forward to this. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On 03/03/13 10:54, Artyom Beilis wrote:
You can also utilize function like backtrace_symbols. AFAIR not every platform has dladdr (Solaris if I recall correctly)
backtrace_symbols uses dladdr, and dladdr requires to link with -ldl, and is very limited in terms of what it sees. Also no debugging information is available. The best way to get a list of symbols on Linux is unfortunately to extract the information from the executable and shared library binaries, as libbfd does. I think the right approach is to separate the backtrace proper (list of addresses) from the mapping to names. Therefore 'backtrace' should be used, but not 'backtrace_symbols'. 'backtrace_symbols' is pretty bad anyway, you can do something better by calling dladdr manually. (Solaris, and any other operating system with ELF shared object support, supports dladdr)
Generally it is very interesting topic and very useful stuff (from my experience in deploy with CppCMS).
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself. It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 10:54, Artyom Beilis wrote:
You can also utilize function like backtrace_symbols. AFAIR not every platform has dladdr (Solaris if I recall correctly)
backtrace_symbols uses dladdr, and dladdr requires to link with -ldl, and is very limited in terms of what it sees. Also no debugging information is available.
The best way to get a list of symbols on Linux is unfortunately to extract the information from the executable and shared library binaries, as libbfd does.
I think the right approach is to separate the backtrace proper (list of addresses) from the mapping to names. Therefore 'backtrace' should be used, but not 'backtrace_symbols'. 'backtrace_symbols' is pretty bad anyway, you can do something better by calling dladdr manually.
(Solaris, and any other operating system with ELF shared object support, supports dladdr)
Generally it is very interesting topic and very useful stuff (from my experience in deploy with CppCMS).
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself.
It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
Surely the idea is to get back-traces from deployed software? You can't use your debugger there. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 13:14, Alexander Lamaison wrote:
Surely the idea is to get back-traces from deployed software? You can't use your debugger there.
Just get the core dump and import it in your debugger.
From my users? I'm not sure many of them know how to do this. Hell, I don't even know how to do this.
In any case, aren't they only produced if a program crashes? What I often need is the backtrace when my program has caught an exception and shown users an error message. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
On 03/03/13 15:20, Alexander Lamaison wrote:
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 13:14, Alexander Lamaison wrote:
Surely the idea is to get back-traces from deployed software? You can't use your debugger there.
Just get the core dump and import it in your debugger.
From my users? I'm not sure many of them know how to do this. Hell, I don't even know how to do this.
In any case, aren't they only produced if a program crashes? What I often need is the backtrace when my program has caught an exception and shown users an error message.
How do you think errors are reported with software like Firefox?
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 15:20, Alexander Lamaison wrote:
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 13:14, Alexander Lamaison wrote:
Surely the idea is to get back-traces from deployed software? You can't use your debugger there.
Just get the core dump and import it in your debugger.
From my users? I'm not sure many of them know how to do this. Hell, I don't even know how to do this.
In any case, aren't they only produced if a program crashes? What I often need is the backtrace when my program has caught an exception and shown users an error message.
How do you think errors are reported with software like Firefox?
Firefox only reports crashes, not arbitrary errors. I've no idea how it does it (Google have a library you can use to add the same functionality to your own project) but that's not the use-case where Artyom's code would be useful. Instead, his code is used to get source information for errors that occur during normal program operation. Core dumps (crashes) should be a vanishingly rare event in deployed software, but errors happen as part of normal program behaviour. When the cause of the error is a bug in the software rather than user error or environment, it would be invaluable if the user could provide a back-trace as part of their bug report. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
I havent seen the source yet but a quick question. The compiler list says visual studio 2012 and gcc 4.7+. Is this library tied to these version? At least I would love to have this functionality in a few earlier versions of VC and GCC. Clang would be nice too. On Mon, Mar 4, 2013 at 6:45 AM, Alexander Lamaison <awl03@doc.ic.ac.uk>wrote:
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 15:20, Alexander Lamaison wrote:
Mathias Gaunard <mathias.gaunard@ens-lyon.org> writes:
On 03/03/13 13:14, Alexander Lamaison wrote:
Surely the idea is to get back-traces from deployed software? You can't use your debugger there.
Just get the core dump and import it in your debugger.
From my users? I'm not sure many of them know how to do this. Hell, I don't even know how to do this.
In any case, aren't they only produced if a program crashes? What I often need is the backtrace when my program has caught an exception and shown users an error message.
How do you think errors are reported with software like Firefox?
Firefox only reports crashes, not arbitrary errors. I've no idea how it does it (Google have a library you can use to add the same functionality to your own project) but that's not the use-case where Artyom's code would be useful.
Instead, his code is used to get source information for errors that occur during normal program operation. Core dumps (crashes) should be a vanishingly rare event in deployed software, but errors happen as part of normal program behaviour. When the cause of the error is a bug in the software rather than user error or environment, it would be invaluable if the user could provide a back-trace as part of their bug report.
Alex
-- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/03/2013 11:28 PM, Shakti Misra wrote:
I havent seen the source yet but a quick question. The compiler list says visual studio 2012 and gcc 4.7+. Is this library tied to these version? At least I would love to have this functionality in a few earlier versions of VC and GCC. Clang would be nice too.
Yes, the code uses C++11 features, in particular new classes in the STL. But it should be easy to move it to any earlier compiler version. Thanks, Aurelian
From my users? I'm not sure many of them know how to do this. Hell, I don't even know how to do this.
On m$ you have ofc WER in which u can get minidumps. In our software we also dump locally for in house crashes. A good article on how to do that is http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Applicat.... On topic: form a client perspective a Boost library helping debugging (e.g. naming threads) is a good thing.
On 3/3/2013 6:56 AM, Mathias Gaunard wrote:
On 03/03/13 10:54, Artyom Beilis wrote:
Generally it is very interesting topic and very useful stuff (from my experience in deploy with CppCMS).
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself.
It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
I believe there are valid uses for displaying a backtrace at points in the code where you do not want to have to stop the debugger simply to be able to visually view the backtrace ( as a call stack ). So I would look forward to a Boost cross-platform library which allowed a programmer to output the backtrace through code.
On Mar 3, 2013, at 9:02 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 3/3/2013 6:56 AM, Mathias Gaunard wrote:
On 03/03/13 10:54, Artyom Beilis wrote:
Generally it is very interesting topic and very useful stuff (from my experience in deploy with CppCMS).
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself.
It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
I believe there are valid uses for displaying a backtrace at points in the code where you do not want to have to stop the debugger simply to be able to visually view the backtrace ( as a call stack ). So I would look forward to a Boost cross-platform library which allowed a programmer to output the backtrace through code.
The example of this that has been proposed in the past is to automatically log the call stack on allocations/deallocations/exceptions. Alternately, to attach the call stack to exceptions before they were thrown (Boost.Exception set up to allow people to attach arbitrary data to an exception). -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 03/03/2013 12:56 PM, Mathias Gaunard wrote:
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself.
It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
There are many situations where that is not the right approach. One of them is web-servers and web-frameworks running arbitrary applications. Once such an application throws an uncaught exception then its stack trace with some other application state can be sent via e-mail to the application admins. I've seen that in practice and it's been very helpful. In my opinion there is no point of discussing whether stack traces are useful or not. Some of us would surely benefit from such a functionality in Boost, some of us would not. It's the same situation as with other Boost libraries. In short, yes to cross-platform stack traces in Boost. WBR, Adam Romanek
I also agree with Adam. Another example is situations where apps are monitored by other applications. So attaching the monitored app to debugger may make the monitoring app to restart it. So in these situations also stack trace helps. So I would like to have it. On Mon, Mar 4, 2013 at 12:31 PM, Adam Romanek <romanek.adam@gmail.com>wrote:
On 03/03/2013 12:56 PM, Mathias Gaunard wrote:
While it is interesting, I have not found it to be that useful in practice. The debugger already does all of this better that you could ever do yourself.
It is probably a better idea to integrate your app with a debugger than to rewrite a debugger inside your app.
There are many situations where that is not the right approach.
One of them is web-servers and web-frameworks running arbitrary applications. Once such an application throws an uncaught exception then its stack trace with some other application state can be sent via e-mail to the application admins. I've seen that in practice and it's been very helpful.
In my opinion there is no point of discussing whether stack traces are useful or not. Some of us would surely benefit from such a functionality in Boost, some of us would not. It's the same situation as with other Boost libraries.
In short, yes to cross-platform stack traces in Boost.
WBR, Adam Romanek
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
participants (9)
-
Adam Romanek -
Alexander Lamaison -
Artyom Beilis -
Aurelian Melinte -
Edward Diener -
gast128 -
Marshall Clow -
Mathias Gaunard -
Shakti Misra