Closed Bug 354380 Opened 18 years ago Closed 17 years ago

crashes [@ _PR_MD_ATOMIC_DECREMENT]

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: smaug, Assigned: jst)

Details

(Keywords: topcrash)

Crash Data

Attachments

(1 file)

Possible fix.
2.38 KB, patch
mrbkap
: review+
sicking
: superreview+
Details | Diff | Splinter Review 
currently #11 trunk crash.
Stack trace looks always like this:
_PR_MD_ATOMIC_DECREMENT  [mozilla\nsprpub\pr\src\md\windows\ntmisc.c, line 733]
JS_GC  [mozilla\js\src\jsapi.c, line 1944]
NS_ProcessNextEvent_P  [mozilla\xpcom\build\nsthreadutils.cpp, line 225]
nsBaseAppShell::Run  [mozilla\widget\src\xpwidgets\nsbaseappshell.cpp, line 153]
0x003c3dbc
0xccccc3c0
Some of this reports are from my machine, at least: TB24026892E, TB24021037X with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061001 Mnenhy/0.7.4.10002 SeaMonkey/1.5a {Build ID: 2006100108}

Unfortunately I can't give a propper way to reproduce. Mostly my used SeaMonkey-XPFE-Trunk-Builds will crash after a while of browsing with multiple Tabs open, when I try to open another Tab with Mouse-Middleclick, sometimes when I try to close a Tab with Middleclick. 

Sometimes I have checked my Mailaccounts before the crash, sometimes SeaMonkey will crash before I opend MailNews. Not too helpful. 


Installed Add-Ons are:

Mnenhy 0.7.4.10002
Message ID Finder 2.0
Flashblock 1.3.1
deutsches_w_ouml_rterbuch-1.0.1-fx+zm+tb.xpi
enigmail-trunk-tb-win32-trunk.xpi {Build 20061002}

Remembering Bug 322414 I have deinstalled Flashblock for testing, also don't use Enigmail because it was broken on Trunk for a while, but this won't aviod SeaMonkey from crashing. Hmm.
Flags: blocking1.9?
This must be crashing in some function tail-called from JS_GC, which for a trunk build from 2006/10/01 is js_RunCloseHooks. But I don't see any atomic increment macro calls in that function.

Cc'ing people who can help diagnose the talkback better than I can.

/be
After a while without Crashes and real testing, 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Mnenhy/0.7.4.10005 SeaMonkey/1.5a
will crash again, TB28143292H, TB28140192X but the stacks won't help. 

As described in Comment #1, reproduce the crash is not too easy. 
Best way to get this crash is to open multiple Tabs and finaly a Site with pictures-series like:
http://www.sueddeutsche.de/sport/weitere/special/299/67232/index.html/sport/weltfussball/bildstrecke/577/77500/p0/article.html?img=0.0
or http://www.spiegel.de/fotostrecke/0,5538,18404,00.html for example.

and click very fast from one picture to the next one; don't wait until the page is fully loaded when click "go next picture". 

Link open behaviour is set to "Open links meant to open a new window in: A new tab in the current window" in preferences. 

When I start SeaMonkey, I first open this Sites in Tabs:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
http://www.heise.de/
and than start browsing other Sites like http://www.spiegel.de/ and http://www.sueddeutsche.de/ in new Tabs. 
#1 crash now for seamonkey trunk
and top 5 crash for FF trunk (lots of them)

Examining 30+ talkbacks no variation from TB29582787 and Tobias' stack except a few with no stack, and a couple others pasted below in case they might help...

TB29582787
_PR_MD_ATOMIC_DECREMENT  [mozilla/nsprpub/pr/src/md/windows/ntmisc.c, line 733]
JS_GC  [mozilla/js/src/jsapi.c, line 1889]


TB28362808 from Nelson Bolyard (examples of same stack TB28267169, TB28255268)
Stack Signature	_PR_MD_ATOMIC_DECREMENT aeffbdaf
Product ID	MozillaTrunk
Build ID	2006122608
Trigger Time	2007-01-14 20:04:01.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	nspr4.dll + (00017959)
URL visited	http://www.filmcritic.com/misc/emporium.nsf/2a460f93626cd4678625624c007f2b46/c86e3975ad708f0188257260006449c0?OpenDocument
User Comments	followed link from http://movies.yahoo.com/movie/1808718535/critic to this page. Boom. /Nelson
Since Last Crash	340438 sec
Total Uptime	726611 sec
Trigger Reason	Access violation
Source File, Line No.	d:\builds\tinderbox\seamonkeytrunk\winnt_5.2_clobber\mozilla\nsprpub\pr\src\md\windows\ntmisc.c, line 733
Stack Trace 	
_PR_MD_ATOMIC_DECREMENT  [mozilla/nsprpub/pr/src/md/windows/ntmisc.c, line 733]
JS_GC  [mozilla/js/src/jsapi.c, line 1892]
NS_ProcessNextEvent_P  [mozilla/xpcom/build/nsthreadutils.cpp, line 225]
nsBaseAppShell::Run  [mozilla/widget/src/xpwidgets/nsbaseappshell.cpp, line 153]
main  [mozilla/xpfe/bootstrap/nsapprunner.cpp, line 1747]
WinMain  [mozilla/xpfe/bootstrap/nsapprunner.cpp, line 1771]
kernel32.dll + 0x16fd7 (0x7c816fd7)


