Open OdinVex opened 4 months ago
Edit: Just re-attached, it'll crash any time I hit a breakpoint, tell it to F9 resume, then try to interact with EDB.
Interesting, to be clear, you are saying that edb segfaults, not the process being debugged, correct?
Could you share more about your system, and anything else that would help me reproduce the issue?
Yes, edb segfaults, not the process being debugged. I've found a way to prevent it. As long as I don't interact with edb after I F9 resume it's fine and I can trigger safe interaction by simply doing something in the software to trigger a breakpoint again, then edb is fine until the next F9.
What could I share about the system to help? Given the nature of what I'm currently doing...it'd best be something discussed privately at most.
It's always follows:
PTRACE_GETREGS failed: No such process
PTRACE_GETFPREGS failed: No such process
Process is still running.
Edb seems to only crash if the process does something in particular, but unfortunately that's all I can determine. The nature of what I'm doing is sensitive.
I understand that what you are doing is sensitive. Any chance you can narrow down the issue in some kind of minimum reproducible example? Unfortunately, I can't do much to fix the issue unless I can reproduce it locally.
I think it would be best if I could try to debug the issue locally. I've found it only segfaults if the target process goes through a specific routine. It's a process that most definitely does low-level system access (raw drive access, RAID access, mdamd, etc). A similar routine does not cause the issue but one in particular does and I can trigger it -every- time. Edit: I'm currently forced to work on a very small drive just to use this debugger, so I can't set up a dev environment to mimic and I doubt you'd be able to recreate (easily) the circumstances to reproduce the issue unless you have some spare drives and turn a bit Shultz about the use of the debugger. X_X;
You may want to attach to EDB with GDB and see where and how it crashes.
All gdb gives me:
Thread 1 "edb" received signal SIGSEGV, Segmentation fault.
0x0000556c07673aa6 in QDisassemblyView::drawJumpArrows(QPainter&, QDisassemblyView::DrawingContext const*) ()
Edit: Attempted to consume those signals and nostop nopass
them followed by continue
but gdb just ends up being spammed by those segfaults and edb remains unresponsive from the loop.
OK, well that helps a little bit. I can see where in there are possible memory errors and add some extra asserts to try to narrow it down.
Hmm, so I've looked at the code in that routine and there's not a ton to go on at the moment. There aren't many memory references to possibly be null or out of bounds, but there are some that I can investigate.
A few thoughts:
Any chance you could try the same with a debug build of edb? gdb may be able to literally give the line number it's breaking on.
Can you test if as a workaround, if disabling "show jump arrows" in the "Disassembly" tab of the options makes the issue go away? (if it does I hope you still will follow up with helping to diagnose since we don't want a latent bug in the code). But it would help prove where precisely the issue is.
I'll attempt to use the AUR's edb-debugger
package but edit the build routine to compile a debug. Meanwhile I'll try to see if disabling jump-arrows helps narrow. Edit: Disabling Show Jump Arrows
it prevents a crash.
Edit:
0x00005555557c590b in QDisassemblyView::drawJumpArrows (this=0x555555b73590, painter=..., ctx=0x7fffffffbe70) at src/edb-debugger/src/widgets/QDisassemblyView.cpp:1376
1376 process->currentThread()->getState(&state);
Looks like 1376. I am pretty sure the software creates a thread and then keels it after it's done with it. If it didn't then what it's being asked to do would be monumentally slow.
Interesting. This is super helpful. I can definitely make the code a little more resilient here. Obviously, it is assuming that currentThread()
(and process too) never returns NULL
. There is code like that in a few spots, but this is very good info for us.
Thanks!
I'm not sure what is triggering a segfault but the process being debugged doesn't crash and I can re-attach to it. Triggering a routine that I had a previous breakpoint on causes EDB to catch it, then I restore the opcodes and correct the RIP, re-add breakpoint, F9 resume, process is fine and EDB is at this point still running but as soon as I attempt to interact with EDB it'll segfault, even if it's a simple scroll.