Thu, Jan 14
Wed, Jan 13
- Fix comment
Nov 19 2020
Oct 30 2020
OK, I believe this is correct now.
- Ignore old modules not in target list
- Expand logging as suggested in D89157
Oct 29 2020
But then you get to a point where you shouldn't really have multiple modules replacing a single one so you aren't really sure what to do about it. That part makes me a little uneasy.
Thanks for the review!
Oct 28 2020
I'd been hoping to get this bugfix into 11.0.1, but it (and D89156, which is just some cleanup that occurred to me while working on this code) have been stalled for a few weeks, and I don't have any insight into the reason. If there's anything i can do to help either one along, please let me know. One idea I had is that I could rebase this on master so it doesn't depend on the other, would that help?
Oct 21 2020
Oct 16 2020
Oct 13 2020
IIUC, the problem with ReplaceModule will get fixed in a dependent patch, right? So the last bit of this patch will get cleaned up by that change. If that's right, then this LGTM.
- Comment new parameter
Oct 10 2020
Thanks for the speedy review! I've updated it to include a testcase that shows the problem you described, and include the fix you suggested.
- Handle finding wrong version before right one
Oct 9 2020
Sep 23 2020
Sep 22 2020
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
If this patch is solely meant to fix this issue, then I remove my "Requires Changes" and this patch is good to go if it no longer hangs LLDB.
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
Therefore I think it would make sense to just spell out each member of that array as a separate member in the yaml representation, which should be a much simpler endeavour. We can use the "actual parameter count" field to suppress the fields that don't contain any value, if they really are zero, which should make the yaml output concise in the usual cases. I think something like this should be sufficient:
I think that would strike a good balance between code complexity, output brevity, and being able to generate interesting and potentially invalid inputs for other tools (which is one of the main goals of yaml2obj, and so interpreting the input too strictly is not desired/helpful).
- Add test with extraneous parameter
- Change Exception Information format per feedback
Hmm.. maybe just keep those constants defined in lldb somewhere (e.g. right next to or inside the RefreshStateAfterStop function)? That's the place which does the decoding and also includes the OS switch, so it makes it easier to explain their purpose and why they are different for each OS...
- Define DumpRequested constant in-line, per feedback in D68656
- Remove ExceptionCode enumeration
Oct 9 2019
- Remove the os-defined exception code enum values
Thanks for taking your time to do this. I have one question: It looks like you're not using the exception code enum in the follow-up patch. I think that's completely reasonable given that the enum values are overloaded and system-dependent. But given this fact, and the fact that I am not convinced the enum values are completely right (e.g. the linux signal numbers depend also on the architecture -- though this may not manifest itself on the architectures that breakpad supports right now), what would you say to just dropping that enumeration?
Oct 8 2019
Nit: Title says "thread" rather than "memory info"
Sep 30 2019
It doesn't look like it should be too hard to add yaml support for the exceptions stream -- it should only be a matter of adapting the patterns already used for other stream to work for this particular case. Could you give a go at that?