Closed Bug 639542 Opened 14 years ago Closed 13 years ago

Crash [@ js_DeepBail(JSContext*) ] at address 0x204 due to frankenbuild

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dveditz, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

Firefox 3.6.15 shows a new topcrash at js_DeepBail() accessing address 0x204. If you look at the modules list this crash is due to a frankenbuild of 3.6.15 with a few files (firefox.exe, xul.dll) from 3.6.14 (build3). firefox.exe 1.9.2.4066 xul.dll 1.9.2.4066 xpcom.dll 1.9.2.4079 browserdirprovider.dll 1.9.2.4079 brwsrcmp.dll 1.9.2.4079 Unlike the frankenbuilds we saw between 3.6.13/3.6.14 (e.g. bug 631105) in this case xpcom.dll has been updated to the newer version rather than stuck on the old version with firefox.exe and xul.dll There's probably not anything we can do here (another bug tracks fixing the updater so we don't get frankenbuilds), mostly I'm filing this so there's a link from crash-stats and people don't beat themselves up trying to figure out where it came from. We know: same thing we've been battling. NB: there were older crashes at js_DeepBail() like bug 564510. This is not that bug, this one strictly covers crashes caused by frankenbuilds. In the configuration listed above the crashing address seems to always be 0x204. That address could move around (or more likely, the signature itself) with different dll version combinations.
Severity: normal → critical
Keywords: crash, topcrash
> (another bug tracks fixing the updater so we don't get frankenbuilds) can someone link that bug# please? I don't remember the #.
Bug 466778 which was backed out of mozilla-1.9.2 in case it was making the update situation worse. Currently on 1.9.2 the updater performs a file copy, updates the copy, then copies the updated file back over the original file late in the update process as it has always done. With the patch from Bug 466778 the updater performs a file rename instead of a copy early in the update process and if the rename fails (which is very unlikely) it rolls back early. If the rename succeeds all is clear to create the updated file. This should improve the success rate on all platforms. Bug 635161 should address the issue with firefox.exe not getting updated.
Depends on: 635161, 466778
Crash Signature: [@ js_DeepBail(JSContext*) ]
These only appear in 3.5 and 3.6 so resolving as works for me.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.