Closed Bug 557161 Opened 15 years ago Closed 11 years ago

crashes and problems with firefox 3.6.x on winxp

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
3.5 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: chofmann, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: user-doc-needed)

Attachments

(1 file)

win9x pct of 3.6 and 3.5 user crashes
116.62 KB, image/png
Details
we might not be able to fix some of these bugs but we could offer support docs and possible workarounds that identify issues when trying to run firefox 3.6 on win95. add dependency bugs as they are found where the issue seems to be soley or disproportionately seen on win95.
nspr lock and threading code is on the stack in many of the stack's I looked at in the dependency bugs, and I notice this comment from last year in bug 476085 "..In NSPR 4.8 we will drop support of Windows 9x." is it possible that some of these signatures in the dependency list that increased dramatically in firefox 3.6 where the result of these changes in nspr?
Depends on: 538724
Depends on: 511756
I guess one thing we could do until we confirm that nspr or something else is at the root of these firefox3.6.x + win95 problems is to hold off offering the 3.5.x to 3.6.x upgrade to this set of users.
on deeper reflection holding off updates to win9x users might not be that big a win. the stability improvements in other areas might outweigh these r ne crashes and regressions in the 3.6.x #1, #3, #5, #6, and #9 topcrashes. It looks like win95 is a disproportional contributor to both releases at this point. OS crash distribution for firefox 3.6.x and 3.5.x crashes - OSrelease 240204 total firefox 3.6 crashes on 2010 04 03 142058 Windows NT 5.1.2600 59% 37209 Windows NT 6.1.7600 26413 Windows NT 6.0.6002 11986 Windows NT 6.0.6001 4734 Windows NT 6.0.6000 3943 Mac OS X 10.4.11 3937 \N \N 3853 Mac OS X 10.5.8 9 2055 Mac OS X 10.6.2 1 1921 Mac OS X 10.6.3 1 559 Windows NT 5.2.3790 399 Windows NT 6.1.7100 --------------------- 42487 total 3.5.x crashes on 2010 04 03 26337 Windows NT 5.1.2600 %61 3030 Windows NT 6.0.6002 2453 Windows NT 6.0.6001 2270 Windows NT 6.1.7600 2134 Mac OS X 10.5.8 9 1808 Mac OS X 10.4.11 1429 \N \N 1001 Windows NT 6.0.6000 756 Mac OS X 10.6.2 1 288 Mac OS X 10.6.3 1 187 Mac OS X 10.5.7 9 135 Mac OS X 10.5.6 9 99 Mac OS X 10.6.0 1 87 Windows NT 5.2.3790 86 Windows NT 6.1.7100 46 Mac OS X 10.6.1 1 46 Mac OS X 10.4.10 32 Mac OS X 10.5.5 9 27 Mac OS X 10.5.4 9 27 Mac OS X 10.5.2 9 26 Mac OS X 10.4.9 8 25 Mac OS X 10.4.6 8 22 Mac OS X 10.5.0 9 20 Mac OS X 10.4.8 8 20 Mac OS X 10.4.0 8 13 Mac OS X 10.4.7 8
although there might be other migration dynamics at work... In the early days of the 3.6 release win9x crashes were running at a higher pct of all 3.6 crashes. That number has been dropping during February and March as the 3.6.x population has grown. Its possible we are leaking win9x back to 3.5x or other browsers as a result of these top crashers, so the pct. of overall crashes would drop if that is happening. The user comments for all these 3.6 top crashers express that kind of frustration. We would need closer correlation to ADU, uninstall, and maybe other data to figure out if we are leaking win9x users at a higher than expected rate.
ken, any thoughts on comment 4?
Firefox 3.6 (and even 3.5) will not run at all on Win95. Why do you think NT 5.1 is Win95?
oops, getting my window version numbers mixed up. NT 5.1 is winxp.
Summary: crashes and problems with firefox 3.6.x on win95 → crashes and problems with firefox 3.6.x on winxp
and I guess we need to correlate to OS marketshare. http://www.w3schools.com/browsers/browsers_os.asp says winxp was at 58% market share in feb. http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10 says 64%. that would make our crash data around 3% or 4% higher than expected, or near what should be expected for that OS. that chart in comment 4 caught only build 5.1.2600; a more generalized query picks up a few more pct.
these might be the areas to look at to see if windows code path changes through nspr might have created some regressions in fx3.6 and winxp https://bugzilla.mozilla.org/show_bug.cgi?id=511757 [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] 2 nspr4.dll PR_Lock nsprpub/pr/src/threads/combined/prulock.c:233 Crash Report [@ UserCallWinProcCheckWow ] 17 nspr4.dll nspr4.dll@0xbdcf in stacks like http://crash-stats.mozilla.com/report/index/29e3e8e0-27d1-45ca-98bc-4c7702100405 and http://crash-stats.mozilla.com/report/index/5a04270f-0a11-4dbf-ab53-b29892100405 The _woutput_l crash might be fixed with updates to trend micro and the nsHttpTransaction::DeleteSelfOnConsumerThread() doesn't show any nspr calls on the stack.
So here is a better idea about which stacks are heavily tilted to winxp out of the to 25 firefox 3.6.x crashes RtlpWaitForCriticalSection firefox 3.6 nt 5.1 bug 511757 20100404-crashdata.csv 3202 3202 100% nsHttpTransaction::DeleteSelfOnConsumerThread firefox 3.6 nt 5.1 bug 538724 20100404-crashdata.csv 3058 3058 100% _woutput_l firefox 3.6 nt 5.1 bug 511756 20100404-crashdata.csv 1956 1770 0.904908 GraphWalker::DoWalk.nsDeque 3.6 5.1 bug 500105 20100404-crashdata.csv 980 694 0.708163 js_TraceObject 3.6 5.1 bug 503772 20100404-crashdata.csv 1011 807 0.79822 _PR_MD_SEND 3.6 5.1 bug 467167 20100404-crashdata.csv 1072 764 0.712687 it turns out that UserCallWinProcCheckWow is not heavily tilted towards xp if I look at a larger sample, although since this signature seems to be multiple problems one or more of those might be tilted at winxp. UserCallWinProcCheckWow firefox 3.6 nt 5.1 bug 531551 bug 501429 bug 556483 20100404-crashdata.csv 10508 5820 0.553864
Depends on: 500105
No longer depends on: 531551
OS: Mac OS X → Windows XP
about 53% (601,029) of users hitting the 3.6.3 whats new page are winxp users and 60.9% (777,026) hitting the 3.5.9 whats new page are winxp. I'm not sure if we have adu metrics broken down by OS. that would help us to confirm any slow uptake and/or backtracking on winxp users to 3.5.x.
I found some adu data but its only across all firefox releases. It says All Windows_NT 104,836,576 NT 5.1 69,250,397 or 66% of all firefox users are on winXP, so it does look like we are seeing a delay in migration to 3.6.x
Blocks: 556178
No longer blocks: 556178
Depends on: 556178
a few more top 300 crashes that are heavily tilted toward winxp RtlpCoalesceFreeBlocks 3.6 5.1 20100404 683 594 0.869693 arena_dalloc_small 3.6 5.1 20100404 1413 1094 0.774239 RtlEnterCriticalSection 3.6 5.1 20100404 625 515 0.824 nsAppShell::ProcessNextNativeEvent.int. 3.6 5.120100404 526 526 100% BaseThreadStart 3.6 5.120100404-crashdata.csv 546 546 100% RtlReAllocateHeap 3.6 5.120100404-crashdata.csv 316 316 100% avgssff.dll@0x9943 3.6 5.120100404 288 258 0.895833 InterlockedCompareExchange 3.6 5.120100404 307 264 0.859935 GoogleDesktopNetwork3.dll@0x3dfb 3.6 5.120100404 334 334 100% memcmp 3.6 5.120100404-crashdata.csv 365 354 0.969863 js_FoldConstants 3.6 5.120100404-crashdata.csv 272 225 0.827206 js_LookupPropertyWithFlags 3.6 5.120100404 189 161 0.851852 strchr 3.6 5.120100404-crashdata.csv 521 441 0.846449 RtlpAdjustHeapLookasideDepth 3.6 5.120100404 176 176 100% RtlInitializeCriticalSection 3.6 5.120100404 155 154 0.993548 shlwapi.dll@0x2c428 3.6 5.120100404-crashdata.csv 132 132 100% arena_bin_nonfull_run_get 3.6 5.120100404-crashdata.csv 140 126 0.9
still want?
Flags: needinfo?(kairo)
3.6 has been out of support for a long time, the stability porgram can't do anything for those people any more.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(kairo)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: