| Summary: | crash due to unaligned acces in KJS::Machine::runBlock() | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Helge Deller <deller> |
| Component: | kjs | Assignee: | Konqueror Bugs <konqueror-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | deller, justin.zobel, maksim |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Helge Deller
2009-10-14 17:06:51 UTC
Well, it's certainly -supposed- to align everything right (it actually even 8-aligns pointers on IA-32), but seems like I screwed it up somewhere... Any chance you could get a backtrace with -fno-inline or such? > Any chance you could get a backtrace with -fno-inline or such?
No, not easily. The backtrace is from the pre-compiled debian packages...
If it helps: The assembler command at 0x46694df4 tries to store a "float" (8-byte alignment needed) to some location. Not sure if that helps though...
0x46694de0 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22196>: extrw,s r20,29,30,r26
0x46694de4 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22200>: stw r26,-10(sp)
0x46694de8 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22204>: fldw -10(sp),fr23
0x46694dec <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22208>: fcnvxf,sgl,dbl fr23,fr4
0x46694df0 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22212>: depw,z r6,27,28,ret0
0x46694df4 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22216>: fstd fr4,r5(ret0)
0x46694df8 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22220>: ldw -334(sp),r4
0x46694dfc <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22224>: ldw 0(r4),ret0
0x46694e00 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22228>: addil L%800,r19,r1
0x46694e04 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22232>: ldw 1d4(r1),r1
0x46694e08 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22236>: ldw,s ret0(r1),r20
0x46694e0c <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22240>: bv,n r0(r20)
0x46694e10 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22244>: ldo c(r4),ret0
0x46694e14 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22248>: stw ret0,-334(sp)
0x46694e18 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22252>: ldw -4(ret0),r20
0x46694e1c <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22256>: ldw -32c(sp),r22
0x46694e20 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22260>: ldb r22(r20),r21
0x46694e24 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22264>: cmpiclr,= 0,r21,r0
0x46694e28 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+22268>: b,l 0x46699514 <_ZN3KJS7Machine8runBlockEPNS_9ExecStateERKN3WTF6VectorIhLj0EEES2_+40424>,r0
floats are 32-bit, so why would they need to be 8-byte aligned? The difficulty here is that it's a pretty frequently aligned method, so without knowing where it comes from it'd be very hard to point out what's wrong. In gdb, can you get value of the pc or localPC local variables? Hmm, logging "info locals" might help. I said "float" above, but meant actually an 8-byte "double" instead, as the assembler statement reads "fstd fr4,r5(ret0)", which refers to a double...
> In gdb, can you get value of the pc or localPC local variables?
Program received signal SIGSEGV, Segmentation fault.
0x46a94df4 in KJS::Machine::runBlock (exec=0xc0048378, codeBlock=..., parentExec=0x0) at codes.def:127
127 codes.def: No such file or directory.
in codes.def
(gdb) info locals
localPC = 0x70 <Address 0x70 out of bounds>
fbDestReg = 7
in = 0x1
out = 0
base = 0xab2238 ""
pc = 0xab2450 ""
workList = {_impBase = 0x46acff78}
localStore = 0xab200c
globalObject = 0x40210000
kjsVMOpHandlers = {0x46a97ecc, 0x46a981b8, 0x46a98174, 0x46a981f4, 0x46a94e54, 0x46a94e10, 0x46a8f91c, 0x46a8f920, 0x46a954d0, 0x46a8f980, 0x46a8f984, 0x46a94d0c, 0x46a8f9e4, 0x46a8f9e8, 0x46a94db4, 0x46a94d74, 0x46a9606c, 0x46a95d84, 0x46a95d14, 0x46a95cdc, 0x46a960b0,
0x46a8fa40, 0x46a8fa44, 0x46a960ec, 0x46a8fa8c, 0x46a8fa90, 0x46a95958, 0x46a8fafc, 0x46a8fb00, 0x46a97f98, 0x46a97f50, 0x46a97f04, 0x46a8fb30, 0x46a8fb34, 0x46a95910, 0x46a8fb78, 0x46a8fb7c, 0x46a95534, 0x46a8fbbc, 0x46a8fbc0, 0x46a954c0, 0x46a954b8, 0x46a954b0,
0x46a90664, 0x46a95484, 0x46a95448, 0x46a95404, 0x46a953a8, 0x46a9517c, 0x46a95138, 0x46a95760, 0x46a8fbf4, 0x46a8fbf8, 0x46a9524c, 0x46a951b8, 0x46a8fd48, 0x46a8fd4c, 0x46a95b24, 0x46a8fe08, 0x46a8fe0c, 0x46a95700, 0x46a956cc, 0x46a95690, 0x46a9557c, 0x46a95108,
0x46a950d0, 0x46a90584, 0x46a90588, 0x46a94fbc, 0x46a94f14, 0x46a94ed8, 0x46a94e94, 0x46a905e0, 0x46a905e4, 0x46a95ae8, 0x46a95aa0, 0x46a90618, 0x46a9061c, 0x46a9585c, 0x46a95820, 0x46a8f88c, 0x46a8f890, 0x46a90664, 0x46a9067c, 0x46a90680, 0x46a906fc, 0x46a90700,
0x46a958ac, 0x46a90784, 0x46a90788, 0x46a909c0, 0x46a909c4, 0x46a90aa0, 0x46a90aa4, 0x46a90cd8, 0x46a90cdc, 0x46a8fe6c, 0x46a8fe70, 0x46a8ff4c, 0x46a8ff50, 0x46a900b4, 0x46a900b8, 0x46a90184, 0x46a90188, 0x46a90288, 0x46a9028c, 0x46a904ac, 0x46a904b0, 0x46a91020,
0x46a91024, 0x46a95be4, 0x46a95a40, 0x46a90e20, 0x46a90e24, 0x46a957bc, 0x46a95a08, 0x46a959cc, 0x46a95f48, 0x46a95f0c, 0x46a90e58, 0x46a90e5c, 0x46a95f80, 0x46a90ec4, 0x46a90ec8, 0x46a90f20, 0x46a90f24, 0x46a90f80, 0x46a90f84, 0x46a90d9c, 0x46a90da0, 0x46a9186c,
0x46a91870, 0x46a917c8, 0x46a917cc, 0x46a91818, 0x46a9181c, 0x46a91474, 0x46a91478, 0x46a91518, 0x46a9151c, 0x46a98020, 0x46a97fd0, 0x46a98518, 0x46a91660, 0x46a91664, 0x46a983b4, 0x46a982cc, 0x46a9823c, 0x46a9105c, 0x46a91060, 0x46a91178, 0x46a9117c, 0x46a91298,
0x46a9129c, 0x46a95dec, 0x46a913b8, 0x46a913bc, 0x46a95c20, 0x46a91414, 0x46a91418, 0x46a95c7c, 0x46a918f8, 0x46a918fc, 0x46a91ae8, 0x46a91aec, 0x46a94078, 0x46a9407c, 0x46a940dc, 0x46a940e0, 0x46a93dc4, 0x46a93dc8, 0x46a93e70, 0x46a93e74, 0x46a96a20, 0x46a93fd4,
0x46a93fd8, 0x46a93af0, 0x46a93af4, 0x46a9635c, 0x46a962bc, 0x46a93b9c, 0x46a93ba0, 0x46a965a0, 0x46a963f8, 0x46a93be4, 0x46a93be8, 0x46a93ce8, 0x46a93cec, 0x46a93d30, 0x46a93d34, 0x46a93d7c, 0x46a93d80, 0x46a937f0, 0x46a937f4, 0x46a9383c, 0x46a93840, 0x46a96688,
0x46a969b4, 0x46a93884, 0x46a93888...}
Thank you for the report, Helge. As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |