609252 - [D2D] Firefox 4.0b8pre 64-bit Crash Report [@ mozcrt19.dll@0x87c7 ]

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Carsten Book [:Tomcat]]

Seems this is a new Firefox 4.0beta8pre Regression - Firefox 4.0b8pre Crash Report [@ mozcrt19.dll@0x87c7 ] - http://crash-stats.mozilla.com/report/list?signature=mozcrt19.dll@0x87c7 - all windows crashes, no comments so far. Also its currently #18 topcrash on the topcrash list

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	mozcrt19.dll 	mozcrt19.dll@0x87c7 	
1 	mozcrt19.dll 	mozcrt19.dll@0x9856 	
2 	mozcrt19.dll 	mozcrt19.dll@0x9a07 	
3 	xul.dll 	xul.dll@0x1e421d 	
4 	xul.dll 	xul.dll@0x1e421d 	
5 	mozcrt19.dll 	mozcrt19.dll@0x9db2 	
6 	mozcrt19.dll 	mozcrt19.dll@0xaa91 	
7 	xul.dll 	xul.dll@0x1e421d 	
8 	mozalloc.dll 	mozalloc.dll@0x1014 	
9 	xul.dll 	xul.dll@0xae3873 	
10 	xul.dll 	xul.dll@0xae323f 	
11 	xul.dll 	xul.dll@0xae3e40 	
12 	xul.dll 	xul.dll@0x10bf687 	
13 	xul.dll 	xul.dll@0x87df02 	
14 	mozjs.dll 	mozjs.dll@0x874f6 	
15 	mozjs.dll 	mozjs.dll@0x4da8b 	
16 	mozjs.dll 	mozjs.dll@0x255c7f 	
17 	xul.dll 	xul.dll@0xae3bd1 	
18 	mozjs.dll 	mozjs.dll@0x4f4db 	
19 	xul.dll 	xul.dll@0x10bf687 	
20 	xul.dll 	xul.dll@0x87e2e8 	
21 	xul.dll 	xul.dll@0x1e421d 	
22 	xul.dll 	xul.dll@0xf5708f 	
23 	xul.dll 	xul.dll@0x87ded3 	
24 	xul.dll 	xul.dll@0xae3bd1 	
25 	xul.dll 	xul.dll@0x1064a27 	
26 	xul.dll 	xul.dll@0x10bf687 	
27 	xul.dll 	xul.dll@0x89e58c 	
28 	xul.dll 	xul.dll@0x1064c97 	
29 	xul.dll 	xul.dll@0xf5cab7 	
30 	xul.dll 	xul.dll@0xae3bd1 	
31 	xul.dll 	xul.dll@0x1064a27 	
32 	xul.dll 	xul.dll@0x10bf687 	
33 	xul.dll 	xul.dll@0x5079b6 	
34 	xul.dll 	xul.dll@0xae3fb7 	
35 	xul.dll 	xul.dll@0xae4844 	
36 	xul.dll 	xul.dll@0x93a5e2 	
37 	mozcrt19.dll 	mozcrt19.dll@0x8dfc 	
38 	xul.dll 	xul.dll@0xf99bf7 	
39 	xul.dll 	xul.dll@0x103185f 	
40 	xul.dll 	xul.dll@0x10bf687 	
41 	xul.dll 	xul.dll@0xabc4a4 	
42 	xul.dll 	xul.dll@0xae4436 	
43 	xul.dll 	xul.dll@0x1e4277 	
44 	xul.dll 	xul.dll@0x3ca847 	
45 	xul.dll 	xul.dll@0x368b81 	
46 	xul.dll 	xul.dll@0x10c4517 	
47 	xul.dll 	xul.dll@0x3a3d25 	
48 	xul.dll 	xul.dll@0x372b7a 	
49 	xul.dll 	xul.dll@0x3a3fb3 	
50 	xul.dll 	xul.dll@0x3cab64 	
51 	xul.dll 	xul.dll@0x3a3e44 	
52 	xul.dll 	xul.dll@0x36ec3d 	
53 	xul.dll 	xul.dll@0x3a0673

Comment 1

[Carsten Book [:Tomcat]]

first build id where this was first seen was 20101025161627

Comment 2

[Benjamin Smedberg]

There are no symbols. This is likely an existing crash which for some reason a particular build doesn't have symbols or they aren't processing correctly.

Comment 3

[Carsten Book [:Tomcat]]

