Closed Bug 507410 Opened 13 years ago Closed 12 years ago
.exe crashes while trying to run mochitest
I have ran into an issue where fennec.exe is crashing when loading a mochitest webpage. I can run a single mochitest .html file and it works as expected. I can run a directory of mochitest test files and it will load up (not run). But if I try to create my own master mochitest file, it fails miserably. I put a debug build on with symbols (which I used to get info for other crashes from July 27), and it returned no information. Here is what I see in the visual studio debugger: AKY=01000001 PC=00a72bb0(fennec.exe+0x00a62bb0) RA=00a72ae0(fennec.exe+0x00a62ae0) BVA=cdcdcdd1 FSR=00000001 Unhandled exception at 0x00a72bb0 in fennec.exe: 0x80000002: Datatype misalignment. attached is a .html file that I have been using to crash.
I have done some more digging into this and it appears that when calling the <script src="/MochiKit/packed.js"> in the referenced iframe src file, that causes the crash. I can load the rest of the test file successfully inside the iframe. This is frustrating as I know the packed.js will load and run just fine if I call the test file directory, but it fails when loaded inside the iframe. If I use the file:///<path>/ to load the harness and test file, I don't get the error. Since I am running this on a remote server, this also questions the stability of running mochitests on a remote web server vs localhost. On a desktop build of fennec I was able to run many tests (so far 2189 dom tests) using the remote server. I looked into reducing packed.js (which is a 6000+ line file of what appears to be generated .js code) and that is just scary. Maybe somebody has an idea of how to debug why loading the packed.js script inside an iframe src document is failing on windows mobile.
Marking blocking fennec -? as this is blocking our ability to get mochitests running for windows mobile (and by all indications) windows CE as well. If all goes well, I will be attempting this on a windows ce machine later today and will likely have the crash repo'd in house. We need this addressed as soon as possible. Let us know what else we can do to help out in providing more information.
tracking-fennec: --- → ?
Need to use a debug build (--enable-debug, not just with symbols) and attach a stack trace, as well as the last few lines of output.
I have a debug build, it gets me in the debugger for other crashes and I can step through line by line. For this specific crash it is only offering up disassembly. Maybe ctalbert can have better luck on the tegra device.
Copy and paste a few dozen lines of disassembly around the crashing instruction, as well as all the register values.. that should be enough to figure out what's going on.
R0 = 0x00b731cc R1 = 0x00000002 R2 = 0xfffffffc R3 = 0x00000000 R4 = 0x33bbcb34 R5 = 0x33bbec34 R6 = 0x33bbcc34 R7 = 0x33bbbaa8 R8 = 0x00000001 R9 = 0x33bbcc74 R10 = 0x00000001 R11 = 0x33bbba84 R12 = 0x00c21240 Sp = 0x33bbba68 Lr = 0x00b82ae0 Pc = 0x00b82bb0 Psr = 0x60000010 00B82AE8 ldr r0, [r11, #-8] 00B82AEC tst r8, r8 00B82AF0 beq 01057538 00B82AF4 str r8, [r9, #0x18] 00B82AF8 str r8, [r9, #-0x20] 00B82AFC str r10, [r9, #0x20] 00B82B00 ldr r8, [r8, #4] 00B82B04 mvn r2, #3 00B82B08 str r2, [r11, #-0x14] 00B82B0C and r8, r8, r2 00B82B10 ldr r12, [pc, #-0xAB0] 00B82B14 cmp r8, r12 00B82B18 bne 0105754C 00B82B1C ldr r2, [pc, #-0xAC0] 00B82B20 movs r1, #1 00B82B24 mul r8, r1, r8 00B82B28 adds r8, r8, r2 00B82B2C ldrb r8, [r8] 00B82B30 tst r8, r8 00B82B34 bne 01057560 00B82B38 movs r8, #2 00B82B3C str r8, [r11, #-8] 00B82B40 cmp r10, #2 00B82B44 bcs 01057574 00B82B48 mvn r2, #0x2F 00B82B4C adds r8, r9, r2 00B82B50 movs r1, #8 00B82B54 mul r2, r1, r2 00B82B58 adds r8, r8, r2 00B82B5C ldr r8, [r8] 00B82B60 str r8, [r9, #0x18] 00B82B64 mvn r2, #1 00B82B68 ldr r1, [r0, #0x10] 00B82B6C and r1, r1, r2 00B82B70 ldr r2, [r11, #-0x14] 00B82B74 ldr r12, [pc, #-0xB1C] 00B82B78 cmp r1, r12 00B82B7C ldr r1, [r11, #-8] 00B82B80 bne 01057588 00B82B84 ldr r0, [r0, #0xC] 00B82B88 ldr r12, [pc, #-0xB34] 00B82B8C cmp r0, r12 00B82B90 bne 0105759C 00B82B94 ldr r0, [pc, #-0xB44] 00B82B98 str r0, [r4] 00B82B9C str r1, [r9, #0x30] 00B82BA0 str r1, [r9, #0x38] 00B82BA4 str r3, [r9, #0x28] 00B82BA8 str r3, [r9, #0x20] 00B82BAC str r8, [r9, #0x40] *00B82BB0 ldr r3, [r8, #4] 00B82BB4 and r3, r3, r2 00B82BB8 ldr r12, [pc, #-0xB6C] 00B82BBC cmp r3, r12 00B82BC0 bne 010575B0 00B82BC4 ldr r8, [r8, #0x10] 00B82BC8 str r8, [r9, #0x30] 00B82BCC ldr r3, [pc, #-0xB84] 00B82BD0 str r3, [r9, #0x40] 00B82BD4 str r3, [r9, #0x48]
Joel, does this still crash?
I honestly haven't tried this since I moved to testing one file at a time. There are some crashes to debug for mochitest and fennec on winmo. I will give this a try and see if it still crashes.
this is not a problem on the Oct 29 1.9.2 nightly build. If I do run into any issues related to this, it will be specific to a single test vs the 5 or 6 folders I tried before and kept running into the same crash.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
marking as verified.
Status: RESOLVED → VERIFIED
Component: Windows Mobile → General
QA Contact: mobile-windows → general
Hardware: ARM → All
You need to log in before you can comment on or make changes to this bug.