Closed Bug 325392 Opened 20 years ago Closed 17 years ago

Crash on shutdown in preference observer with this testcase

Categories

(Core Graveyard :: Java: OJI, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: jaas)

References

Details

(Keywords: crash, fixed1.9.1, testcase, Whiteboard: [sg:dos] stack overflow)

Attachments

(3 files, 2 obsolete files)

See upcoming testcase which makes Mozilla crash on shutdown. You need to test the testcase locally to get the crash.
Attached file testcase —
Attached file Backtrace —
#0 0x6ca46aaa in nsPrefBranch::freeObserverList() (this=0xdd6d68) at c:/mozilla/mozilla/modules/libpref/src/nsPrefBranch.cpp:787 #1 0x6ca4676a in nsPrefBranch::Observe(nsISupports*, char const*, wchar_t const *) (this=0xdd6d68, aSubject=0x3fc754, aTopic=0x6feccfd0 "xpcom-shutdown", someData=0x0) at c:/mozilla/mozilla/modules/libpref/src/nsPrefBranch.cpp:727 etc.
Whiteboard: DUPEME
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
(I tested this on latest-trunk mozilla-central nightly build on WinXP SP3) 0:000> !exploitable -v HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception *** WARNING: Unable to verify checksum for C:\Documents and Settings\Administrator\Desktop\firefox\xul.dll Exception Faulting Address: 0x355c42 First Chance Exception Type: STATUS_STACK_OVERFLOW (0xC00000FD) Faulting Instruction:00355c42 call nspr4!_md_current_thread (00358450) Basic Block: 00355c42 call nspr4!_md_current_thread (00358450) Exception Hash (Major/Minor): 0x37f0c23.0x4f7e150b Stack Trace: nspr4!PR_Lock+0x2 nspr4!PR_EnterMonitor+0x22 xul!nsComponentManagerImpl::GetServiceByContractID+0x34 xul!CallGetService+0x25 xul!nsCOMPtr_base::assign_from_gs_contractid+0x19 xul!nsCOMPtr<nsIObserverService>::nsCOMPtr<nsIObserverService>+0x14 xul!nsJVMManager::~nsJVMManager+0x40 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 xul!nsJVMManager::Internal::Release+0x1b xul!nsJVMManager::Release+0xd xul!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>+0xf xul!nsObserverList::RemoveObserver+0x98 xul!nsObserverService::RemoveObserver+0x4c xul!nsJVMManager::~nsJVMManager+0x62 xul!nsJVMManager::`scalar deleting destructor'+0x8 Instruction Address: 0x355c42 Description: Stack Overflow Short Description: StackOverflow Exploitability Classification: UNKNOWN Recommended Bug Title: Stack Overflow starting at nspr4!PR_Lock+0x2 (Hash=0x37f0c23.0x4f7e150b)
http://mxr.mozilla.org/mozilla-central/source/modules/oji/src/nsJVMManager.cpp?mark=403-404,413-414,853-871#385 could someone please write something which looks for [constructor] foo.addObserver(... WEAK:=FALSE) [destructor] foo.removeObserver(... ) This is stupid, as the only way to reach destructor is if the refcount reaches 0.
Component: Preferences: Backend → Java: OJI
Attached patch fix it (obsolete) — — Splinter Review
i'm well aware that josh wants to kill oji. we should for older branches fix this.
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #369924 - Flags: review?(joshmoz)
Attachment #369924 - Flags: approval1.9.1?
Attachment #369924 - Flags: approval1.9.0.10?
Blocks: 485834
Josh, can you review this please?
Comment on attachment 369924 [details] [diff] [review] fix it This needs review before approval on either 1.9.1 or 1.9.0.
Attachment #369924 - Flags: approval1.9.1?
Attachment #369924 - Flags: approval1.9.0.10?
Attachment #369924 - Flags: review?(joshmoz) → review+
Attachment #369924 - Flags: approval1.9.1?
Attachment #369924 - Flags: approval1.9.0.9?
Attachment #369924 - Flags: approval1.9.0.10?
Comment on attachment 369924 [details] [diff] [review] fix it This needs trunk landing at least before we'll consider it for 1.9.0.
Attachment #369924 - Flags: approval1.9.0.9?
Attachment #369924 - Flags: approval1.9.0.10?
This can't land on the trunk, this code has been removed in 1.9.2.
Then lets get it in 1.9.1 first.
you'd need to approve it!
Whiteboard: DUPEME
Comment on attachment 369924 [details] [diff] [review] fix it a191=beltzner
Attachment #369924 - Flags: approval1.9.1? → approval1.9.1+
Whiteboard: [needs 1.9.1 landing]
Version: Trunk → 1.9.1 Branch
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Target Milestone: --- → mozilla1.9.1b4
verified FIXED on builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090422 Minefield/3.6a1pre ID:20090422044118 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre ID:20090422042031
Status: RESOLVED → VERIFIED
Attachment #369924 - Flags: approval1.9.0.10?
Whiteboard: [sg:dos] stack overflow
Comment on attachment 369924 [details] [diff] [review] fix it Approved for 1.9.0.11, a=dveditz for release-drivers
Attachment #369924 - Flags: approval1.9.0.11? → approval1.9.0.11+
Checked in on 1.9.0 branch. Checking in modules/oji/src/nsJVMManager.cpp; /cvsroot/mozilla/modules/oji/src/nsJVMManager.cpp,v <-- nsJVMManager.cpp new revision: 1.84; previous revision: 1.83
Keywords: fixed1.9.0
Attached test case is still crashing when I test it using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11pre) Gecko/2009051504 GranParadiso/3.0.11pre. Crash report at http://crash-stats.mozilla.com/report/index/26677caf-6aed-40c2-b7d8-a31662090515?p=1.
I see that too: bp-77d3a203-e6b8-4459-978c-edabd2090517 We're both seeing a different crash than what was claimed earlier in this bug, and given the random address at the top of the stack the new crash is a bit scary (but thankfully inaccessible from content). In a 3.0.10 build on Mac the testcase crashes me immediately, not at shutdown, and the stack is useless. bp-f90805f4-0e5d-43b5-8e3a-d3a662090517 bp-c2964d51-3481-47d5-a012-13a462090517 So that seems to be a different bug, too.
Do we need to open another bug or ??
Same crash on 1.9.1: bp-41c0baab-22db-4b56-9f56-c40e02090518 removing the verified1.9.1 keyword.
Backed this out from the 1.9.0 branch, the resulting crash looks exploitable whereas a stack overflow isn't. This should be backed out from 1.9.1 as well.
Group: core-security
Keywords: fixed1.9.0.11
Attachment #369924 - Flags: approval1.9.0.11+ → approval1.9.0.11-
Comment on attachment 369924 [details] [diff] [review] fix it unapproving this patch, the resulting crash is scarier looking than the original.
Comment on attachment 369924 [details] [diff] [review] fix it Removing the approval1.9.1+ flag. (I'd minus it if I could.) This wasn't ready for landing as it makes the crash worse, per dveditz above.
Attachment #369924 - Flags: approval1.9.1+
Attached patch fix v2.0 (obsolete) — — Splinter Review
This seems to fix all of the crashes. The problem is that even after timeless's fix, the aggregate constructor creates an nsJVMManager object, the constructor for that object registers as an observer (while its refcount is 0), then the aggregate constructor deletes the nsJVMManager object it created. The shutdown crash happens because the observer service tries to access the deleted object.
Assignee: timeless → joshmoz
Attachment #369924 - Attachment is obsolete: true
Attachment #379811 - Flags: review?(jst)
There is some pretty awful code that needs to be fixed here, we should take this for 1.9.1 if possible.
Flags: blocking1.9.1?
Should we block the release on it, or take a reviewed patch if one comes along?
Flags: wanted1.9.1.x+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Attachment #379811 - Flags: review?(jst) → review?(bzbarsky)
Attachment #379811 - Flags: superreview+
Attachment #379811 - Flags: review?(bzbarsky)
Attachment #379811 - Flags: review+
Comment on attachment 379811 [details] [diff] [review] fix v2.0 s/nsJVMManager::Init/Init/ and looks great.
Attached patch fix v2.1 — — Splinter Review
Attachment #379811 - Attachment is obsolete: true
Attachment #380222 - Flags: approval1.9.1?
Comment on attachment 380222 [details] [diff] [review] fix v2.1 a191=beltzner, crossing fingers
Attachment #380222 - Flags: approval1.9.1? → approval1.9.1+
Keywords: fixed1.9.1
Product: Core → Core Graveyard
Target Milestone: mozilla1.9.1b4 → ---
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: