nsDBAccessor::GetID is attempting to do this (line 257) on an unaligned pointer: t@1 (l@1) signal BUS (invalid address alignment) in nsDBAccessor::GetID at line 257 in file "nsDBAccessor.cpp" 257 *aID = *(NS_REINTERPRET_CAST(PRInt32*, db_data.data)) ; (dbx t@1 l@1) p db_data.data db_data.data = 0x68e7dd While this will work on ia86 platforms, this causes a crash on architectures that require that memory accesses have proper alignment (such as solaris/sparc). Tested on solaris/native with a 5/10 evening cvs pull. Running "mozilla-bin" with no arguments is sufficient to reproduce. Stack trace: =>[1] nsDBAccessor::GetID(this = 0x63e1b0, key = 0xffbec174 "http://www.mozilla.org/quality/checkin-guidelines.html", length = 55U, aID = 0xffbebfb4), line 257 in "nsDBAccessor.cpp" [2] nsNetDiskCache::GetCachedNetData(this = 0x64d1c8, key = 0xffbec174 "http://www.mozilla.org/quality/checkin-guidelines.html", length = 55U, _retval = 0xffbec03c), line 401 in "nsNetDiskCache.cpp" [3] nsReplacementPolicy::GetCachedNetData(this = 0x63d9e8, cacheKey = 0xffbec174 "http://www.mozilla.org/quality/checkin-guidelines.html", cacheKeyLength = 55U, aCache = 0x64d1c8, aResult = 0xffbec1c0), line 538 in "nsReplacementPolicy.cpp" [4] nsCacheManager::GetCachedNetData(this = 0x62c998, aUriSpec = 0x6449f8 "http://www.mozilla.org/quality/checkin-guidelines.html", aSecondaryKey = (nil), aSecondaryKeyLength = 0, aFlags = 0, aResult = 0x489af8), line 263 in "nsCacheManager.cpp" [5] nsHTTPChannel::CheckCache(this = 0x489a80), line 874 in "nsHTTPChannel.cpp" [6] nsHTTPChannel::Open(this = 0x489a80, bIgnoreCache = 0), line 1254 in "nsHTTPChannel.cpp" [7] nsHTTPChannel::AsyncRead(this = 0x489a80, listener = 0x6cdba8, aContext = (nil)), line 314 in "nsHTTPChannel.cpp" [8] nsDocumentOpenInfo::Open(this = 0x6cdba8, aChannel = 0x489a80, aCommand = 0, aWindowTarget = (nil), aWindowContext = 0x66fef8), line 164 in "nsURILoader.cpp" [9] nsURILoader::OpenURIVia(this = 0x118118, aChannel = 0x489a80, aCommand = 0, aWindowTarget = (nil), aOriginalWindowContext = 0x66fef8, aLocalIP = 0), line 545 in "nsURILoader.cpp" [10] nsURILoader::OpenURI(this = 0x118118, aChannel = 0x489a80, aCommand = 0, aWindowTarget = (nil), aWindowContext = 0x66fef8), line 434 in "nsURILoader.cpp" [11] nsDocShell::DoURILoad(this = 0x66fef8, aURI = 0x6c72e8, aReferrerURI = (nil), aLoadCmd = 0, aWindowTarget = (nil), aPostData = (nil)), line 2595 in "nsDocShell.cpp" [12] nsDocShell::InternalLoad(this = 0x66fef8, aURI = 0x6c72e8, aReferrer = (nil), aWindowTarget = (nil), aPostData = (nil), aLoadType = loadNormal), line 2294 in "nsDocShell.cpp" [13] nsDocShell::LoadURI(this = 0x66fef8, aURI = 0x6c72e8, aLoadInfo = (nil)), line 213 in "nsDocShell.cpp" [14] nsDocShell::LoadURI(this = 0x66fef8, aURI = 0x2f22f0), line 1054 in "nsDocShell.cpp" [15] nsBrowserInstance::LoadUrl(this = 0x673910, urlToLoad = 0x2f22f0), line 481 in "nsBrowserInstance.cpp" [16] 0xff23351c(0x673910, 0x50, 0x1, 0xffbed0e8, 0x17d668, 0x1), at 0xff23351b [17] nsXPCWrappedNativeClass::CallWrappedMethod(this = 0x673970, cx = 0x17d668, wrapper = 0x673d20, desc = 0x673a34, callMode = CALL_METHOD, argc = 1U, argv = 0x2c1cb4, vp = 0xffbed330), line 913 in "xpcwrappednativeclass.cpp" [18] WrappedNative_CallMethod(cx = 0x17d668, obj = 0x578ee0, argc = 1U, argv = 0x2c1cb4, vp = 0xffbed330), line 198 in "xpcwrappednativejsops.cpp" [19] js_Invoke(cx = 0x17d668, argc = 1U, flags = 0), line 686 in "jsinterp.c" [20] js_Interpret(cx = 0x17d668, result = 0xffbed7ac), line 2483 in "jsinterp.c" [21] js_Invoke(cx = 0x17d668, argc = 1U, flags = 2U), line 702 in "jsinterp.c" [22] js_InternalInvoke(cx = 0x17d668, obj = 0x295be0, fval = 2717912, flags = 0, argc = 1U, argv = 0xffbedb84, rval = 0xffbed9f8), line 775 in "jsinterp.c" [23] JS_CallFunctionValue(cx = 0x17d668, obj = 0x295be0, fval = 2717912, argc = 1U, argv = 0xffbedb84, rval = 0xffbed9f8), line 2794 in "jsapi.c" [24] nsJSContext::CallEventHandler(this = 0x37b460, aTarget = 0x295be0, aHandler = 0x2978d8, argc = 1U, argv = 0xffbedb84, aBoolResult = 0xffbedad0, aReverseReturnResult = 0), line 786 in "nsJSEnvironment.cpp" [25] nsJSEventListener::HandleEvent(this = 0x41f238, aEvent = 0x671424), line 149 in "nsJSEventListener.cpp" [26] nsEventListenerManager::HandleEventSubType(this = 0x434200, aListenerStruct = 0x42cdd0, aDOMEvent = 0x671424, aSubType = 1U, aPhaseFlags = 7U), line 703 in "nsEventListenerManager.cpp" [27] nsEventListenerManager::HandleEvent(this = 0x434200, aPresContext = 0x15dd48, aEvent = 0xffbee9dc, aDOMEvent = 0xffbee1bc, aFlags = 7U, aEventStatus = 0xffbeea1c), line 1269 in "nsEventListenerManager.cpp" [28] GlobalWindowImpl::HandleDOMEvent(this = 0x253350, aPresContext = 0x15dd48, aEvent = 0xffbee9dc, aDOMEvent = 0xffbee1bc, aFlags = 1U, aEventStatus = 0xffbeea1c), line 386 in "nsGlobalWindow.cpp" [29] nsWebShell::OnEndDocumentLoad(this = 0x37a2f8, loader = 0x376278, channel = 0x166b68, aStatus = 0), line 1162 in "nsWebShell.cpp" [30] nsDocLoaderImpl::FireOnEndDocumentLoad(this = 0x376278, aLoadInitiator = 0x376278, aDocChannel = 0x166b68, aStatus = 0), line 711 in "nsDocLoader.cpp" [31] nsDocLoaderImpl::DocLoaderIsEmpty(this = 0x376278, aStatus = 0), line 540 in "nsDocLoader.cpp" [32] nsDocLoaderImpl::OnStopRequest(this = 0x376278, aChannel = 0x6720a8, aCtxt = (nil), aStatus = 0, aMsg = (nil)), line 484 in "nsDocLoader.cpp" [33] nsLoadGroup::RemoveChannel(this = 0x184960, channel = 0x6720a8, ctxt = (nil), status = 0, errorMsg = (nil)), line 544 in "nsLoadGroup.cpp" [34] nsFileChannel::OnStopRequest(this = 0x6720a8, transportChannel = 0x672120, context = (nil), aStatus = 0, aMsg = (nil)), line 629 in "nsFileChannel.cpp" [35] nsOnStopRequestEvent::HandleEvent(this = 0x672528), line 306 in "nsAsyncStreamListener.cpp" [36] nsStreamListenerEvent::HandlePLEvent(aEvent = 0x6796e8), line 97 in "nsAsyncStreamListener.cpp" [37] PL_HandleEvent(self = 0x6796e8), line 575 in "plevent.c" [38] PL_ProcessPendingEvents(self = 0xef438), line 520 in "plevent.c" [39] nsEventQueueImpl::ProcessPendingEvents(this = 0xe5570), line 316 in "nsEventQueue.cpp" [40] event_processor_callback(data = 0xe5570, source = 6, condition = GDK_INPUT_READ), line 143 in "nsAppShell.cpp" [41] our_gdk_io_invoke(source = 0x245ca0, condition = G_IO_IN, data = 0xd5418), line 55 in "nsAppShell.cpp" [42] g_main_dispatch(0xffbef188, 0xfd5f1890, 0x0, 0xfd5f17d0, 0xfd5ef680, 0xfd5ef680), at 0xfd5c291c [43] g_main_iterate(0x1, 0xffffffff, 0xffffffff, 0xfd5f1898, 0xfd5f1800, 0xfd5f188c), at 0xfd5c308c [44] g_main_run(0x2a1d40, 0xfd5f1890, 0xfd5ef680, 0xfd5f1920, 0xfd5f1890, 0xfd5ef680), at 0xfd5c3264 [45] gtk_main(0xfd8f1440, 0xfd854da4, 0xfd83de1c, 0x2a1d40, 0x0, 0x0), at 0xfd72d1d4 [46] nsAppShell::Run(this = 0x1197f0), line 313 in "nsAppShell.cpp" [47] nsAppShellService::Run(this = 0xe5470), line 365 in "nsAppShellService.cpp" [48] main1(argc = 1, argv = 0xffbef5dc, splashScreen = (nil)), line 765 in "nsAppRunner.cpp" [49] main(argc = 1, argv = 0xffbef5dc), line 998 in "nsAppRunner.cpp"

