Don't crash on the v8 demo
cgaebel opened this issue · 4 comments
The v8 demo is in demo/demo.js
Right now, attempts to magic-trace it crash while trying to parse perf output:
"3435768/3435768 1283684.240499276: int 556263730105 v8::base::OS::Abort+0x15 => 556263608d40 v8::internal::Snapshot::DefaultSnapshotBlob+0x57e00"))
or even:
"3435768/3435768 1283760.029165481: int 55626368b83f v8::internal::Snapshot::DefaultSnapshotBlob+0xda8ff => 5562635f7e80 v8::internal::Snapshot::DefaultSnapshotBlob+0x46f40"))
At this point, I'd normally go add parsing for software interrupts, int. But I don't understand what's going on here. Looking at V8's source code, OS::Abort is supposed to abort the process. But the process didn't abort! Also also, DefaultSnapshotBlob is pretty trivial function that doesn't look like it should be generating software interrupts.
It would be interesting to get the perf report -D output corresponding with that time region (I think you should be able to filter that specific time range with --time starttime,stoptime).
My understanding is that an interrupt should appear in a TIP (Target IP) packet, but that those packets are also used to encode indirect branch targets... and that perf then disassembles that IP to determine whether to show an int or jmp in the trace output. (Only semi-confident on the last point.)
If that's the case, then maybe it's possible that that IP was once an indirect jmp, and that V8 did some JIT magic by the time we got around to running perf script? From a cursory look through V8 code, it looks like it fills regions it expects to not get executed with INT3 instructions: https://github.com/v8/v8/search?q=int3&type=commits
Of course, this seems less likely if it's always the same function that we hit an int in...
It might be a V8-ism, but I'd like to point out that these are C++ functions, not JS.
Let's just treat it as a jump for now, and look into why later.
We weren't able to reproduce this again, so closing for now.