Closed Bug 581888 Opened 15 years ago Closed 15 years ago

TEST-UNEXPECTED-FAIL... test_ctypes.xul | Exited with code -10 during test run

Categories

(Core :: js-ctypes, defect)

Product:
Core
Component:
js-ctypes
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: jaas, Unassigned)

References

Details

(Keywords: intermittent-failure)

I'm pretty sure this isn't from my patch. Bug 565380 is similar but the error code is different. TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/components/jsctypes-test/test_ctypes.xul | Exited with code -10 during test run Seen here: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280122393.1280122878.20873.gz#err0
Whiteboard: [orange]
This showed up before my commit, I think for the first time at changeset 247e849189a8.
I landed three things today: * ce8c5b97125c to change symbol_store.py, mochitest-chrome doesn't touch this code * e301cb6bddd6 to enable symbols on mac64 builds, since backed out by 247e849189a8/dc4f4587d548 * some mozconfig changes on mac64 to support symbols, http://hg.mozilla.org/build/buildbot-configs/rev/9340c8d65ce7 I will try backing out the mozconfig changes and forcing a new round of builds.
It's possible that the mozconfig-fu there confused libffi's configure script. Did the ctypes xpcshell tests also fail?
Builds with the mozconfig backout were http://hg.mozilla.org/mozilla-central/rev/5cda23bbfc29 5 opt and 5 debug mochitest-other runs on that didn't have this failure, and there was one unrelated orange (bug 557986). In the xpcshell tests there is TEST-INFO | /Users/cltbld/talos-slave/mozilla-central-snowleopard-debug-u-xpcshell/build/xpcshell/tests/jsctypes-test/unit/test_jsctypes.js | running test ... TEST-PASS | /Users/cltbld/talos-slave/mozilla-central-snowleopard-debug-u-xpcshell/build/xpcshell/tests/jsctypes-test/unit/test_jsctypes.js | test passed but no other references to 'ctypes'
I ran this chrome test locally and it is in fact crashing, although with a spectacularly unhelpful stack: Crash reason: EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE Crash address: 0x21bfa4a0 Thread 17 (crashed) 0 0x121bfa4a0 rbx = 0x00000001 r12 = 0x00000001 r13 = 0x00000001 r14 = 0x21bfa570 r15 = 0x212f4b80 rip = 0x21bfa4a0 rsp = 0x212f4b78 rbp = 0x212f4b80
Looking at the libffi bits in my objdir, it appears to have been correctly compiled for x86-64.
Did you reland the patches? If you didn't, the fact that this bug isn't collecting oranges probably means it did fix it. It could also be fixed by my ffi_arg landing a few weeks back. So if we're not seeing this anymore, with your patches landed, we should just close it out.
The backout of the mozconfig changes seems to have fixed this. We can revisit if we determine we need those changes.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Blocks: 438871
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.