[lldb-dev] Documentation on stack unwinding

[Jakub Bednář]

Hi Greg,

thank you for the response.

I have only one concern about backtrace(). Is it safe to be used from a signal handler? What happens in case of corrupted stack, stack overflow or corrupted heap. Won’t the backtrace() call try to read invalid data and possibly crash as well? I need it to be reliable. As it is in section 3 of the manpages I suppose it is not a system call and it is not listed as a signal handler safe function.

Best regards,

Jakub

On 12 May 2015, at 20:17, Greg Clayton <gclayton at apple.com> wrote:

> 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
>