[haiku-bugs] Re: [Haiku] #10641: Webpositive Crashed in real_time_clock_usecs()
- From: "pulkomandy" <trac@xxxxxxxxxxxx>
- Date: Wed, 05 Mar 2014 22:10:50 -0000
#10641: Webpositive Crashed in real_time_clock_usecs()
----------------------------------------+----------------------------
Reporter: SeanCollins | Owner: pulkomandy
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Applications/WebPositive | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
----------------------------------------+----------------------------
Comment (by 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@xxxxxxxxx) 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
}}}
--
Ticket URL: <https://dev.haiku-os.org/ticket/10641#comment:3>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
