If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

firefox 18.0 (opensolaris i386) crashes on most websites

RESOLVED WORKSFORME

Status

()

Core
Networking: Cache
--
blocker
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: beanladen, Assigned: Ginn Chen)

Tracking

({crash, regression})

18 Branch
x86
OpenSolaris
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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
(Reporter)

Comment 3

5 years ago
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.

Comment 4

5 years ago
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
(Reporter)

Comment 7

5 years ago
@ 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
(Reporter)

Comment 8

5 years ago
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
(Assignee)

Comment 10

5 years ago
I've seen this problem before, and I fixed it.
But I can't remember how. :(
Assignee: nobody → ginn.chen
(Assignee)

Comment 11

5 years ago
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.

Comment 12

5 years ago
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.
(Reporter)

Comment 13

5 years ago
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
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.