Segmentation fault (Address not mapped to object [(nil)]) on printing end #194
Comments
|
You must select a single symbol resolver implementation. Take a look at the top of |
|
Hi there, we are running into this error as well. Here is how we use backward: @bombela, is this incorrect usage ? |
|
We use it on Linux with a static binary + elfutils library git://sourceware.org/git/elfutils.git |
|
Could it be the object being in main is destroyed somehow before being
used? Maybe it should be a global? I am just throwing ideas here.
…On Tue, 23 Feb 2021, 19:19 Benjamin Sergeant, ***@***.***> wrote:
We use it on Linux with a static binary + elfutils library git://
sourceware.org/git/elfutils.git
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#194 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUZDDWWJ3M73PUEORDUCLTARV2JANCNFSM4TATGYJQ>
.
|
|
Everything is possible but that sounds unlikely. Our main is server code so we essentially never exit main.
In the past I wrote crash-handling code too, and I remember avoiding fwrite and using straight write with a file descriptor instead.
fwrite is not ’signal safe’ according to the internet. I’m contemplating making a PR that would add an interface with ‘write’ for the code that prints the backtrace.
… On Feb 23, 2021, at 7:39 PM, François-Xavier Bourlet ***@***.***> wrote:
Could it be the object being in main is destroyed somehow before being
used? Maybe it should be a global? I am just throwing ideas here.
On Tue, 23 Feb 2021, 19:19 Benjamin Sergeant, ***@***.***>
wrote:
> We use it on Linux with a static binary + elfutils library git://
> sourceware.org/git/elfutils.git
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#194 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABUZDDWWJ3M73PUEORDUCLTARV2JANCNFSM4TATGYJQ>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2O6ULGBZPZ3AK4HZNHWQTTARYI7ANCNFSM4TATGYJQ>.
|
|
Fair enough. Backward-cpp is not signal safe at all. None of the lib used to parse the debug symbols are. Making signal safe code is a pretty serious endeavor. So my take was: better have stacktrace most often, than have nothing. Nontheless you think it's the fwrite? Any ways you comment the frwite out and test on your program? |
|
I actually have no clue whether it’s the fwrite, and agreed that signal safe is a pain, I hate using C function for doing string manipulation myself …
I hope I can find something and report here.
… On Feb 23, 2021, at 7:39 PM, François-Xavier Bourlet ***@***.***> wrote:
Could it be the object being in main is destroyed somehow before being
used? Maybe it should be a global? I am just throwing ideas here.
On Tue, 23 Feb 2021, 19:19 Benjamin Sergeant, ***@***.***>
wrote:
> We use it on Linux with a static binary + elfutils library git://
> sourceware.org/git/elfutils.git
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#194 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABUZDDWWJ3M73PUEORDUCLTARV2JANCNFSM4TATGYJQ>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2O6ULGBZPZ3AK4HZNHWQTTARYI7ANCNFSM4TATGYJQ>.
|
|
If you don't mind me piggy-backing onto this, I'm getting a similar error. Here's how I'm using it (on an exception I construct an error class and inside the constructor this code is called): which results in: That all said, it all works lovely if I don't attempt to do a manual traverse and just let it fail and output to the terminal as normal, but I'd also like to capture the output and do stuff with it, (edit: I'm running XUbuntu 20.04, gcc11.1, and link in binutils-dev and libunwind-dev and have set the defines correctly) |
|
In your output, backward-cpp is printing the trace on a segfault... caused when accessing a resolved trace from backward-cpp! That's fun. |
Its all incredibly meta isn't it? Incidentally, I'd thought I'd try to be clever and use the Printer object instead but writing it to an ostringsteam. No cigar either, alas: |
|
I cannot reproduce the segfault. Ubuntu 20.04.2 LTS Testing with: |
|
Does it behaves differently with unwind instead of libunwind? |
|
Same error with using both libunwind and the standard unwind. I'm also using lbfd but would that make a difference? As I said, it works beautifully if I let it do its thing when an exception occurs and print stuff out to the console and then exit. But I would like to be handle things a bit more gracefully if possible and grab the stack trace to allow users to send it to me. |
|
I don't think libfd makes a difference. Feel free to try them all. Note that you can store the stacktrace with your exception, and resolve it later. Up to you. Anyways, I cannot reproduce the segfault. If you could come up with a small reproducible example, it would be great. |
|
OK, a smidgeon of clarity achieved. I use both CodeBlocks and VSCode, and I think the seg fault is caused either by something in the way Codeblocks is linking or the way I have the project setup therein; because if I compile using VSCode/make, no seg fault occurs. That's a bit weird, that said, since as far as I can tell, my build options for both methods are identical and up until now, there's been no difference in what I use to compile and link with regards to the rest of the codebase. Build options are pretty standard BTW, including backward.cpp for the defines, search path includes backward.hpp, debug symbols are on, and the three libraries mentioned above. I'll continue to investigate and report back, and see how I get on with valgrind. |
|
Try |
|
Also if you could find out the exact compiler command line invocation it would be great. |
|
OK, no difference in CodeBlocks with unwind. :-( Compilation example:
Linkage: |
|
In your first segfault, you are using BACKTRACE, not BFD. But you claim that you intended to use BFD. Your command line also doesn't include the various defines for backward.hpp. This leads me to believe that you are compiling backward.hpp differently in various code object (.o). And then linking the whole thing together. I further believe that because you mentioned some defines in backward.cpp. Which only applies to this very .cpp file. The one that registers unix signal that then give you a nice printed trace. But the backward.hpp you are importing for attaching to the exception is not compiled with the same defines. In other words: set the defines for your compilation command lines. Or set them atop backward.hpp. But not in .cpp files. |
|
ok, I'll try that!!! |
|
That worked. Removing backward.cpp from my project and moving the defines into backward.hpp was the key. I can now grab the stack to allow the users to send me the info. Thank you!!!
What's the best/preferred way of crediting use of the library btw? |
|
Ah C++... It keeps you on your toes at all time. One tiny slip, and your program will do everything and anything. If you already have an "about" dialog with a list of open sources credits, you can add a mention there if you would like. No obligation. |
|
For anybody else reading this issue. Make sure that you are compiling backward.hpp with the exact same defines and compilation flags throughout your program. Otherwise, the generated machine code will be incompatible at runtime. |
|
@bombela i ran into this same issue, but ONLY when executed from inside Digging into the source and Simply commenting out that line removes the error message. I did also try using Some more experimentation, i tried forcefully Conclusions:
My code to reproduce this is below: #include "backward.hpp"
using namespace backward;
void p() {
backward::StackTrace st;
st.load_here(32);
backward::TraceResolver tr;
tr.load_stacktrace(st);
for (size_t i = 0; i < st.size(); ++i) {
backward::ResolvedTrace trace = tr.resolve(st[i]);
std::cout << i
<< " " << trace.object_filename
<< " " << trace.object_function
<< " " << trace.addr
<< " " << std::endl;
}
}
int nullSegfault()
{
int* p_junk = 0;
int val = *p_junk;
return val; // have to use `val` to avoid optimizer throwing all this code away
}
void raiseSegfault()
{
raise(SIGSEGV);
}
int main(int argc, char* argv[])
{
// print stacktrace normally to show that it works in-process
p();
// register backward signal handlers to showcase the error message
backward::SignalHandling sh;
// comment these out to choose how to raise the signal
// cause segfault by NULL pointer access, prints:
// Segmentation fault (Address not mapped to object [(nil)])
nullSegfault();
// cause segfault by raising the signal manually, prints:
// Segmentation fault (Signal sent by tkill() [0x3e800063099])
raiseSegfault();
return 0;
}Hope this helps someone else. |
|
I don't think it is the same issue. You are talking about some output message from psiginfo. They had a memory access error because of incompatible datastructures in memory. Unless you are saying you got a memory access error during the execution of psiginfo?
|
It segfaults on end of printing stacktrace, on line 3975
raise(info->si_signo);.And it prints a redefinition warning if I uncomment
#define BACKWARD_HAS_BFD 1this is what I use now
The text was updated successfully, but these errors were encountered: