Webpositive Crashed in real_time_clock_usecs()

[SeanCollins]

webpositive crashed, could be a duplicate of another crash, not sure why it crashed, attaching crash report.

version 46955 new webkit build.

[pulkomandy]

I don't think anyone reported this one, yet, but I have seen it happen some times. The crash is in real_time_cloc_usecs, which is part of libroot. I don't know what's going on, but I plan to have a look...

[pulkomandy]

This is reproductible in WebKi ttest suite: LayoutTests/fast/parser/parser-yield-timing.html The stack overflows.

Storing conversation with WebKit devs:

[22:14] <msaboff> The JSC stack is actually limited by maxPerThreadStackUage in JavaScriptCore/runtime/Options.h
[22:15] <msaboff> The JSC stack checks should cause a JS exception before the stack overflows.
[22:18] <msaboff> PulkoMandy: Is wtf/StackBounds.cpp set up so that it matches the actual limits to your native stack?
[22:19] <PulkoMandy> msaboff: seems to be, yes
[22:24] <PulkoMandy> our main stack is 16MB, which is the limit we hit here
[22:24] <msaboff> Is jsc really trying to access beyond the allocated stack?
[22:24] <PulkoMandy> runtime/Options.h is set to 4MB
[22:25] <PulkoMandy> as far as I can tell, it always (often?) crashes when calling WTF::CurrentTime
[22:25] <PulkoMandy> and the stack is indeed past the 16MB limit at that point
[22:25] <msaboff> There is some reserved space in Options.h.  JSC should give an exception if it tries to allocate a frame past maxPerThreadStackUsage - reservedZoneSize of stack.
[22:34] <msaboff> PulkoMandy: Between frames  0x721a7d18  0x6155d52   ?  and 0x711a9258  0x114776    ? you are using 16M.  That appears to be where all the stack is going.  By the time we call out to operationLinkConstruct there should be 128K bytes of stack left.  Clearly there is not.
[22:36] <PulkoMandy> yes, I see that - I was wondering if the huge stack usage sounds like usual for JSC, or if something went wrong - I guess the latter then
[22:37] <msaboff> PulkoMandy: I'd look into why the call from 0x6155d52 to 0x114776 is using all that stack.  Is it the caller's or callee's local stack space?
[22:39] <PulkoMandy> I don't know
[22:41] <msaboff> PulkoMandy: Are both of these functions JS? If so, which engine, LLInt, Baseline or DFG?
[22:43] <msaboff> PulkoMandy: If you can disassemble arbitrary addresses after the crash, look around 0x114776 and 0x6155d52.  By around, +/- 30 bytes.
[22:43] <msaboff> PulkoMandy: The addresses will be different if they are JIT'ed addresses.
[22:43] *** rcombs (~rcombs@rcombs.me) has joined the channel.
[22:44] <PulkoMandy> ok, let me try that...
[22:45] <msaboff> PulkoMandy: If possible, the values of esp and ebp for the frames in question would be good.
[22:46] <msaboff> PulkoMandy: ebp - Typically esp is roughly the size of the local stack frame for a function, after both have been properly set up at the beginning of the function.
[22:46] <msaboff> PulkoMandy: *Typically (ebp - esp) *
[23:02] <PulkoMandy> msaboff: the value in the report is the value of EBP in the caller, at the time the "call" instruction to the next function is executed
[23:02] <PulkoMandy> the debugger doesn't want to give me the esp value, I guess I have to examine the stackframe myself
[23:03] <PulkoMandy> and, these two functions are JIT, as their address doesn't map to any loaded executable or shared lib, they are in a malloc'ed area

[pulkomandy]

[23:09] <msaboff> PulkoMandy: If you go into wtf/DataLog.cpp and set DATA_LOG_TO_FILE to 1 and then set DATA_LOG_FILENAME to path that WebKit can write to, you can enable some logging to see a little more detail.
[23:11] <msaboff> PulkoMandy: If you have the disassembler enabled for your platform, you can set showDisassembly to true to see the generated code. showDisassembly can be set via the environment variable JSC_showDisassembly=1
[23:12] <PulkoMandy> http://paste.debian.net/85505/
[23:13] <PulkoMandy> I get this
[23:13] <msaboff> PulkoMandy: The logging file will actually be DATA_LOG_FILENAME with the pid and ".txt" appended.
[23:13] <PulkoMandy> I guess I have to enable disassembly now
[23:13] <msaboff> PulkoMandy: That means that the disassembly is not enabled for your platform.  You can see the byte ranges for generated code though.
[23:15] <msaboff> PulkoMandy: If you disassemble beginning at 0x145000, you can see the instructions that set up the stack for that function.
[23:15] <msaboff> PulkoMandy: Same thing for disassembling beginning from 0x102940
[23:16] <PulkoMandy> http://paste.debian.net/85508/
[23:16] <PulkoMandy> the matching backtrace for this run
[23:16] <PulkoMandy> the addresses are different, so...
[23:18] <PulkoMandy> so, the caller ? is JIT, and the callee doesn't seem to be
[23:19] <msaboff> PulkoMandy: The baseline compile of sleep#BywTgC should create a small frame
[23:20] <msaboff> PulkoMandy: In http://paste.debian.net/85505/, the first function is a baseline JIT compile of a function named "sleep()"
[23:21] <msaboff> PulkoMandy: The second section is a DFG compile of the same function (sleep#BywTgC).
[23:22] <PulkoMandy> the function doesn't look like it should use that much stack
[23:23] <msaboff> PulkoMandy: No.  From a debugger, are you able to disassembly the first ~30 instructions of each of the JSC functions on the stack?
[23:23] <msaboff> PulkoMandy: That is after the crash, but before the process dies.
[23:24] <PulkoMandy> our debugger doesn't seem to want to disassemble this :(
[23:25] <PulkoMandy> I can get an hex dump
[23:27] <msaboff> PulkoMandy: You could see about enabling the udis86 disassembler in wtf/Platform.h - Look where  WTF_USE_UDIS86 is defined
[23:28] <msaboff> PulkoMandy: It shouldn't require anything special from your OS.
[23:29] <PulkoMandy> ok - this will take a while to recompile, however
[23:29] <msaboff> PulkoMandy: Are you trying to disassemble using an address?
[23:30] <PulkoMandy> I don't find a way to do that in our debugger
[23:31] <PulkoMandy> well, we have a gdb port, but it is too old, I can try it but it probably won't be very helpful
[23:34] <PulkoMandy> http://paste.debian.net/85514/
[23:34] <PulkoMandy> yes, that doesn't really help
[23:34] <PulkoMandy> is disassemble the right command to use?
[23:35] <msaboff> PulkoMandy: But gdb shows many more frames
[23:36] <msaboff> PulkoMandy: Some of those frames look bogus (0xfffffffb which is likely a JSC tag)
[23:37] <PulkoMandy> yes, I think it gets lost in the stack trace
[23:38] <PulkoMandy> http://paste.debian.net/85516/ this should be the relevant part (the function that calls operationLinkConstruct)
[23:39] <PulkoMandy> http://paste.debian.net/85519/ and the one below, according to gdb - doesn't look like x86 code

[pulkomandy]

This crash doesn't happen in the testsuite anymore. does it still happen to someone?

[SeanCollins]

I am frequently getting the attached crash, not sure if its the same. If not, close the ticket and I'll open a new case for the new crash, I am getting these crashes frequently to btw.

[pulkomandy]

No, not the same at all. This new report is a memory corruption problem, so if you could run Web+ with libroot debug, it would help getting a more useful report:

LD_PRELOAD=/system/lib/x86/libroot_debug.so WebPositive