Closed Bug 827971 Opened 8 years ago Closed 7 years ago
.0 (opensolaris i386) crashes on most websites
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 => mutex_lock_impl(0x0, 0x0, 0x0, 0xfed16e76, 0xfed85840, 0x1), at 0xfed1745b  mutex_lock(0x0, 0xe85e20d0, 0xef7fecf8, 0xfec0a774), at 0xfed176d8  PR_Lock(0x0), at 0xfec0a786  nsCacheService::ProcessPendingRequests(0x88b0660, 0xa05a1d0, 0x83e43754, 0xfb9cac66), at 0xfb9cc6f0  nsCacheService::DoomEntry_Internal(0x88b0660, 0xa05a1d0, 0x1, 0xfb9c46f6), at 0xfb9cad3f  nsAsyncDoomEvent::Run(0xa9ca070, 0x1, 0xef7fee28, 0xfd2b3b01), at 0xfb9c472e  nsThread::ProcessNextEvent(0x88b08b8, 0x1, 0xef7fef3c, 0xfd25b875), at 0xfd2b3eb7  NS_ProcessNextEvent_P(0x88b08b8, 0x1, 0xef7fef6c, 0xfd2b2e80), at 0xfd25b8ac  nsThread::ThreadFunc(0x88b08b8), at 0xfd2b2f0a  _pt_root(0x88b0a58, 0xfed80000, 0xef7fefe8, 0xfed1f3be), at 0xfec11873  _thrp_setup(0xf9e2aa40), at 0xfed1f413  _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
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
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.
@ 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 => nsCacheService::ProcessPendingRequests(0x8891920, 0xada7618, 0xc7305ac8, 0xfb9cac66), at 0xfb9cbe45  nsCacheService::DoomEntry_Internal(0x8891920, 0xada7618, 0x1, 0xfb9c46f6), at 0xfb9cad3f  nsAsyncDoomEvent::Run(0x9c16c40, 0x1, 0xef5fee28, 0xfd2b3b01), at 0xfb9c472e  nsThread::ProcessNextEvent(0x8891b78, 0x1, 0xef5fef3c, 0xfd25b875), at 0xfd2b3eb7  NS_ProcessNextEvent_P(0x8891b78, 0x1, 0xef5fef6c, 0xfd2b2e80), at 0xfd25b8ac  nsThread::ThreadFunc(0x8891b78), at 0xfd2b2f0a  _pt_root(0x8891d18, 0xfed80000, 0xef5fefe8, 0xfed1f3be), at 0xfec11873  _thrp_setup(0xf9e2aa40), at 0xfed1f413  _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.