[haiku-bugs] Re: [Haiku] #10641: Webpositive Crashed in real_time_clock_usecs()
- From: "pulkomandy" <trac@xxxxxxxxxxxx>
- Date: Wed, 05 Mar 2014 22:55:31 -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):
{{{
[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
}}}
--
Ticket URL: <https://dev.haiku-os.org/ticket/10641#comment:4>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
