- User Since
- Jun 2 2015, 7:30 PM (278 w, 19 h)
Wed, Sep 23
Tue, Sep 22
Aug 31 2020
Yeah, the potential for quadratic explosion is why I didn't hook this flag up to expensive checks when I added it. It occurs to me now that if we want, we could presumably have some cutoff counter so that after inserting 300 instructions or whatever limit is reasonable, we start hashing normally. We'd have to empty the table and repopulate it with the normal hash when we cut over, but that should be doable I think (it's similar to what the table does internally when it grows).
Aug 26 2020
To clarify, the failure did not reproduce for me in the SUSE 15.02 container. I don't know what I'm doing differently. To create the environment, I just did docker run ... opensuse/leap:15.2, and then zypper in gcc-c++ python3-devel inside the container.
FWIW, I tried running the test in an SUSE 15.2 docker container (on an Ubuntu 18.04 host), and here's what I'm seeing. raise and abort indeed do not indicate that they had the S set in the augmentation:
eh_frame augmented UnwindPlan:
This UnwindPlan is for a trap handler function: yes.
Aug 25 2020
And its parent 'raise' is set so as well because of 'GetNextFrame()->m_frame_type == eTrapHandlerFrame '.
May 12 2020
Feb 10 2020
Dec 4 2019
Dec 3 2019
- Use invalid_argument error code
- Change signature to return Expected<vector<BreakpointSP>>
Dec 2 2019
Oct 18 2019
Oct 17 2019
- Use Twine instead of formatv
Oct 16 2019
Oct 15 2019
- punctuation fixes
Oct 14 2019
- Move test
- Remove TODO, lit-ify negative test and tighten check
Oct 13 2019
- ...and fix namespace...
- Fix Expected<> types
- Apply review feedback (-auto, -memset, +comments)
Oct 11 2019
Just to make sure I'm understanding the feedback correctly, I'll try to summarize. Please let me know if this is off track:
Added Exception stream to minidump-basic.yaml as suggested.
Address review feedback
- Remove useless comment and leftover debugging cruft
Oct 10 2019
- Update test input yaml Exception stream
- Add testcase
- Add test with extraneous parameter
- Change Exception Information format per feedback
- Define DumpRequested constant in-line, per feedback in D68656
- Remove ExceptionCode enumeration
Oct 9 2019
- Remove the os-defined exception code enum values
Oct 8 2019
Nit: Title says "thread" rather than "memory info"
Sep 30 2019
- Review feedback
Sep 27 2019
- Use accessor for m_unix_signals_sp
- Move artificial SIGSTOP injection to RefreshStateAfterStop
Fortunately, for the functionality you're testing, I don't think you really need the executable file, so you can just ignore the elf bit and test with a plain lldb -c foo.dmp (obviously, you won't get the backtrace that way, but you don't really need that here.
Sep 26 2019
I'm trying to fix an issue where opening a minidump created by breakpad in lldb just hangs, but if I use breakpad's minidump-2-core on that same dump then opening the core dump works fine. From debugging the two cases I can see that the critical logic that ProcessElfCore has which ProcessMinidump lacks is here, and the code in this patch is my attempt to replicate that.
Aug 7 2019
Aug 6 2019
LGTM. Probably good to have someone else weigh in before committing (I touched this code last, but only to fix a couple bugs).
Aug 2 2019
- Expand comment about return trampolines
- rename PropagateTrapHandlerFlag -> PropagateTrapHandlerFlagFromUnwindPlan
Jul 31 2019
- add test
- Move resolution helper from RegisterContextLLDB to lldb_private::Address
- Defensively initialize out arguments
Jul 30 2019
#include <signal.h> #include <stdio.h> #include <stdlib.h>
Jul 21 2019
Jul 19 2019
Jul 18 2019
Jul 15 2019
I'm guessing on this Linux system, you've got a trap receiver function on the stack that is on its first instruction or something? So backing up the pc value for *that* frame is the problem you're solving.
Just just to check, we've got a backtrace like...
ping @jasonmolenda -- do the updates look like what you had in mind when you said " It'd be a good change to capture that information from the eh_frame though, even if we don't see a clear way to use it right now"?
That LLDB frame #5 is a bit bogus
Jun 27 2019
- Include __restore_rt
Jun 25 2019
- fix copy pasta
I've updated this with code to recognize the 'S' in the eh_frame augmentation and record it in a new bool member of UnwindPlan, m_plan_is_for_signal_trap. I haven't hooked up any consumers of the new bit; as you say, with the current code flow we don't parse the eh_frame info until after we've decided whether the current frame is a trap handler frame or not.