Closed Bug 827971 Opened 8 years ago Closed 7 years ago

firefox 18.0 (opensolaris i386) crashes on most websites

Categories

(Core :: Networking: Cache, defect)

18 Branch
x86
OpenSolaris
defect
Not set
blocker

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: beanladen, Assigned: ginnchen+exoracle)

References

Details

(Keywords: crash, regression)

User Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121129183351

Steps to reproduce:

Install new firefox, start it. Or better, start it with a specific URL (not on the Mozilla websites), then
go to mozilla (check for addons or whatever). Almost all web pages kill the browser except the most
simple ones.
OS Version Openindiana 151a7, Firefox 17.0.1 works without flaw.



Actual results:

Firefox goes to Mozilla 'Congrats' page and crashes immediately.
(dbx) cont
t@22 (l@22) signal SEGV (no mapping at the fault address) in mutex_lock_impl at 0xfed1745b
0xfed1745b: mutex_lock_impl+0x0023:	movzbl   0x00000004(%eax),%edi
(dbx) where
current thread: t@22
=>[1] mutex_lock_impl(0x0, 0x0, 0x0, 0xfed16e76, 0xfed85840, 0x1), at 0xfed1745b 
  [2] mutex_lock(0x0, 0xe85e20d0, 0xef7fecf8, 0xfec0a774), at 0xfed176d8 
  [3] PR_Lock(0x0), at 0xfec0a786 
  [4] nsCacheService::ProcessPendingRequests(0x88b0660, 0xa05a1d0, 0x83e43754, 0xfb9cac66), at 0xfb9cc6f0 
  [5] nsCacheService::DoomEntry_Internal(0x88b0660, 0xa05a1d0, 0x1, 0xfb9c46f6), at 0xfb9cad3f 
  [6] nsAsyncDoomEvent::Run(0xa9ca070, 0x1, 0xef7fee28, 0xfd2b3b01), at 0xfb9c472e 
  [7] nsThread::ProcessNextEvent(0x88b08b8, 0x1, 0xef7fef3c, 0xfd25b875), at 0xfd2b3eb7 
  [8] NS_ProcessNextEvent_P(0x88b08b8, 0x1, 0xef7fef6c, 0xfd2b2e80), at 0xfd25b8ac 
  [9] nsThread::ThreadFunc(0x88b08b8), at 0xfd2b2f0a 
  [10] _pt_root(0x88b0a58, 0xfed80000, 0xef7fefe8, 0xfed1f3be), at 0xfec11873 
  [11] _thrp_setup(0xf9e2aa40), at 0xfed1f413 
  [12] _lwp_start(0xfed80000, 0xef7fec88, 0x0, 0x88b0710, 0x0, 0x0), at 0xfed1f6c0 



Expected results:

Show pages as usual and don't crash.
Adding blocker for OS as FF 18 is unusable on OSol/OI.
Severity: normal → blocker
Keywords: regression
OS: Solaris → OpenSolaris
Priority: -- → P5
note: solaris is no Tier-1 platform and I don't know if there are still Oracle developers working on it.
Component: Untriaged → Networking: Cache
Keywords: crash
Priority: P5 → --
Product: Firefox → Core
See <http://hub.opensolaris.org/bin/view/Community+Group+desktop/development> from 
Ginn Chen, those packages regularily appear in the 'contrib' folders shortly after release.
I'm seeing the same exact problem here.  Also running OpenIndiana 151a7, and Firefox 17.0.1 was flawless.  I was able to close the "congratulations for upgrading" tab fast enough to not crash there, but I get crashes elsewhere.  (Though Bugzilla apparently doesn't kill it.)
Can you set browser.cache.disk.enable to false ?
That could stop the crashes.
Duplicate of this bug: 817482
@ comment #5:
Does not help (although about:config shows that it's correctly disabled), e.g. 
going to de.nachrichten.yahoo.com gives this stacktrace:

Attached to process 3230 with 31 LWPs
t@1 (l@1) stopped in __pollsys at 0xfed241f5
0xfed241f5: __pollsys+0x0015:	jb       __cerror	[ 0xfec7bd50, .-0xa84a5 ]
(dbx) cont
t@22 (l@22) signal SEGV (no mapping at the fault address) in nsCacheService::ProcessPendingRequests at 0xfb9cbe45
0xfb9cbe45: ProcessPendingRequests+0x0195:	movl     (%eax),%ecx
(dbx) where 
current thread: t@22
=>[1] nsCacheService::ProcessPendingRequests(0x8891920, 0xada7618, 0xc7305ac8, 0xfb9cac66), at 0xfb9cbe45 
  [2] nsCacheService::DoomEntry_Internal(0x8891920, 0xada7618, 0x1, 0xfb9c46f6), at 0xfb9cad3f 
  [3] nsAsyncDoomEvent::Run(0x9c16c40, 0x1, 0xef5fee28, 0xfd2b3b01), at 0xfb9c472e 
  [4] nsThread::ProcessNextEvent(0x8891b78, 0x1, 0xef5fef3c, 0xfd25b875), at 0xfd2b3eb7 
  [5] NS_ProcessNextEvent_P(0x8891b78, 0x1, 0xef5fef6c, 0xfd2b2e80), at 0xfd25b8ac 
  [6] nsThread::ThreadFunc(0x8891b78), at 0xfd2b2f0a 
  [7] _pt_root(0x8891d18, 0xfed80000, 0xef5fefe8, 0xfed1f3be), at 0xfec11873 
  [8] _thrp_setup(0xf9e2aa40), at 0xfed1f413 
  [9] _lwp_start(0xfe1b49f4, 0xef5fed08, 0xfcc82dc1, 0xa0b47300, 0xfe226ec0, 0xfddee47e), at 0xfed1f6c0
Found a workaround: browser.cache.disk.enable, browser.cache.memory.enable (and probably also
browser.cache.disk_cache_ssl) have to be set to false to prevent the cache segfault. So there's
a more general problem in nsCacheService.
marking new based on comment#4
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've seen this problem before, and I fixed it.
But I can't remember how. :(
Assignee: nobody → ginn.chen
nsCOMPtr<nsCacheEntryDescriptor> mDescriptor;
nsCacheEntryDescriptor *descriptor;
mDescriptor = descriptor;

For some reason, with Solaris Studio, mDescriptor.get() doesn't equal to the raw pointer descriptor.

I made a workaround with FF19, but forgot to backport it to FF18.
I tried the Firefox 18 opensolaris-i386 build under the contrib/solaris-respin/solaris_tarball directory on a clean install of OpenIndiana 151a7, and it seems to work fine with the caches enabled.
18 respin has this problem fixed, but chokes and finally freezes on all kinds of videos, still
unusable.
WFM per comment 13
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.