[richb - 5/11/00] Jim, I've cc:ed you on this. I understand from Margaret Chan that you have a fix for this, although she understands it to be a fix specific to HP-UX. She mentioned it was a big/little-endian problem. Could you provide more details please, and indicate what changes you had to make (and why this fix couldn't be applied to other platforms)? Thanks.

[richb - 5/11/00] I forgot to mention the workaround to this bug. Add the following two lines to the prefs.js file for your profile: user_pref("browser.cache.disk_cache_size", 0); user_pref("browser.cache.memory_cache_size", 0); and restart Mozilla.

My workaround on HP was to add +u1 as a compiler option which allows HP to access words on non-word aligned boundaries. We had a test that we tried on Solaris (using gcc & WS5.0) and didn't see the same problem so that is why I assumed it was HP only. http://bugzilla.mozilla.org/show_bug.cgi?id=37482 Copying DavidM since he and I talked about our earlier problem

I'm not familiar with the caching code, but at first glance it appears as though it's using the first four bytes of the passed string as part of the lookup key. Since most of these will be the same ("http"), this seems problematic. Am I missing something?

The workaround suggested by richb doesn't work, as nsDBAccessor::Init() still is exectuted and attempts an unaligned access of a 16-bit value: t@1 (l@1) signal BUS (invalid address alignment) in nsDBAccessor::Init at line 117 in file "nsDBAccessor.cpp" 117 if(*old_ID < ini_sessionID) { (dbx t@1 l@1) p old_ID old_ID = 0x6da801 (dbx t@1 l@1) whatis old_ID PRInt16 *old_ID; =>[1] nsDBAccessor::Init(this = 0x641cd8, dbfile = 0x631e58), line 117 in "nsDBAccessor.cpp" [2] nsNetDiskCache::InitDB(this = 0x6a1750), line 318 in "nsNetDiskCache.cpp" [3] nsNetDiskCache::InitCacheFolder(this = 0x6a1750), line 232 in "nsNetDiskCache.cpp" [4] nsNetDiskCache::Init(this = 0x6a1750), line 296 in "nsNetDiskCache.cpp" [5] nsNetDiskCacheConstructor(aOuter = (nil), aIID = STRUCT, aResult = 0x649d58), line 65 in "nsNetModule.cpp" [6] nsGenericFactory::CreateInstance(this = 0x431488, aOuter = (nil), aIID = STRUCT, aResult = 0x649d58), line 47 in "nsGenericFactory.cpp" [7] nsComponentManagerImpl::CreateInstance(this = 0x3d8a0, aClass = STRUCT, aDelegate = (nil), aIID = STRUCT, aResult = 0x649d58), line 1172 in "nsComponentManager.cpp" [8] nsComponentManagerImpl::CreateInstanceByProgID(this = 0x3d8a0, aProgID = 0xfcfcc360 "component://netscape/network/cache?name=file-cache", aDelegate = (nil), aIID = STRUCT, aResult = 0x649d58), line 1211 in "nsComponentManager.cpp" [9] nsComponentManager::CreateInstance(aProgID = 0xfcfcc360 "component://netscape/network/cache?name=file-cache", aDelegate = (nil), aIID = STRUCT, aResult = 0x649d58), line 93 in "nsRepository.cpp" [10] nsCacheManager::Init(this = 0x649d40), line 155 in "nsCacheManager.cpp" ...

