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 <gclay...@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.bed...@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@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
