Closed Bug 348586 Opened 18 years ago Closed 18 years ago

Feed Preview crashes Firefox (random address)

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Product:
Firefox Graveyard
Component:
RSS Discovery and Preview
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Firefox 2 beta2

People

(Reporter: dao, Assigned: sayrer)

References

(
URL
)

Details

(Keywords: crash, regression, verified1.8.1)

Attachments

(3 files)

Stack from debug build
2.02 KB, text/plain
Details
initial assert in array_sort on page load
8.17 KB, text/plain
Details
avoid delete[]
1.45 KB, patch
asaf
: review+
dbaron
: approval1.8.1+
Details | Diff | Splinter Review 
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.
investigating
Assignee: nobody → sayrer
(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
I can't reproduce this with OS X.
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).
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) ?

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.
(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.
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.
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
Attached file 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.
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>
Attached patch avoid delete[] — — Splinter Review 
this seems to avoid the crash. bug 322135 seems implicated.
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta2
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+
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?
Igor just filed bug 348810, "Crash when sorting array with only holes". That fits this case.
Depends on: 348810
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...)
wallpaper is backed out on trunk
no crashes anymore using the build with the wallpaper patch removed.
resolved, nothing needed on the branch
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
verified with Fx 2.0b2 builds from 22060821
Keywords: fixed1.8.1 → verified1.8.1
Flags: blocking1.9?
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: