Closed Bug 523581 Opened 15 years ago Closed 14 years ago

ARM alignment trap caused by aggressive optimization of js/src/jstracer.cpp

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
Other
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: junkmailnotread, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.14) Gecko/2009102016 Gentoo Firefox/3.0.14 Build Identifier: fennec-1.0b5pre fennec provokes numerous alignment trap warnings on my HP iPAQ hx4700 (armv5tel) PDA. The traps are all at the same program address: ... Alignment trap: fennec (1774) PC=0x40abc584 Instr=0xe18a60d2 Address=0xbe950eec FSR 0x013 Alignment trap: fennec (1774) PC=0x40abc584 Instr=0xe18a60d2 Address=0xbe950efc FSR 0x013 Alignment trap: fennec (1774) PC=0x40abc584 Instr=0xe18a60d2 Address=0xbe950f04 FSR 0x013 Alignment trap: fennec (1774) PC=0x40abc584 Instr=0xe18a60d2 Address=0xbe950ef4 FSR 0x013 ... I tracked this program address to the file js/src/jstracer.cpp and its function LeaveTree(): d710: e18a60d2 ldrd r6, [sl, r2] I was not able to match this instruction to any line of C++ source code. Instead it looked like compiler generated function entry code. So, looking at the Makefile build options, I noticed that -O3 optimization was being used. Reducing this to -O2 fixed the problem. Here is my fix: --- mobilebase/xulrunner/js/src/Makefile.orig 2009-10-21 15:01:56.138887402 +0100 +++ mobilebase/xulrunner/js/src/Makefile 2009-10-21 15:06:47.486031614 +0100 @@ -87,9 +87,9 @@ #XXX: do we want different INTERP_OPTIMIZER flags here? endif else # not INTEL_CXX -MODULE_OPTIMIZE_FLAGS = -O3 -fstrict-aliasing $(MOZ_OPTIMIZE_SIZE_TWEAK) +MODULE_OPTIMIZE_FLAGS = -O2 -fstrict-aliasing $(MOZ_OPTIMIZE_SIZE_TWEAK) # Special optimization flags for jsinterp.c -INTERP_OPTIMIZER = -O3 -fstrict-aliasing +INTERP_OPTIMIZER = -O2 -fstrict-aliasing endif else # not GNU_CXX ifeq ($(OS_ARCH),SunOS) To summarize: building js/src/jstracer.cpp with -O2 instead of -O3 fixes the alignment trap warnings on my hx4700. Reproducible: Always Steps to Reproduce: 1. Build xulrunner and fennec with -march=armv5te 2. Run fennec on HP iPAQ hx4700. Actual Results: dmesg output contains numerous Alignment trap warnings from fennec process. Expected Results: dmesg output contains no Alignment trap warnings from fennec process.
Hardware: Other → ARM
Version: unspecified → Other Branch
The mozilla version is 1.9.3a1pre
What's the compiler version? It sounds like a compiler bug, to me.
Hardware: ARM → Other
Version: Other Branch → unspecified
% arm-angstrom-linux-gnueabi-gcc -v Using built-in specs. Target: arm-angstrom-linux-gnueabi Configured with: /var/tmp/cross/arm-angstrom-linux-gnueabi/portage/cross-arm-angstrom-linux-gnueabi/gcc-4.3.2-r4/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-angstrom-linux-gnueabi/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.2/include --datadir=/usr/share/gcc-data/arm-angstrom-linux-gnueabi/4.3.2 --mandir=/usr/share/gcc-data/arm-angstrom-linux-gnueabi/4.3.2/man --infodir=/usr/share/gcc-data/arm-angstrom-linux-gnueabi/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --target=arm-angstrom-linux-gnueabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++,fortran --with-sysroot=/usr/arm-angstrom-linux-gnueabi --disable-bootstrap --disable-libgomp --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r4 p1.8, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r4 p1.8, pie-10.1.5) %
I looked on Gentoo's Bugzilla and found no obvious problem with gcc-4.3.2 and ARM. But I did run across this statement: "Using -O3 is not recommended for gcc 4.x." Source: http://www.gentoo.org/doc/en/gcc-optimization.xml
That would be an interesting statement to find out more about. Do we know why they recommend that? We've been using -O3 for some time, is there a specific suboptimization that causes problems? (And how old is that comment?)
Today I upgraded my cross-compiler from gcc-4.3.2-r4 to gcc-4.3.4. I rebuilt fennec - using the latest source files - and tried again. In place of alignment traps I now get a segmentation violation, with both -O3 and -O2 optimizations. For example: fennec: unhandled page fault (11) at 0xe50b5040, code 0x015 Whether this change in behaviour was caused by the compiler upgrade or updated mozilla-central source files (or both) I do not know. However, I tracked the segmentation violation to the same place that caused the earlier alignment traps, namely the start of LeaveTree() in js/src/jstracer.cpp. After adding some debug I believe the problem is with the second argument to LeaveTree(), namely lr: LeaveTree(InterpState& state, VMSideExit* lr) In the final call to LeaveTree() before the crash, lr had the value 0xe50b500c. The faulting instruction offsets this address by 52 - i.e. 0xe50b5040 - before dereferencing it and crashing. This address matches the kernel's reported faulting address. My feeling now is that fennec is crashing because of a programming bug, rather than because of buggy -O3 optimization.
There is an alloca in LeaveTree(). That might cause complications. I am afraid we will need some more data and disassembly since you are using a non-default build environment.
Hello. OK, I added some more debug. Here are some snippets of jstracer.cpp: 6340 static JS_REQUIRES_STACK VMSideExit* 6341 ExecuteTree(JSContext* cx, Fragment* f, uintN& inlineCallCount, 6342 VMSideExit** innermostNestedGuardp) 6343 { <snip> 6487 VMSideExit* lr = (VMSideExit*)rec->exit; 6488 6489 AUDIT(traceTriggered); 6490 6491 cx->interpState = state->prev; 6492 6493 JS_ASSERT(!cx->bailExit); 6494 JS_ASSERT(lr->exitType != LOOP_EXIT || !lr->calldepth); 6495 tm->tracecx = NULL; 6496 { 6497 FILE *fp; 6498 fp = fopen("/dev/tty0", "w"); 6499 fprintf(fp, "calling LeaveTree 2: lr=%p\n", lr); 6500 fclose(fp); 6501 } 6502 LeaveTree(*state, lr); 6503 return state->innermost; 6504 } 6505 6506 static JS_FORCES_STACK void 6507 LeaveTree(InterpState& state, VMSideExit* lr) 6508 { 6509 { 6510 FILE *fp; 6511 fp = fopen("/dev/tty0", "w"); 6512 fprintf(fp, "LeaveTree: lr=%p\n", lr); 6513 fclose(fp); 6514 } 6515 VOUCH_DOES_NOT_REQUIRE_STACK(); 6516 6517 JSContext* cx = state.cx; 6518 FrameInfo** callstack = state.callstackBase; 6519 double* stack = state.stackBase; 6520 6521 /* 6522 * Except if we find that this is a nested bailout, the guard the call 6523 * returned is the one we have to use to adjust pc and sp. 6524 */ 6525 VMSideExit* innermost = lr; 6526 6527 /* <snip> 6538 */ 6539 FrameInfo** rp = (FrameInfo**)state.rp; 6540 if (lr->exitType == NESTED_EXIT) { And here are the last 8 lines printed on the screen (typed in here by hand): calling LeaveTree 2: lr=0x4471d9f8 LeaveTree: lr=0x4471d9f8 calling LeaveTree 2: lr=0x446f0370 LeaveTree: lr=0x446f0370 calling LeaveTree 2: lr=0x447c2388 LeaveTree: lr=0x447c2388 calling LeaveTree 2: lr=0xe50b500c LeaveTree: lr=0xe50b500c According to /proc/<pid>/maps, there is nothing at - or anywhere near - address 0xe50b500c. Hence the crash. So the problem is the 2nd argument (lr) passed to LeaveTree() on line 6502. Here is the full kernel crash report: fennec: unhandled page fault (11) at 0xe50b5040, code 0x015 pgd = c1198000 [e50b5040] *pgd=00000000 Pid: 1004, comm: fennec CPU: 0 PC is at 0x40a945bc LR is at 0x4002f6f0 pc : [<40a945bc>] lr : [<4002f6f0>] Not tainted sp : bec178a8 ip : 00000001 fp : bec209a4 r10: 4064e200 r9 : bec178f8 r8 : 446ddcc8 r7 : 40ac1000 r6 : e50b500c r5 : 44878650 r4 : 44878650 r3 : 00000001 r2 : 40360040 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode USER_32 Segment user Control: 397F Table: A1198000 DAC: 00000015 [<c001b368>] (show_regs+0x0/0x50) from [<c0021060>] (__do_user_fault+0x5c/0xa4) r4 = C0380CE0 [<c0021004>] (__do_user_fault+0x0/0xa4) from [<c00213a4>] (do_bad_area+0x50/0x6c) r7 = C0007940 r6 = A1198000 r5 = 00003940 r4 = 00000000 [<c0021354>] (do_bad_area+0x0/0x6c) from [<c0021434>] (do_translation_fault+0x74/0x80) [<c00213c0>] (do_translation_fault+0x0/0x80) from [<c00214ac>] (do_DataAbort+0x38/0x98) r7 = 00000015 r6 = C0237E98 r5 = 44878650 r4 = C0237E48 [<c0021474>] (do_DataAbort+0x0/0x98) from [<c0019c88>] (ret_from_exception+0x0/0x10) The program counter 0x40a945bc corresponds to libmozjs.so offset 0xd45bc (since libmozjs.so is loaded at address 0x409c0000). Here is the disassembly of libmozjs.so: 000d4570 <LeaveTree(InterpState&, VMSideExit*)>: d4570: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr} d4574: e59f7668 ldr r7, [pc, #1640] ; d4be4 <LeaveTree(InterpState&, VMSideExit*)+0x674> d4578: e1a09000 mov r9, r0 d457c: e1a06001 mov r6, r1 d4580: e59f0660 ldr r0, [pc, #1632] ; d4be8 <LeaveTree(InterpState&, VMSideExit*)+0x678> d4584: e59f1660 ldr r1, [pc, #1632] ; d4bec <LeaveTree(InterpState&, VMSideExit*)+0x67c> d4588: e08f7007 add r7, pc, r7 d458c: e24dd02c sub sp, sp, #44 ; 0x2c d4590: e0871001 add r1, r7, r1 d4594: e0870000 add r0, r7, r0 d4598: ebfcefbf bl 1049c <_init+0x34c> d459c: e59f264c ldr r2, [pc, #1612] ; d4bf0 <LeaveTree(InterpState&, VMSideExit*)+0x680> d45a0: e1a03006 mov r3, r6 d45a4: e3a01001 mov r1, #1 ; 0x1 d45a8: e0872002 add r2, r7, r2 d45ac: e1a04000 mov r4, r0 d45b0: ebfcf196 bl 10c10 <_init+0xac0> d45b4: e1a00004 mov r0, r4 d45b8: ebfcef7e bl 103b8 <_init+0x268> d45bc: e5963034 ldr r3, [r6, #52] Instruction d45bc offsets lr (in r6) by 52 which yields &lr->exitType I believe. So my guess is the program crashes on line 6540.
Obviously lr is loaded on line 6487. So the suspected culprit is the rec->exit value. Incidentally, line 6487 seems suspicious to me: 6487 VMSideExit* lr = (VMSideExit*)rec->exit; The type of rec->exit is struct SideExit*. However SideExit is a base class of VMSideExit. My C++ is a bit rusty but I'm pretty sure you can't safely cast a pointer to a base object into a pointer to one of its derived objects, because the base object is smaller. Maybe I'm missing something.
The cast should be fine. Can you break on this line in gdb? (b jstracer.cpp:6487) And then print the structure (p/x *rec) Continue a couple of times if needed to hit the error condition (c)
I gave up with gdb after passing the breakpoint 500 times and still with nothing on the screen. Something was wrong. So instead I used fprintf to write the rec structure to a file. Here's the full output: jmp=0x40022fb0, next=(nil), exit=0x43491ab0 jmp=0x40022b58, next=(nil), exit=0x435404c0 jmp=0x40022bac, next=(nil), exit=0x43495558 jmp=0x40022bac, next=(nil), exit=0x43495558 jmp=0x40022ec0, next=(nil), exit=0x4348f540 jmp=0x40022bac, next=(nil), exit=0x43495558 jmp=0x40022ec0, next=(nil), exit=0x4348f540 jmp=0x40022ec0, next=(nil), exit=0x4348f540 jmp=0x40022bac, next=(nil), exit=0x43495558 jmp=0x40022698, next=(nil), exit=0x43495b18 jmp=0x40022698, next=(nil), exit=0x43495b18 jmp=0x40022358, next=(nil), exit=0x435ec9b0 jmp=0x40022358, next=(nil), exit=0x435ec9b0 jmp=0x40023e48, next=(nil), exit=0x435ecf68 jmp=0x40023e48, next=(nil), exit=0x435ecf68 jmp=0x404ffbac, next=(nil), exit=0x446eea08 jmp=0x404ff974, next=(nil), exit=0x446eed90 jmp=0x404ff974, next=(nil), exit=0x446eed90 jmp=0x404ff824, next=(nil), exit=0x446efc88 jmp=0x404ff7cc, next=(nil), exit=0x446efb18 jmp=0x404ff618, next=(nil), exit=0x446efe80 jmp=0x404ff618, next=(nil), exit=0x446efe80 jmp=0x404feb60, next=(nil), exit=0x446f0370 jmp=0x404ffb28, next=(nil), exit=0x446ee818 jmp=0xe24dd030, next=0xe50b4008, exit=0xe50b500c
The addresses on which you're seeing this crash look suspiciously like instructions. > jmp=0xe24dd030, next=0xe50b4008, exit=0xe50b500c These disassemble to the following instructions: e24dd030 sub sp, sp, #48 ; 0x30 e50b4008 str r4, [fp, #-8] e50b500c str r5, [fp, #-12] I don't know how that's relevant, but it might be a clue.
(In reply to comment #0) > fennec provokes numerous alignment trap warnings on my HP iPAQ hx4700 > (armv5tel) PDA. The traps are all at the same program address: > > [...] > > I tracked this program address to the file js/src/jstracer.cpp and its function > LeaveTree(): > > d710: e18a60d2 ldrd r6, [sl, r2] > > I was not able to match this instruction to any line of C++ source code. > Instead it looked like compiler generated function entry code. Ah, that could explain things. I'm not terribly familiar with the alignment rules of ARMv5, but from the ARMv5 ARM: "If the load address is not doubleword-aligned, the results are UNPREDICTABLE." ARMv6 (such as ARM1176) has a (deprecated) compatibility mode to comply with ARMv5's behaviour for LDRD, but can also support word-aligned LDRD. ARMv7 requires that the processor implements unaligned accesses, but for instructions that load or store multiple words (such as LDRD), word-alignment is still required. ---- So, if ((sl+r2) & 0b111) != (0b000), we would expect to hit an alignment fault on your processor, but not on ARMv6 (not in legacy mode) or ARMv7. Since we test mostly on ARMv6 and ARMv7, it would make sense that we haven't seen this before. Another clue :-)
I added the value of rec to the debug output, hoping it might be pointing to a text segment when the crash occurs. But no such luck: pid=893, rec=0x43491b10, jmp=0x40022fb0, next=(nil), exit=0x43491ab0 pid=893, rec=0x43540520, jmp=0x40022b58, next=(nil), exit=0x435404c0 pid=893, rec=0x434955b8, jmp=0x40022bac, next=(nil), exit=0x43495558 pid=893, rec=0x434955b8, jmp=0x40022bac, next=(nil), exit=0x43495558 pid=893, rec=0x4348f5a0, jmp=0x40022ec0, next=(nil), exit=0x4348f540 pid=893, rec=0x434955b8, jmp=0x40022bac, next=(nil), exit=0x43495558 pid=893, rec=0x4348f5a0, jmp=0x40022ec0, next=(nil), exit=0x4348f540 pid=893, rec=0x4348f5a0, jmp=0x40022ec0, next=(nil), exit=0x4348f540 pid=893, rec=0x434955b8, jmp=0x40022bac, next=(nil), exit=0x43495558 pid=893, rec=0x43495b70, jmp=0x40022698, next=(nil), exit=0x43495b18 pid=893, rec=0x43495b70, jmp=0x40022698, next=(nil), exit=0x43495b18 pid=893, rec=0x435eca08, jmp=0x40022358, next=(nil), exit=0x435ec9b0 pid=893, rec=0x435eca08, jmp=0x40022358, next=(nil), exit=0x435ec9b0 pid=893, rec=0x435ecfc0, jmp=0x40023e48, next=(nil), exit=0x435ecf68 pid=893, rec=0x435ecfc0, jmp=0x40023e48, next=(nil), exit=0x435ecf68 pid=893, rec=0x446eea70, jmp=0x404ffbac, next=(nil), exit=0x446eea08 pid=893, rec=0x446eee00, jmp=0x404ff974, next=(nil), exit=0x446eed90 pid=893, rec=0x446eee00, jmp=0x404ff974, next=(nil), exit=0x446eed90 pid=893, rec=0x446efcf0, jmp=0x404ff824, next=(nil), exit=0x446efc88 pid=893, rec=0x446efb88, jmp=0x404ff7cc, next=(nil), exit=0x446efb18 pid=893, rec=0x446efef0, jmp=0x404ff618, next=(nil), exit=0x446efe80 pid=893, rec=0x446efef0, jmp=0x404ff618, next=(nil), exit=0x446efe80 pid=893, rec=0x446ee888, jmp=0x404ffb28, next=(nil), exit=0x446ee818 pid=893, rec=0x446eea70, jmp=0x404ffbac, next=(nil), exit=0x446eea08 pid=893, rec=0x446eee00, jmp=0x404ff974, next=(nil), exit=0x446eed90 pid=893, rec=0x4471b9f8, jmp=0x404ff338, next=(nil), exit=0x4471b988 pid=893, rec=0x446efcf0, jmp=0x404ff824, next=(nil), exit=0x446efc88 pid=893, rec=0x446efef0, jmp=0x404ff618, next=(nil), exit=0x446efe80 pid=893, rec=0x4471da68, jmp=0x42268e20, next=(nil), exit=0x4471d9f8 pid=893, rec=0x446f03d8, jmp=0x404feb60, next=(nil), exit=0x446f0370 pid=893, rec=0x447c2408, jmp=0x422febf0, next=(nil), exit=0x447c2388 pid=893, rec=0x455ce9bc, jmp=0xe24dd080, next=0xe50b4008, exit=0xe50b500c Here's the tail of /proc/<pid>/maps: 42c01000-43600000 rw-p 42c01000 00:00 0 43600000-43601000 ---p 43600000 00:00 0 43601000-43e00000 rw-p 43601000 00:00 0 43e00000-43e01000 ---p 43e00000 00:00 0 43e01000-44a00000 rw-p 43e01000 00:00 0 44a00000-44a01000 ---p 44a00000 00:00 0 44a01000-45200000 rw-p 44a01000 00:00 0 45200000-45459000 r--p 00000000 1f:02 21828 /usr/lib/fennec/xulrunner/chrome/toolkit.jar 45459000-454ab000 r--p 00000000 1f:02 21819 /usr/lib/fennec/xulrunner/chrome/en-US.jar 454ab000-45575000 r--p 00000000 1f:02 21785 /usr/lib/fennec/chrome/chrome.jar 45575000-455c5000 rw-p 45575000 00:00 0 455c5000-455d7000 rwxp 455c5000 00:00 0 45600000-45700000 rw-p 45600000 00:00 0 45700000-45701000 ---p 45700000 00:00 0 45701000-46400000 rw-p 45701000 00:00 0 bedd4000-bede9000 rw-p bedd4000 00:00 0 [stack]
I just updated mobile-browser (rather than mozilla-central) to the latest sources. Previously my snapshot of mobile-browser was about 2 weeks old. The segmentation violation has now moved to js_CallTree(). This time fennec starts OK and crashes only after I move the main panel from side to side. Here's the kernel crash report: fennec: unhandled page fault (11) at 0xe50b5040, code 0x0f5 pgd = c27b4000 [e50b5040] *pgd=00000000 Pid: 979, comm: fennec CPU: 0 PC is at 0x40aadf20 LR is at 0x447bcc60 pc : [<40aadf20>] lr : [<447bcc60>] Not tainted sp : beb2b370 ip : 000035be fp : beb2b3a0 r10: 00000000 r9 : beb2bc88 r8 : 00000000 r7 : 00000000 r6 : beb344bc r5 : beb33c68 r4 : beb2b3b8 r3 : 00003b72 r2 : 447990e0 r1 : beb33c68 r0 : e50b500c Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user Control: 397F Table: A27B4000 DAC: 00000015 [<c001b368>] (show_regs+0x0/0x50) from [<c0021060>] (__do_user_fault+0x5c/0xa4) r4 = C03D4360 [<c0021004>] (__do_user_fault+0x0/0xa4) from [<c00213a4>] (do_bad_area+0x50/0x6c) r7 = C0007940 r6 = A27B4000 r5 = 00003940 r4 = 00000000 [<c0021354>] (do_bad_area+0x0/0x6c) from [<c0021434>] (do_translation_fault+0x74/0x80) [<c00213c0>] (do_translation_fault+0x0/0x80) from [<c00214ac>] (do_DataAbort+0x38/0x98) r7 = 000000F5 r6 = C0237E98 r5 = BEB33C68 r4 = C0237E48 [<c0021474>] (do_DataAbort+0x0/0x98) from [<c0019c88>] (ret_from_exception+0x0/0x10) The program counter 0x40aadf20 corresponds to libmozjs.so offset 0xedf20 (since libmozjs.so is loaded at address 0x409c0000). This is in js_CallTree() in jsbuiltins.cpp: 000edf08 <js_CallTree(InterpState*, nanojit::Fragment*)>: edf08: e591301c ldr r3, [r1, #28] edf0c: e92d4010 push {r4, lr} edf10: e3a01000 mov r1, #0 ; 0x0 edf14: e1a04000 mov r4, r0 edf18: e12fff33 blx r3 edf1c: e5900008 ldr r0, [r0, #8] edf20: e5903034 ldr r3, [r0, #52] edf24: e3530004 cmp r3, #4 ; 0x4 edf28: 15840018 strne r0, [r4, #24] edf2c: 0a000001 beq edf38 <js_CallTree(InterpState*, nanojit::Fragment*)+0x30> edf30: e5840024 str r0, [r4, #36] edf34: e8bd8010 pop {r4, pc} edf38: e594301c ldr r3, [r4, #28] edf3c: e3530000 cmp r3, #0 ; 0x0 edf40: 1afffffa bne edf30 <js_CallTree(InterpState*, nanojit::Fragment*)+0x28> edf44: e5903024 ldr r3, [r0, #36] edf48: e5942004 ldr r2, [r4, #4] edf4c: e1a03103 lsl r3, r3, #2 edf50: e0822003 add r2, r2, r3 edf54: e5842020 str r2, [r4, #32] edf58: e584001c str r0, [r4, #28] edf5c: eafffff3 b edf30 <js_CallTree(InterpState*, nanojit::Fragment*)+0x28> Instruction 0xedf20 is again offsetting a pointer by 52. Looking at the source code my guess is line 246: 230 SideExit* FASTCALL 231 js_CallTree(InterpState* state, Fragment* f) 232 { 233 union { NIns *code; GuardRecord* (FASTCALL *func)(InterpState*, Fragment*); } u; 234 235 u.code = f->code(); 236 JS_ASSERT(u.code); 237 238 GuardRecord* rec; 239 #if defined(JS_NO_FASTCALL) && defined(NANOJIT_IA32) 240 SIMULATE_FASTCALL(rec, state, NULL, u.func); 241 #else 242 rec = u.func(state, NULL); 243 #endif 244 VMSideExit* lr = (VMSideExit*)rec->exit; 245 246 if (lr->exitType == NESTED_EXIT) { Is this the same crash in a different function?
About a week ago I upgraded my cross-compiler from gcc-4.3.4 to gcc-4.4.3. I rebuilt fennec - using 4-week old source files - and tried again. Now fennec works fine. I can browse websites with no alignment traps or crashes. Whether it is the new compiler, the newer source files, or the disabling of nanojit (bug 565312) which fixed it I cannot tell. Whatever the reason, I have no incentive to pursue this further unless it recurs. So I am happy for this bug to be closed.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.