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)
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)
|
478 bytes,
text/html
|
Details | |
|
1.50 KB,
text/plain
|
Details | |
|
4.24 KB,
patch
|
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
See upcoming testcase which makes Mozilla crash on shutdown.
You need to test the testcase locally to get the crash.
| Reporter | ||
Comment 1•20 years ago
|
||
| Reporter | ||
Comment 2•20 years ago
|
||
#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.
Comment 3•18 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Comment 4•17 years ago
|
||
(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
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?
Comment 7•17 years ago
|
||
Josh, can you review this please?
Comment 8•17 years ago
|
||
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 9•17 years ago
|
||
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?
| Assignee | ||
Comment 10•17 years ago
|
||
This can't land on the trunk, this code has been removed in 1.9.2.
Comment 11•17 years ago
|
||
Then lets get it in 1.9.1 first.
Comment 12•17 years ago
|
||
you'd need to approve it!
Updated•17 years ago
|
Whiteboard: DUPEME
Comment 13•17 years ago
|
||
Comment on attachment 369924 [details] [diff] [review]
fix it
a191=beltzner
Attachment #369924 -
Flags: approval1.9.1? → approval1.9.1+
Updated•17 years ago
|
Keywords: checkin-needed
Updated•17 years ago
|
Whiteboard: [needs 1.9.1 landing]
Version: Trunk → 1.9.1 Branch
Comment 14•17 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed → fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Target Milestone: --- → mozilla1.9.1b4
Comment 15•17 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
Attachment #369924 -
Flags: approval1.9.0.10?
Updated•17 years ago
|
Whiteboard: [sg:dos] stack overflow
Comment 16•17 years ago
|
||
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+
| Assignee | ||
Comment 17•17 years ago
|
||
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
Updated•17 years ago
|
Keywords: fixed1.9.0 → fixed1.9.0.11
Comment 18•17 years ago
|
||
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.
Comment 19•17 years ago
|
||
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.
Comment 20•17 years ago
|
||
Do we need to open another bug or ??
Comment 21•17 years ago
|
||
Same crash on 1.9.1: bp-41c0baab-22db-4b56-9f56-c40e02090518
removing the verified1.9.1 keyword.
Keywords: verified1.9.1 → fixed1.9.1
Comment 22•17 years ago
|
||
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
Updated•17 years ago
|
Attachment #369924 -
Flags: approval1.9.0.11+ → approval1.9.0.11-
Comment 23•17 years ago
|
||
Comment on attachment 369924 [details] [diff] [review]
fix it
unapproving this patch, the resulting crash is scarier looking than the original.
| Assignee | ||
Comment 24•17 years ago
|
||
backed out from the 1.9.1 branch
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5342c75bb174
Updated•17 years ago
|
Keywords: fixed1.9.1
Comment 25•17 years ago
|
||
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+
| Assignee | ||
Comment 26•17 years ago
|
||
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)
| Assignee | ||
Comment 27•17 years ago
|
||
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?
Comment 28•17 years ago
|
||
Should we block the release on it, or take a reviewed patch if one comes along?
Updated•17 years ago
|
Flags: wanted1.9.1.x+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Attachment #379811 -
Flags: review?(jst) → review?(bzbarsky)
Updated•17 years ago
|
Attachment #379811 -
Flags: superreview+
Attachment #379811 -
Flags: review?(bzbarsky)
Attachment #379811 -
Flags: review+
Comment 29•17 years ago
|
||
Comment on attachment 379811 [details] [diff] [review]
fix v2.0
s/nsJVMManager::Init/Init/ and looks great.
| Assignee | ||
Comment 30•17 years ago
|
||
Attachment #379811 -
Attachment is obsolete: true
Attachment #380222 -
Flags: approval1.9.1?
Comment 31•17 years ago
|
||
Comment on attachment 380222 [details] [diff] [review]
fix v2.1
a191=beltzner, crossing fingers
Attachment #380222 -
Flags: approval1.9.1? → approval1.9.1+
| Assignee | ||
Comment 32•17 years ago
|
||
pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6c571818ffaa
Keywords: fixed1.9.1
Product: Core → Core Graveyard
Target Milestone: mozilla1.9.1b4 → ---
Updated•15 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•