[lldb-dev] Documentation on stack unwinding

[Greg Clayton]

You best bet for simplicity is to use backtrace(). LLDB has code that does this in the host layer:

void
Host::Backtrace (Stream &strm, uint32_t max_frames)
{
    if (max_frames > 0)
    {
        std::vector<void *> frame_buffer (max_frames, NULL);
        int num_frames = ::backtrace (&frame_buffer[0], frame_buffer.size());
        char** strs = ::backtrace_symbols (&frame_buffer[0], num_frames);
        if (strs)
        {
            // Start at 1 to skip the "Host::Backtrace" frame
            for (int i = 1; i < num_frames; ++i)
                strm.Printf("%s\n", strs[i]);
            ::free (strs);
        }
    }
}

Using LLDB.framework is probably too expensive and you can't guarantee a user system will have it installed since it is only installed with Xcode or the command line tools package that is available separately.

The above code will be the cheapest way memory wise compared to using LLDB.

Greg

> On May 12, 2015, at 2:22 AM, Jakub Bednář <jakub.bednar at avg.com> wrote:
> 
> Hello everyone,
> 
> I am trying to develop a crash handler, that is able to detect which part of my code did cause a crash. The process registers a signal handler. When it crashes, the signal handler is called with siginfo_t. But the information there might point to some libc function (memcmp, memcopy, etc.). I need to find out, which part of my code up the stack is responsible for calling it. Currently I am relying on systems CrashReporter, but for some reason I am getting reports from users with .crash files missing, so maybe it does not create the .crash file for all possible crash scenarios? It also does not carry parts of heap etc so its use is limited.
> 
> I have tried several things with no results so far.
> 
> 1. Google’s crashpad and breakpad can generate a minidump, but they currently can’t correctly unwind stack that is in signal handler.
> 2. stackshot(1) creates some stacks, but they are divided to kernel and user stacks and have many frames that seems to be wrong. They are not displayed in lldb for instance.
> 3. backtrace(3) seems risky to be used from signal handler, especially when the stack can be corrupted.
> 4. Taking LLDB.framework with me as suggested in one of the mailing list threads could work, but the framework has 43MB.
> 
> Trying to find out some documentation and reading forums and mailing lists, I got stuck on two questions and I hope someone here can help me out.
> 
> a. How can I get into the depths of stack unwinding? Can you please point me to any literature, articles to get into it. I know where to find it in LLDB source code, but it is a dark magic for me and reading the code without understanding the concepts does not help.
> b. Do you know about any project that I could use just for stack unwinding. I need mainly x86_64 darwin systems.
> c. Is there possibly any API to Mac OS X system crash reporter so I can utilize it? Would be great to get on-demand stacks of process or maybe even a minidump.
> d. Are there any compiler options for clang that could make stack unwinding easier? I believe on Windows you can work only with ebp chains. That would help a lot.
> 
> Thank you very much for any help.
> 
> Best regards,
> 
> Jakub 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev