Feed Preview crashes Firefox (random address)

RESOLVED FIXED in Firefox 2 beta2

Status

()

--
critical
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: dao, Assigned: sayrer)

Tracking

({crash, regression, verified1.8.1})

Trunk
Firefox 2 beta2
x86
Windows XP
crash, regression, verified1.8.1
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060813 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060813 Minefield/3.0a1

I got several crashes with the current trunk nightly when opening or closing feed previews:

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22046013K
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22046043E
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22046071G
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22046084M
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22046096Y

feed preview checkins since previous nightly:

bug 340554, bug 344983, bug 346317, bug 347824, bug 348010

Reproducible: Sometimes
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060813 Minefield/3.0a1 ID:2006081313 [cairo]

confirmed.

I tried feeds for a while and am getting the same random address crashes.
reproducable... not really, seemingly random cause, just open a feed and see what will happen.

TB22054695W
TB22054001X
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression
Summary: Feed Preview crashes Firefox → Feed Preview crashes Firefox (random address)
Keywords: crash
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060814 Minefield/3.0a1

Oldest build where I could reproduce a crash by reloading a feed view is 11-Aug-2006:15 but the crash could very well be older. The crashes are about ntdll.dll.
Well, for me, I see a regression range between 2006-08-12 and 2006-08-13.
It only happens on trunk.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-12+04&maxdate=2006-08-13+06&cvsroot=%2Fcvsroot
I get it usually after the 3rd reload on http://www.mozillazine.org/contents.rdf
I suspect this might be a regression from bug 347824.
(Assignee)

Comment 4

12 years ago
investigating
Assignee: nobody → sayrer
(Assignee)

Comment 5

12 years ago
(In reply to comment #3)
> Well, for me, I see a regression range between 2006-08-12 and 2006-08-13.
> It only happens on trunk.

I worry about bug 340554, checked in late on 08-11. 

bug 340554 was checked in on 2145pdt on 20060811
I have 
firefox-3.0a1.en-US.win32_20060811_1512pdt_cairo.zip
and
firefox-3.0a1.en-US.win32_20060812_0043pdt_cairo.zip
for anyone who wants to try.(just send me an email)

I'm having a hard time to reproduce this bug, my crashes seem to come out of the blue
(Assignee)

Comment 7

12 years ago
I can't reproduce this with OS X.
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk
I could several times reproduce it in this build: 1.9a1_2006081209 but not in 1.9a1_2006081122 or older, whatever I try. So possibly the crash in 1.9a1_2006081114 was unrelated and had rather something to do with the session restore or so (it crashed on startup).
(Assignee)

Comment 9

12 years ago
A likely cause for this crash, and other trunk crashes, is the use of the wrong free() implementation in innerHTML (trunk only) and feeds. 

See bug 348643.
maximum weirdness....
Using Martijns method, reload a feed until you crash (multiple tests per build)

I get NO crash in the Win32 20060812 0351pdt build
I get NO crash in the Win32 20060812 0536pdt Nightly build
I do crash in the Win32 20060812 0913pdt build

According to bonsai, there were NO checkins during that period or shortly before or after.

Was something unrecorded by bonsai checked in during that period (some machine config maybe) ?
(Assignee)

Comment 12

12 years ago
I just landed a fix for bug 348643. (2006-08-14 15:05 PDT)
The latest build is still crashing (1.9a1_2006081421).
I don't get this crash in a debug build.
(Assignee)

Comment 15

12 years ago
(In reply to comment #13)
> The latest build is still crashing (1.9a1_2006081421).
> 

I checked in the fix for bug 348643 at 2006-08-14 15:05 PDT, and I don't get the crash on Windows with the latest nightly. Can anyone verify?
TB22114210H  TB22114180X  TB22114275Q
Everything after the second reload of 10 tabs with feeds. 
Hm, the latest hourly (1.9a1_2006081503) has a more familiar stack: TB22114388W
I'm also still crashing with the 2006-08-15 daily trunk build when viewing a feed.
(Assignee)

Comment 19

12 years ago
OK, I can dupe this (In reply to comment #18)
> I'm also still crashing with the 2006-08-15 daily trunk build when viewing a
> feed.
> 

OK, I can dupe this on my pentium 4 laptop, but not on my Athlon 64 box.
(Assignee)

Comment 20

12 years ago
I can get it with a non-debug build. I installed the Windows symbols, and the crash is always in one of the heap allocator functions.

>	ntdll.dll!_RtlAllocateHeap@12()  + 0xc0c	
 	msvcr80.dll!78134ce9() 	
 	msvcr80.dll!78160e0d() 	
 	firefox.exe!004e7c6b() 	
 	xpcom_core.dll!604f4057() 	
 	firefox.exe!004e71c8() 	
 	firefox.exe!0042627b() 	
 	xpcom_core.dll!604f82be() 	
 	ntdll.dll!_RtlAllocateHeap@12()  + 0x117	
 	firefox.exe!004ede95() 	
 	firefox.exe!004eed05() 	
 	xpcom_core.dll!604c1745() 	
 	firefox.exe!004ef904() 	
 	firefox.exe!004e240c() 	
 	firefox.exe!004e2526() 	
 	firefox.exe!004e2185() 	
 	firefox.exe!004e76ca() 	
 	xpcom_core.dll!604f4acc() 	
 	firefox.exe!0041b354() 	
 	firefox.exe!0041cd60() 	
 	firefox.exe!0040aa61() 	
 	firefox.exe!0041ae7d() 	
 	firefox.exe!0041f9ea() 	
 	firefox.exe!0041b9c7() 	
 	js3250.dll!6012515e() 	
 	firefox.exe!00421bcf() 	
 	firefox.exe!0041fc96() 	
 	js3250.dll!601402d2() 	
 	js3250.dll!601460b4() 	
 	firefox.exe!0041d15a() 	
 	xpcom_core.dll!604dbcd5() 	
 	xpcom_core.dll!604c1db6() 	
 	firefox.exe!0041bf16() 	
 	js3250.dll!6012ff8c() 	
 	xpcom_core.dll!604dba68() 	
 	xpcom_core.dll!604c1d75() 	
 	firefox.exe!0041d570() 	
 	js3250.dll!60140310() 	
 	firefox.exe!004281e8() 	
 	xpcom_core.dll!604c1db6() 	
 	firefox.exe!0041b3fe() 	
 	xpcom_core.dll!604c1d75() 	
 	firefox.exe!004db73e() 	
 	firefox.exe!004dcfbf() 	
 	firefox.exe!004dd040() 	
 	firefox.exe!004dd0de() 	
 	firefox.exe!004df111() 	
 	firefox.exe!0042627b() 	
 	xpcom_core.dll!604f3fe2() 	
 	firefox.exe!0041b9c7() 	
 	xpcom_core.dll!604efef6() 	
 	nspr4.dll!60329326() 	
 	xpcom_core.dll!604f4057() 	
 	xpcom_core.dll!604f4acc() 	
 	firefox.exe!0041b354() 	
 	firefox.exe!0041cd60() 	
 	firefox.exe!0040aa61() 	
 	firefox.exe!0041ae7d() 	
 	firefox.exe!0041f9ea() 	
 	firefox.exe!0041b9c7() 	
 	js3250.dll!6012515e() 	
 	firefox.exe!00421bcf() 	
 	firefox.exe!0041fc96() 	
 	js3250.dll!601402d2() 	
 	js3250.dll!601460b4() 	
 	xpcom_core.dll!604dbcd5() 	
 	xpcom_core.dll!604c1db6() 	
 	firefox.exe!0041bf16() 	
 	firefox.exe!0041d4f7() 	
 	js3250.dll!6012ff8c() 	
 	xpcom_core.dll!604dba68() 	
 	xpcom_core.dll!604c1d75() 	
 	firefox.exe!0041d570() 	
 	js3250.dll!60140310() 	
 	firefox.exe!004281e8() 	
 	xpcom_core.dll!604ef059() 	
 	firefox.exe!00810856() 	
 	xpcom_core.dll!604c4b76() 	
 	firefox.exe!00780a5a() 	
 	xpcom_core.dll!604c131d() 	
 	firefox.exe!0042627b() 	
 	xpcom_core.dll!604f3fe2() 	
 	firefox.exe!004846bf() 	
 	firefox.exe!004846ed() 	
 	xpcom_core.dll!604f4057() 	
 	firefox.exe!0077e704() 	
 	firefox.exe!004800af() 	
 	firefox.exe!0045071e() 	
 	firefox.exe!0045086b() 	
 	xpcom_core.dll!604e0da6() 	
 	xpcom_core.dll!604ee476() 	
 	xpcom_core.dll!604c57e3() 	
 	firefox.exe!0053713d() 	
 	firefox.exe!008afebf() 	
 	firefox.exe!00403fae() 	
 	msvcr80.dll!78146fca() 	
 	msvcr80.dll!7814f4ba() 	
 	msvcr80.dll!781323ee() 	
 	msvcr80.dll!7814f56e() 	
 	msvcr80.dll!7814f566() 	
 	nspr4.dll!6032960f() 	
 	nspr4.dll!60325932() 	
 	nspr4.dll!6031bb6f() 	
 	msvcr80.dll!78132d95() 	
 	msvcr80.dll!78136e3f() 	
 	firefox.exe!00401012() 	
 	firefox.exe!00401029() 	
 	firefox.exe!009290d7() 	
 	kernel32.dll!_BaseProcessStart@4()  + 0x23	
(Assignee)

Comment 21

12 years ago
Created attachment 233864 [details]
Stack from debug build

OK, I got this to happen in a static optimized debug build. Looks like we're actually crashing on a timeout, but we assert with heap pointer issues before that, too. In one, we go right past the warning in bug 347480 in the initial assertions, which happens on the first page load.
(Assignee)

Comment 22

12 years ago
Created attachment 233869 [details]
initial assert in array_sort on page load

The initial asserts happen in JS array_sort, which makes bug 344983 a likely candidate:

<http://lxr.mozilla.org/seamonkey/source/browser/components/feeds/src/FeedConverter.js#431>
(Assignee)

Comment 23

12 years ago
Created attachment 233894 [details] [diff] [review]
avoid delete[]

this seems to avoid the crash. bug 322135 seems implicated.
(Assignee)

Updated

12 years ago
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta2
(Assignee)

Comment 24

12 years ago
Igor, Brendan asked me to CC you on this.

We keep a small cache of URI objects for feeds between requests. On Windows, it seems that calling delete[x] (leaving a hole) will cause heap problems in array_sort, which leads to a crash later on when the JSArray dtor is called. The stacks above show an array of one member, deleting the member, calling sort(), then pop(), and then deleting the array itself. (We do this because the array can grow if the same feed is loaded in multiple frames and such)
Comment on attachment 233894 [details] [diff] [review]
avoid delete[]

r=mano as a wallpaper for b2 in case the underlying issue isn't fixed on time.
Attachment #233894 - Flags: review+
(Assignee)

Comment 26

12 years ago
Comment on attachment 233894 [details] [diff] [review]
avoid delete[]

Drivers,

I need this to land my other feed patches without causing crashes and big leaks on Windows.

Martijn, 

I checked the wallpaper in on 2006-08-15 18:48.
Attachment #233894 - Flags: approval1.8.1?
(Assignee)

Comment 27

12 years ago
Igor just filed bug 348810, "Crash when sorting array with only holes". That fits this case.
(Assignee)

Updated

12 years ago
Depends on: 348810

Comment 28

12 years ago
This is my fault: see bug 348810.
Comment on attachment 233894 [details] [diff] [review]
avoid delete[]

a=dbaron on behalf of drivers.  Please land on MOZILLA_1_8_BRANCH and add the fixed1.8.1 keyword once you have done so.

But if igor's patch makes it in on time, you don't need to land it.

And it would probably be best if you back it out once igor's patch does land to make sure it fixes the problem.
Attachment #233894 - Flags: approval1.8.1? → approval1.8.1+
Flags: blocking-firefox2? → blocking-firefox2+
Robert, please decide what (based on dbaron's comments above) the right course of action is here, and mark fixed1.8.1 when you do. Thanks!
It looks like the JS engine fix has landed -- so could you check that it's really fixed and then mark fixed1.8.1 if it is?  (And probably back the workaround out of the trunk...)
(Assignee)

Comment 32

12 years ago
wallpaper is backed out on trunk
no crashes anymore using the build with the wallpaper patch removed.
(Assignee)

Comment 34

12 years ago
resolved, nothing needed on the branch
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
verified with Fx 2.0b2 builds from 22060821
Keywords: fixed1.8.1 → verified1.8.1

Updated

12 years ago
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.