The default bug view has changed. See this FAQ.

XPCJSRuntime::XPCJSRuntime shouldn't touch mJSRuntime without null checking something

RESOLVED FIXED in mozilla1.9.2b1

Status

()

Core
XPConnect
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

Trunk
mozilla1.9.2b1
Points:
---
Bug Flags:
blocking1.9.2 +
wanted1.9.1 +

Firefox Tracking Flags

(status1.9.2 beta1-fixed, status1.9.1 .8-fixed)

Details

(URL)

Attachments

(1 attachment)

1022 bytes, patch
Ben Turner (not reading bugmail, use the needinfo flag!)
: review+
Details | Diff | Splinter Review
(Assignee)

Description

8 years ago
hi gal. please be more careful about using locks which are otherwise null checked.

I'm not sure what this code is doing, but you're the last person to add code which doesn't make sense. And we have reports of crashes (bug 496628, mostly incomprehensible) involving a PR_Lock call from this call site, i.e. you.

It's true that there was code ifdef DEBUG to use mJSRuntime, but it also null checked mJSRuntime before using it.
(Assignee)

Comment 1

8 years ago
Created attachment 382002 [details] [diff] [review]
only create mWatchdogThread if mWatchdogWakeup is around to release it
Attachment #382002 - Flags: superreview?(jst)
Attachment #382002 - Flags: review?(gal)
Timeless, thanks -- looks like an honest mistake. Should try to fix soon, maybe for 1.9.1. The bug you cite, bug 496628, was marked INVALID, blamed on a distro. But if this bug was the cause, then we should probably change that bug's status retroactively. We may not be able to prove what caused that bug, though.

/be
Flags: wanted1.9.1?
Flags: blocking1.9.2?

Updated

8 years ago
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.2?
Flags: blocking1.9.2+

Comment 3

8 years ago
Comment on attachment 382002 [details] [diff] [review]
only create mWatchdogThread if mWatchdogWakeup is around to release it

Ben, can you review?
Attachment #382002 - Flags: review?(gal) → review?(bent.mozilla)
Attachment #382002 - Flags: review?(bent.mozilla) → review+
Comment on attachment 382002 [details] [diff] [review]
only create mWatchdogThread if mWatchdogWakeup is around to release it

This looks fine.

Updated

8 years ago
Attachment #382002 - Flags: superreview?(jst) → superreview+
(Assignee)

Comment 5

8 years ago
http://hg.mozilla.org/mozilla-central/rev/2356ce183942
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Mass change: adding fixed1.9.2 keyword

(This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)
Keywords: fixed1.9.2
status1.9.2: --- → beta1-fixed
Keywords: fixed1.9.2
This didn't make it back to 1.9.1, did it? I was poking around some crash reports and saw a 3.5.4 crash here:
http://crash-stats.mozilla.com/report/index/f5cd0d58-932b-4448-8072-1ff432091203
(Assignee)

Updated

7 years ago
Duplicate of this bug: 496628
Attachment #382002 - Flags: approval1.9.1.7?
Comment on attachment 382002 [details] [diff] [review]
only create mWatchdogThread if mWatchdogWakeup is around to release it

Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #382002 - Flags: approval1.9.1.8? → approval1.9.1.8+
Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/15fb9a1c8f71
status1.9.1: --- → .8-fixed
Timeless, is there any reliable way for QA to test this fix? Having a stack we can query on to determine no more crashes happen?
Target Milestone: --- → mozilla1.9.2b1
(Assignee)

Comment 12

7 years ago
there's going to be a different signature for each platform...

*IF* pthread_mutex_lock, RtlpWaitForCriticalSection and RtlEnterCriticalSection are added to some ignore list, then instead of [@ RtlpWaitForCriticalSection | RtlEnterCriticalSection ] we could look for [@ PR_Lock | XPCJSRuntime::XPCJSRuntime] with crash address 0x10

this is based on ted's crash report which clearly is fixed by this bug:
UUID	f5cd0d58-932b-4448-8072-1ff432091203
Crash Address	0x10
0 	ntdll.dll 	RtlpWaitForCriticalSection 	
1 	ntdll.dll 	RtlEnterCriticalSection 	
2 	nspr4.dll 	PR_Lock
3 	xul.dll 	XPCJSRuntime::XPCJSRuntime

I'm still not quite sure about the Linux crash, the interesting pointer was NO_SCOPE_SHARING_TODO (lock=0xfeedbeef), which doesn't make much sense. Brendan would have to explain other conditions under which we'd get that value. It's possible that an optimizer confused the debugger and lock really is 0x0.
We have a lot of those PRLOCK signatures on crashstat. See the link below. But while checking some of the crashes none has the same stack as given by Ted. So we should probably wait until 3.5.8 has been released and monitor the crash stats a couple of days after the release. Without a testcase I do not want to mark it as verified on 1.9.1. Thanks timeless!

http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=exact&query=PR_Lock&date=&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=PR_Lock
You need to log in before you can comment on or make changes to this bug.