Usage of libv4l causes a crash during rr record #2929
Comments
|
That looks like VIDIOC_G_INPUT. |
|
Try again with the latest tip? |
|
We now get |
|
Attach gdb to the tracee following the instructions at the bottom and get a backtrace? |
|
When I run I get taken to Pressing |
|
If you rerun that recording and attach the emergency debugger again, what's the value of |
|
Some output from gdb: |
|
779040e adds some more debug logging, can you pull it and rerun your failing test? |
|
It seems deeply wrong that the return address should be |
|
Here's the updated log: |
|
Can you disassemble the code at 0xffffffffff600000? |
|
@khuey Re-running the trace I get and then |
|
Hmm, ok. The vsyscall page should be there ... You could try booting your kernel with the parameter |
|
✔️ This worked. Thank you. Testing now to see if Pernosco accepts the trace. |
|
The |
|
When we get the output |
Try SIGKILLing the tracee (rr's child) instead. |
No, there should be nothing there. The kernel's vsyscall emulation relies on that page being unmapped. Jumping there triggers a fault with RIP in the vsyscall page, and the kernel emulates everything from there. |
|
Sending I'll remove the |
|
With I got |
|
I think the tracee execed through a vsyscall and now we can't "patch the caller" because the caller is completely gone. |
|
I don't think you can execve through a vsyscall. |
|
Yeah, vsyscall can only do |
|
0xffffffffff600000 is This return address we pulled from the stack is clearly is clearly |
|
Yeah I guess it's limited to just a few syscalls https://github.com/torvalds/linux/blob/2734d6c1b1a089fb593ef6a23d4b70903526fe0c/arch/x86/entry/vsyscall/vsyscall_64.c#L185 |
|
Actually though ... the code in the disassembly here is clearly NOT |
|
In fact it looks like we're pulling values from the stack, doing arithmetic on them and returning the result, just like you'd expect from a wrapper function calling |
|
I think the problem is simply that this code doesn't match the single very limited template we know how to patch for vsyscalls. @georgewsinger can you disassemble the 256 bytes before and after that return address, with /r please? |
|
@rocallahan What do you mean? |
|
Use |
|
Over in #2939 this appears to be a PLT thunk trampolining directly into the vsyscall (where the GNU IFUNC stuff was used to select an implementation at runtime). That's definitely not going to fit the X64VSyscallEntry template. |
|
@georgewsinger: Can you please drop the output of |
|
That PLT thunk stuff is probably glibc only and probably not happening here according to the parts of the disassembly we've seen so far. Most likely all that is required here is to get the disassembly of the code leading up to the vsyscall as well as after it, and use that to create a patch template that matches this call site. |
|
|
|
Can you keep going on the last one until you get back to 0x55b39d8a720b? |
|
With I'm now getting
...which looks like mangled/unreadable output? |
|
Can you do x/100i for that? |
|
I ran it again and got a similar result, but it seems to be more readable assembly if I use
|
|
idk what /r does, idk why roc told you to use that :) |
|
Out of curiosity, what version of libc does this system have? |
|
2.32: |
|
Have you updated to 8a15f2a ? |
|
Just to drop that here: I have 2.17 and the issue that showed the same hex address (which we've seen in the time function disassembly) was fixed by the recent snapshot.
|
@rocallahan Just tried updating to latest tip, and the issue has gone away. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: