I created a patch and am compiling as I write. Here is the patch. Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is actually correct too.
Now to test the crash patch....
Darrell
On Friday 16 of August 2013 02:01:26 Darrell Anderson wrote:
I created a patch and am compiling as I write. Here is the patch. Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is actually correct too.
Now to test the crash patch....
Darrell
Good job. Just one mistake - was not included "ConfigureChecks.cmake". Now I test build on my local builder => I will soon approve it.
Slavek --
On Friday 16 of August 2013 02:07:24 Slávek Banko wrote:
On Friday 16 of August 2013 02:01:26 Darrell Anderson wrote:
I created a patch and am compiling as I write. Here is the patch. Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is actually correct too.
Now to test the crash patch....
Darrell
Good job. Just one mistake - was not included "ConfigureChecks.cmake". Now I test build on my local builder => I will soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not both. For me successfully tested builds for both variants - with and without backtrace handler.
However, there is still good objection from Fat-Zer... It would be good to find a consensus soon, because the current situation leads to FTBFS.
Slavek --
2013/8/16 Slávek Banko slavek.banko@axis.cz
On Friday 16 of August 2013 02:07:24 Slávek Banko wrote:
On Friday 16 of August 2013 02:01:26 Darrell Anderson wrote:
I created a patch and am compiling as I write. Here is the patch. Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is actually correct too.
Now to test the crash patch....
Darrell
Good job. Just one mistake - was not included "ConfigureChecks.cmake".
Now
I test build on my local builder => I will soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not both. For me successfully tested builds for both variants - with and without backtrace handler.
However, there is still good objection from Fat-Zer... It would be good to find a consensus soon, because the current situation leads to FTBFS.
Slavek
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Here is propoused patch which checks if demangle.h is present.
I consider the print_trace() and all backtrace_symbol.c as a temporary debug crutch. Am I wrong? Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace or generic backtrace()?
2013/8/16 Fat-Zer fatzer2@gmail.com
Here is propoused patch which checks if demangle.h is present.
Darrell, I have demangle.h on my system, so it's up to you to test it.
I consider the print_trace() and all backtrace_symbol.c as a temporary debug crutch. Am I wrong? Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace or generic backtrace()?
2013/8/16 Slávek Banko slavek.banko@axis.cz
On Friday 16 of August 2013 02:07:24 Slávek Banko wrote:
On Friday 16 of August 2013 02:01:26 Darrell Anderson wrote:
I created a patch and am compiling as I write. Here is the patch. Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is actually correct too.
Now to test the crash patch....
Darrell
Good job. Just one mistake - was not included "ConfigureChecks.cmake".
Now
I test build on my local builder => I will soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not both. For me successfully tested builds for both variants - with and without backtrace handler.
However, there is still good objection from Fat-Zer... It would be good to find a consensus soon, because the current situation leads to FTBFS.
Slavek
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Here is propoused patch which checks if demangle.h is present.
I consider the print_trace() and all backtrace_symbol.c as a temporary debug crutch. Am I wrong? Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace or generic backtrace()?
The new routine prints a stack trace that is very close to gdb's output, complete with line numbers, whereas the other routines leave off critical information which then makes debugging very difficult.
Either way, you are correct--the code section in question is only activated when debugging is turned on at compile time (#undef NDEBUG in tdeioslavebase.cpp). Furthermore, the output is logged to ~./xsession-errors as text, not via a popup kcrash dialog.
Tim
Tim
2013/8/16 Timothy Pearson kb9vqf@pearsoncomputing.net
The new routine prints a stack trace that is very close to gdb's output, complete with line numbers, whereas the other routines leave off critical information which then makes debugging very difficult.
Either way, you are correct--the code section in question is only activated when debugging is turned on at compile time (#undef NDEBUG in tdeioslavebase.cpp). Furthermore, the output is logged to ~./xsession-errors as text, not via a popup kcrash dialog.
Tim
ok... I suppose it would be nice to make it an another backend for kdBacktrace. but before starting to I've got couple more questions: Does it have some special requirements? e.g. debug information (splitted or not) or source code installed? Is there any library that implements it and provides higher-level API?
-
Darrell Anderson -
Fat-Zer -
Slávek Banko -
Timothy Pearson