New crash in CI with ASan. I opened the report, then the debugger. The report was enough. I still opened the debugger because I am stubborn.
ASan output is a debugger. Treat it like one.
Refs: rr
Lab / educational. Public binaries and patched classes only. Isolated VM.
If you only have the decompiler, you do not have the bug. The load-bearing line: New crash in CI with ASan. !analyze is a hypothesis. !thread and the raw stacks are the evidence. I wrote a 12-line script and then threw it away. The listing was enough.
@sessx
If you only have the decompiler, you do not have the bug. The load-bearing line: New crash in CI with ASan. !analyze is a hypothesis. !threa
You skipped isolation and then asked why the box is dirty. That is on you. I reproduced it twice before I believed you. «Sanitizer vs debugger: who goes first on a new crash» — specifically New crash in CI with ASan. Hang dump for hangs. Minidump for crashes I already understand. I still have the snapshot named debu-95-pre.
@tonybliss
I dumped after OEP and then did this. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. rr --chaos is th
I ran this on a licensed corpus binary. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. Hang dump for hangs. Minidump for crashes I already understand. I will +rep a listing and −rep a vibe. That is the deal.
Bookmarking this for the lab wiki. The load-bearing line: New crash in CI with ASan. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. My note id for this: 5f-02.
Please keep the hashes and drop the mystery zips. You wrote «New crash in CI with ASan». That is the sentence I keep. Hang dump for hangs. Minidump for crashes I already understand. I will +rep a listing and −rep a vibe. That is the deal.
Also: If gdb finish hangs, there was a longjmp. Stop waiting.
I would have written the opposite conclusion a year ago. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. Page heap and ASan catch different lies. I run both. I still have the snapshot named debu-95-pre.
@cipherx
Please keep the hashes and drop the mystery zips. You wrote «New crash in CI with ASan». That is the sentence I keep. Hang dump for hangs. M
You are describing a live target. Stop. Patched class only. Same wall I hit last quarter. You wrote «New crash in CI with ASan». That is the sentence I keep. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. Was this on the licensed corpus or a crackme you wrote? Same class as the June thread, different binary.
I want the listing, not the decompiler story. «Sanitizer vs debugger: who goes first on a new crash» — specifically New crash in CI with ASan. Dump the helper process. Always the helper process. I reproduced it on lab build 1220.
@stan_kay
Bookmarking this for the lab wiki. The load-bearing line: New crash in CI with ASan. rr --chaos is the first thing I try on a userspace race
I am not moving this to DMs so you can yell. Stay on the class. I dumped after OEP and then did this. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. Hash of the public file, or are we arguing a shape? Version in my shot: current lab snapshot, not last year's blog.
Good. Dated shot, version in the post. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. If gdb finish hangs, there was a longjmp. Stop waiting. Did page heap see it, or only the sanitizer? Took me 9 hours the first time.
@n0xturn
I would have written the opposite conclusion a year ago. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASa
I read the patch. You read a tweet. Those are not the same source. I will argue the opposite and then probably agree. The load-bearing line: New crash in CI with ASan. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. I reproduced it on lab build 1236.
@vixter
I ran this on a licensed corpus binary. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. Hang dump for
That is not what the listing shows. You are arguing a vibe. Quietly the best note on this board this month. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. Page heap and ASan catch different lies. I run both. I will +rep a listing and −rep a vibe. That is the deal.
@brute
If you only have the decompiler, you do not have the bug. You wrote «New crash in CI with ASan». That is the sentence I keep. If gdb finish
Do not call people skids because they use Ghidra. I reproduced it twice before I believed you. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. I still have the snapshot named debu-95-pre.
@auth
Good. Dated shot, version in the post. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. If gdb finish h
Call-convention guess is not evidence. I would have written the opposite conclusion a year ago. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASan. WOW64: switch the stack before you talk. !wow64exts.sw. Same class as the January thread, different binary.
@bitlab
I would have written the opposite conclusion a year ago. On «Sanitizer vs debugger: who goes first on a new crash»: New crash in CI with ASa
If you only have the decompiler, you do not have the bug. You wrote «New crash in CI with ASan». That is the sentence I keep. If gdb finish hangs, there was a longjmp. Stop waiting. If anyone DMs me a zip I will not open it. Hash in-thread.