531663 - New Firefox 3.6b4 Crash [@ _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() ] Search Mozill

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect)

Description

[chris hofmann]

stack looks like

0  	nspr4.dll  	_PR_MD_ATOMIC_DECREMENT  	 nsprpub/pr/src/md/windows/ntmisc.c:1079
1 	xul.dll 	nsHttpChannel::Release 	netwerk/protocol/http/src/nsHttpChannel.cpp:4099
2 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base 	obj-firefox/xpcom/build/nsCOMPtr.cpp:81
3 	xul.dll 	nsIOService::NewChannelFromURI 	netwerk/base/src/nsIOService.cpp:607
4 	xul.dll 	NewImageChannel 	modules/libpr0n/src/imgLoader.cpp:324
5 	xul.dll 	imgLoader::LoadImage 	modules/libpr0n/src/imgLoader.cpp:1429
6 	xul.dll 	nsCOMPtr_base::assign_from_qi 	obj-firefox/xpcom/build/nsCOMPtr.cpp:96
7 	xul.dll 	nsImageBoxFrame::UpdateImage 	layout/xul/base/src/nsImageBoxFrame.cpp:273
8 	xul.dll 	nsINode::GetFlags 	obj-firefox/dist/include/nsINode.h:736
9 	xul.dll 	nsImageBoxFrame::AttributeChanged 	layout/xul/base/src/nsImageBoxFrame.cpp:174
10 	xul.dll 	nsCSSFrameConstructor::AttributeChanged 	layout/base/nsCSSFrameConstructor.cpp:8128

more reports at

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b4&query_search=signature&query_type=exact&date=&range_value=1&range_unit=weeks&do_query=1&signature=_PR_MD_ATOMIC_DECREMENT%20|%20nsHttpChannel%3A%3ARelease%28%29

not much to go on to start the investigation

looks like its happening only on Windows NT 5.1.2600 Service Pack 2  so far

crash seems to be happening very close to start up.


there has been some recent activity in the source file on the second line of the stack that may or may not be connected to this problem.

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/4c488520d1bf/netwerk/protocol/http/src/nsHttpChannel.cpp#l4099

bb4e5ea3ba69
2009-11-18 15:21 -0800	Jonas Sicking - Bug 529041: Deal with http channels not implementing nsIUploadChannel2. r=biesi
diff
browse
annotate	fc158dcd3472
2009-10-07 00:34 -0700	Jonas Sicking - Bug 491201 - Support sending File objects using XMLHttpRequest. r=sicking/biesi/bz sr=sicking a=jst

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Looking into this. It's crashing in the code I added, but it's a crashing in a codepath we take all the time, so not sure what's different in the cases it's crashing.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So for what it's worth, all 7 crashes here are from the same day, same OS, same CPU and almost the same time. So it's quite possibly all from the same person.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can't figure out what's going on here. The code where we're crashing is dead simple. This could be something like a developer of an extension crashing during development, a corrupted firefox file or something like that.

If we start seeing more crashes I'll look into this again.

Comment 4

[chris hofmann]

not much help in the url's


 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 \N
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank
 _PR_MD_ATOMIC_DECREMENT | nsHttpChannel::Release() 3.6b4 about:blank

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It looked like all of the crashes were startup crashes. Which makes sense given that this code is run every time a http-url is fetched (i.e. *a lot*)

Comment 6

[timeless]

from memory, we had a virus scanner which replaced our http impl (see problems w/ nsIUploadChannel2). This could be similar...

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I know, that is why this code was written. Though in the end it turned out they weren't replacing the http channel, just implementing new protocols that implemented nsIHttpChannel.

In any case that doesn't really explain this crash.