found 3 like TB29631901 "Closed page with Flash playing" and 
TB29517717  
Stack Signature	_PR_MD_ATOMIC_DECREMENT 45742d0a
Product ID	MozillaTrunk
Build ID	2007021310
Trigger Time	2007-02-20 10:53:52.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	nspr4.dll + (000179b9)
URL visited	
User Comments	
Since Last Crash	874 sec
Total Uptime	136731 sec
Trigger Reason	Access violation
Source File, Line No.	d:\builds\tinderbox\seamonkeytrunk\winnt_5.2_clobber\mozilla\nsprpub\pr\src\md\windows\ntmisc.c, line 733
Stack Trace 	
_PR_MD_ATOMIC_DECREMENT  [mozilla/nsprpub/pr/src/md/windows/ntmisc.c, line 733]
JS_GC  [mozilla/js/src/jsapi.c, line 1889]
DoOnShutdown  [mozilla/xpfe/bootstrap/nsapprunner.cpp, line 741]
main  [mozilla/xpfe/bootstrap/nsapprunner.cpp, line 1730]
WinMain  [mozilla/xpfe/bootstrap/nsapprunner.cpp, line 1746]
KERNEL32.dll + 0x289a5 (0x7c5989a5)


An old Sunbird crash TB28199323
_PR_MD_ATOMIC_DECREMENT ef51666c
Product ID	SunbirdTrunk
Build ID	2006100618
Trigger Time	2007-01-09 15:29:04.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	nspr4.dll + (00017939)
URL visited	
User Comments	
Since Last Crash	2122 sec
Total Uptime	2122 sec
Trigger Reason	Access violation
Source File, Line No.	d:\builds\tinderbox\sunbird-trunk\winnt_5.2_depend\mozilla\nsprpub\pr\src\md\windows\ntmisc.c, line 733
Stack Trace 	
_PR_MD_ATOMIC_DECREMENT  [mozilla/nsprpub/pr/src/md/windows/ntmisc.c, line 733]
DOMGCCallback  [mozilla/dom/src/base/nsjsenvironment.cpp, line 3151]
JS_GC  [mozilla/js/src/jsapi.c, line 1944]
NS_ProcessNextEvent_P  [mozilla/xpcom/build/nsthreadutils.cpp, line 225]
nsXULWindow::ShowModal  [mozilla/xpfe/appshell/src/nsxulwindow.cpp, line 402]
nsContentTreeOwner::ShowAsModal  [mozilla/xpfe/appshell/src/nscontenttreeowner.cpp, line 503]


Note the yahoo related crashes of bug 354912 and its ilk are gone from current builds.
Severity: major → critical
Since this build Minefield started crashing a lot (@ _PR_MD_ATOMIC_DECREMENT)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070628 Minefield/3.0a6pre ID:2007062805

Crash reports:
1341e766-25aa-11dc-a5cf-001a4bd43e5c
31ebbee1-2593-11dc-9ee3-001a4bd43ef6
405991ab-2593-11dc-b3d7-001a4bd43e5c
c552c75e-2596-11dc-bed6-001a4bd43ef6
e186314f-25ab-11dc-851c-001a4bd43ed6
ff33bfde-25a8-11dc-abe3-001a4bd43e5c
nikolakocicbz@gmail.com: i'm not sure where you're getting your incident ids, but if they come in a form that doesn't include a bp- prefix please let me know asap. if they do come w/ a bp- prefix, please *STOP* stripping it.

bugzilla will eventually make links out of the following items, but it *can't* make links out of the ones you pasted into the bug.

bp-1341e766-25aa-11dc-a5cf-001a4bd43e5c
bp-31ebbee1-2593-11dc-9ee3-001a4bd43ef6
bp-405991ab-2593-11dc-b3d7-001a4bd43e5c
bp-c552c75e-2596-11dc-bed6-001a4bd43ef6
bp-e186314f-25ab-11dc-851c-001a4bd43ed6
bp-ff33bfde-25a8-11dc-abe3-001a4bd43e5c
we cant ship alpha 6 crashing this much ive crashes over 30 times today from this
for reference, http://code.google.com/p/socorro/issues/list https://crash-reports.mozilla.com/reports/report/index/1341e766-25aa-11dc-a5cf-001a4bd43e5c