(In reply to comment #2)
> There are no symbols. This is likely an existing crash which for some reason a
> particular build doesn't have symbols or they aren't processing correctly.

hmm benjamin this problem can be seen on different build ids, so its more breakpad bug ?

Comment 4

[Scoobidiver (away)]

It is #2 top crasher in the latest 64-bit nightly build.
Crashes first appeared in 4.0b8pre/20101026 build.

One comment says:
"I was printing a microsoft excel 2007 document and changed the printer to a networked printer in the dialog box, then Minefield crashed. Not sure if it is related but it happened right when I did that."

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b8pre&query_search=signature&query_type=exact&query=mozcrt19.dll%400x87c7&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozcrt19.dll%400x87c7

Comment 5

[chris hofmann]

yeah, this one is strange.  still showing up in builds from nov 22 and in builds across many days since the first of the month.

its moved up to #10 top crash on trunk,  sometimes hitting 20 crash per day.

what are some things that we might be able to do to get a better handle on this?

I guess figuring out regression range could be one step.

Comment 6

[Scoobidiver (away)]

Here is a very large regression range (5 days of checkin because 64-bit nightlies are not build every night):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=571ddddc7e13&tochange=e2124a8f65ed

Comment 7

[chris hofmann]

os breakdown
mozcrt19.dll@0x87c7Total 29

27      0.931034        Windows NT6.1.7600
2       0.0689655       Windows NT6.0.6002 Service Pack 2

Distribution of CPU info
  14 amd64 family 6 model 23 stepping
   6 amd64 family 6 model 30 stepping
   4 amd64 family 6 model 15 stepping
   2 amd64 family 6 model 26 stepping
   1 amd64 family 17 model 3 stepping
   1 amd64 family 15 model 75 stepping
   1 amd64 family 15 model 67 stepping


urls for testing
   4 http://eric22222.files.wordpress.com/2010/11/hl2.jpg

when I tried this I got messages indicated the image could not be shown because of errors

   4 \N
   1 http://www.youtube.com/user/NaturalSelection2HD
   1 http://www.powderbuythepound.com/search.php?mode=search&page=1
   1 https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking2.0%3Abeta8

   1 jar:file:///E:/Internet/Minefield/omni.jar!/chrome/toolkit/content/global/aboutSupport.xhtml
   1 jar:file:///C:/Program%20Files/Minefield/omni.jar!/chrome/browser/content/browser/aboutSessionRestore.xhtml

Comment 8

[chris hofmann]

looks like it might first have appeared on 10/25 in builds from that day.

20101025 1 4.0b8pre 2010102516         1 , 
20101026 5      2 4.0b8pre^\2010102516, 
                        1 4.0b8pre^\2010102612,         1 4.0b8pre^\2010102610, 
                        1 4.0b8pre^\2010102604, 
20101027 10     8 4.0b8pre^\2010102610, 
                        2 4.0b8pre^\2010102612, 
20101028 19     10 4.0b8pre^\2010102610, 
                        4 4.0b8pre^\2010102805,         4 4.0b8pre^\2010102612, 
                        1 4.0b8pre^\2010102706,

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Crash reporting for Win64 landed on 10/22, and the 2010-10-25-16-mozilla-central build was the first Win64 build after it landed, so the regression date here is just "crash reporting turned on on Win64".

Comment 10

[Benjamin Smedberg]

Windows 64-bit crashes do not block FF4, we're not releasing Win64 at all.

Comment 11

[chris hofmann]

ok, sounds good.

Comment 12

[Lozzy]

(In reply to comment #10)
> Windows 64-bit crashes do not block FF4, we're not releasing Win64 at all.

Does this mean this crash won't be looked into at all? It's easily reproducible for me; open a Youtube page with a HD video that is fairly long (over  10 minutes or so). Then after a few minutes of buffering it will crash itself. I believe it's a similar situation for downloading large files.

Also a bit disappointed that there won't be a 64 bit build :(

Comment 13

[timeless]

lozzy: it means that people who are paid to work on mozilla firefox 4 are unlikely to be directed to look into such problems. If you want to chase this problem down, you'll need to find a helpful soul who can provide a 64bit binary with symbols. try irc.mozilla.org if you're interested in helping. it's best of course if you're willing to build yourself.

As we aren't going to be shipping 64bit builds, it means that if you install ff4 for windows, you'll get something which won't have whatever 64bit only problems you may be hitting.

If you want to help us drive to ff4, the best thing would be for you to install a 32bit nightly and use that.

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I was opening a lot of tabs at once, and Minefield 64 crashes on me consistently after a lot of tabs get opened, and they all list this bug as related.

I middle-clicked the "Latest Headlines" live bookmark thing a bunch of times (so I had about 200 tabs open by the time it crashed), and then it crashed.

Crashing thread: http://pastebin.mozilla.org/913038

Comment 15

[Josh Aas]

I think Makoto Kato has been driving Windows 64-bit development, maybe he can help. CC'd.

Comment 16

[Makoto Kato [:m_kato]]

Until bug 618385 is fixed, the symbol of crash address isn't resolved.  After crash reporter shows function name instead of module name + address offset, I will investigate this.

Of course, if someone founds 100% repro step, I can investigate this soon.

Comment 17

[Frank Wein [:mcsmurf]]

BTW: This crash here might be Bug 625753 as I got some crash reports from a Windows x64 user, without symbols all his crash reports (stack signature) were pointing to this bug here, now they point at said bug number. Bug 625753 is also some kind of meta bug though as all the stacktraces are different in the stack above the allocator.

Comment 18

[Scoobidiver (away)]

Comment 17 is right.
As there have been no crashes from the landing of bug 618385, I close this bug.