[richb - 5/11/00] > The workaround suggested by richb doesn't work, as ... Interesting. This was actually tried with a build of the Netscape commercial tree (as opposed to Mozilla) from a few days ago. It was a debug version compiled with Sun Workshop 5.0 compilers. We've been trying this internally and have been able to successfully browse (mail and AIM still core dump but the stack traces indicated that these were other problems).

I have the is as a seperate bug that is on my like to fix list. Is there a work around for sparc like on hpux or does this absolutely have to be fixed for 1.0? For a work around try disabling the cache ( try disableing the cache browser.cache.enable ) rather than setting its size to zero.

[richb - 5/10/00] > ...does this absolutely have to be fixed for 1.0? Excuse my ignorance but what does 1.0 mean? We would like this fix in for Mozilla beta2 (and therefore for Netscape PR2). How does that relate to your 1.0?

SUNWspro does have a "-misalign" option, but just recompiling netwerk/cache/filecache with that (like jdunn did for hpux) still resulted in misalignment crashes in the disk cache. -misalign (SPARC)(PowerPC) Permits misaligned data, which would otherwise generate an error, in memory, as shown in the following code: char b[100]; int f(int *ar){ return *(int *)(b +2) + *ar; } Thus, very conservative loads and stores must be used for the data, that is, one byte at a time. Using this option can cause significant degrada- tion in performance when you run the program. Note- If possible, do not link aligned and misaligned parts of the program.

This is a problem under Tru64 Unix too. Its not a fatal error there, it just prints a message. I dont think it is a good idea to work around this with a compiler switch. The CPU can not access non-aligned ints. The compiler switch might make it not crash, but it still has to do some sort of run time fixup which is going to be slow.

adding jgaunt and marking this so that when we fix this we can remove the HPUX compile flag hack in the makefile

*** Bug 38701 has been marked as a duplicate of this bug. ***

This works on HP... r= jdunn@netscape.com Gordon do you want to check this in... or do you want me to?

Looks reasonable to me. I say check it in.

reassigning to myself

Checked in fix

marking verified per engineers comments