shows:
frame signature 
0 _PR_MD_ATOMIC_DECREMENT 
1 _releaseobject 
2 NPObjWrapper_Finalize 
3 js_FinalizeObject 
4 js_GC 
5 JS_GC 
6 nsXPConnect::BeginCycleCollection() 
7 nsXPConnect::GetContext(JSContext *,nsXPConnect *) 
8 nsCycleCollector::Collect(unsigned int) 
9 nsCycleCollector_collect() 

which is not really more interesting/useful 

https://crash-reports.mozilla.com/reports/report/index/e186314f-25ab-11dc-851c-001a4bd43ed6
Stack of Crashing Thread
frame signature 
0 _PR_MD_ATOMIC_DECREMENT 
1 _releaseobject 
2 NPObjWrapper_Finalize 
3 js_FinalizeObject 
4 js_GC 
5 JS_GC 
6 nsXREDirProvider::DoShutdown() 
7 ScopedXPCOMStartup::~ScopedXPCOMStartup() 
8 XRE_main 
9 main 

assuming the incidents are the same set, we now have a stack that doesn't appear to suffer from tail call recursion which fingers plugins (not at all surprising).

note that one crash was clearly late shutdown, the others were all normal runtime cycle collections.
Assignee: general → nobody
Component: JavaScript Engine → Plug-ins
QA Contact: general → plugins
https://crash-reports.mozilla.com/reports/report/index/d58af714-25db-11dc-9fca-001a4bd46e84

is perhaps the most simpliest of the stacks

0  	_PR_MD_ATOMIC_DECREMENT
1 	xul.dll@0x3dbd34
2 	js_GC
3 	JS_GC
4 	xul.dll@0xfae0
Attached patch Possible fix. — — Splinter Review 
I haven't thought about this enough to convince myself that this is really the fix here as I don't really know what the problem really is yet. Judging from the call stack it seems like the problem is that a plugin exposed a NPObject to JS and then released and destroyed the NPObject while JS still held a reference to the NPObject. This would make us crash once the JS object is finalized as its private data would point to a deleted NPObject. This patch should fix that, anyone have any way to test this?
well best way to test is check it in since i crash quite reliably with this bug recently ill be able to tell you with 99 percent certainty if it fixes it
gabe: can you build or do you need someone else to produce a build with this patch for you to test?

/be
well i cant build myself 
I'm contacting Gabe over a build with the patch included, FYI
I just did a build with this patch included and I'm seeing a lot of random crashing now too. I can't confirm that it's this stack, however, as I don't export symbols or anything for my builds. But it certainly seems to fit the M.O. for this crash anyway.
well based on build ryan sent me im pretty sure that patch does nothing 
(In reply to comment #16)
> I just did a build with this patch included and I'm seeing a lot of random
> crashing now too. I can't confirm that it's this stack, however, as I don't
> export symbols or anything for my builds. But it certainly seems to fit the
> M.O. for this crash anyway.

Thanks for testing. Are you seeing more, or the same amount of random crashes with and w/o this patch? If you're seeing more crashes then I might have messed something up in that patch...
jst - this patch could actually be exactly the fix for this bug. The problem is, the bug we were hitting was bug 386332 which crashed at the same point but with a different stack. That's why the patch wasn't fixing our crashes.
(In reply to comment #19)
> jst - this patch could actually be exactly the fix for this bug. The problem
> is, the bug we were hitting was bug 386332 which crashed at the same point but
> with a different stack. That's why the patch wasn't fixing our crashes.
> 

Ah, I see. Any chance you could test again now that bug 386332 is fixed (by backing out bug 347743)?
Blocking- due to lack of feedback here.
Flags: blocking1.9? → blocking1.9-
So, as Ryan pointed out, this bug got hijacked for the crash that was really bug 386332. This crash was the #33 topcrash in 3.0a7 in Breakpad, so there are a lot of more severe topcrashes.

That said, we're still getting roughly twenty or thirty crashes a day with this stacktrace -- enough to land jst's patch and see if it fixes the crash. I think we should give it a shot.
Sounds like a bad crash, so reassigning to jst to get this landed and tested.
Assignee: nobody → jst
Flags: blocking1.9- → blocking1.9?
Comment on attachment 270257 [details] [diff] [review]
Possible fix.

This is an attempt at fixing a problem with us running into dead private data in JSObjects due to plugins not properly managing their object lifetime. Not pretty, but might be worth landing...
Attachment #270257 - Flags: superreview?(jonas)
Attachment #270257 - Flags: review?(mrbkap)
Attachment #270257 - Flags: review?(mrbkap) → review+
Attachment #270257 - Flags: superreview?(jonas) → superreview+
Status: NEW → ASSIGNED
Flags: blocking1.9? → blocking1.9+
Fix checked in. I'm closing this bug, but if this still appears, please reopen this bug.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Crash Signature: [@ _PR_MD_ATOMIC_DECREMENT]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: