Segfaulting, unsure why.

[OdinVex]

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.

[OdinVex]

Edit: Just re-attached, it'll crash any time I hit a breakpoint, tell it to F9 resume, then try to interact with EDB.

[eteran]

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?

[OdinVex]

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.

[OdinVex]

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.

[eteran]

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.

[OdinVex]

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;

[10110111]

You may want to attach to EDB with GDB and see where and how it crashes.

[OdinVex]

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.

[eteran]

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.

[eteran]

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:

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

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

[OdinVex]

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.

[eteran]

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!