[brickcam]

Hi, thanks for reading.

My iBook G4 running 10.4.10 is not performing well. Applications regularly crash; the longer the computer stays running, the more frequently they crash. It's my hope that Firefox will stay open long enough to finish this post.

Here's what I've tried: reinstalled Tiger, and copied my User folder over the fresh install. Used the combo update. The problems persisted.

Investigated the possibility of corrupt fonts, validated them with Font Book, Font Finagler, etc.

Repaired permissions/disk several times. Emptied the caches.

Created a new user and futzed around there for a while. The crashing continued. It was my guess that this ruled out the possibility of individual user preferences creating the problem, and since I had reinstalled the system, I figured the system ones were okay.

Ran Rember for many cycles on my RAM: no problems.

I rebooted using the install cd and tried to find the Apple Hardware Test program: didn't seem to find it.

I'm at wits end and would appreciate any input. Here is a sample of the crashes I've been having:

Command: firefox-bin
Path: /Applications/Firefox.app/Contents/MacOS/firefox-bin
Parent: WindowServer [68]

Version: 2.0.0.6 (2.0.0.6)

PID: 732
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000134

Thread 0 Crashed:
0 libxpcom_core.dylib 0x2c0021b8 nsCOMPtr_base::~nsCOMPtr_base [unified]() + 16
1 org.mozilla.firefox 0x00a5c274 MOZ_Z__length_code + 188632
2 libxpcom_core.dylib 0x2c0019d8 PL_DHashTableFinish + 108
3 org.mozilla.firefox 0x00591a38 nsBindingManager::~nsBindingManager [unified]() + 188
4 org.mozilla.firefox 0x005916d4 nsBindingManager::Release() + 64
5 org.mozilla.firefox 0x001b8468 nsDocument::~nsDocument [unified]() + 1608
6 org.mozilla.firefox 0x0016d574 nsXMLDocument::~nsXMLDocument [unified]() + 240
7 org.mozilla.firefox 0x0016fee4 nsXULDocument::~nsXULDocument [unified]() + 1012
8 org.mozilla.firefox 0x001b8f4c nsDocument::Release() + 68
9 org.mozilla.firefox 0x003f6a70 XPCJSRuntime::GCCallback(JSContext*, JSGCStatus) + 1532
10 org.mozilla.firefox 0x005bc658 nsJSContext::FireGCTimer() + 252
11 libmozjs.dylib 0x2302e9d8 js_GC + 2512
12 libmozjs.dylib 0x23003044 JS_GC + 76
13 org.mozilla.firefox 0x005bc514 nsJSContext::Notify(nsITimer*) + 32
14 libxpcom_core.dylib 0x2c04bb0c nsTimerImpl::Fire() + 196
15 libxpcom_core.dylib 0x2c04bc18 handleTimerEvent(TimerEventType*) + 140
16 libxpcom_core.dylib 0x2c047a9c PL_HandleEvent + 36
17 libxpcom_core.dylib 0x2c0479c0 PL_ProcessPendingEvents + 128
18 com.apple.CoreFoundation 0x907de4fc __CFRunLoopDoSources0 + 384
19 com.apple.CoreFoundation 0x907dda2c __CFRunLoopRun + 452
20 com.apple.CoreFoundation 0x907dd4ac CFRunLoopRunSpecific + 268
21 com.apple.HIToolbox 0x93298b20 RunCurrentEventLoopInMode + 264
22 com.apple.HIToolbox 0x932981b4 ReceiveNextEventCommon + 380
23 com.apple.HIToolbox 0x932dd348 AcquireNextEventInMode + 72
24 com.apple.HIToolbox 0x932dd138 RunApplicationEventLoop + 132
25 org.mozilla.firefox 0x002966f4 nsAppShell::Run() + 64
26 org.mozilla.firefox 0x00334328 nsAppStartup::Run() + 60
27 org.mozilla.firefox 0x00012a14 XRE_main + 4904
28 org.mozilla.firefox 0x0000d768 start + 432
29 org.mozilla.firefox 0x0000d5e8 start + 48

and the full log:

http://cb.nfshost.com/firefox-bin.crash.log

Thank you again for your time.

[reader50]

My first thought is a heat sink or fan problem. More crashes the longer the iBook stays up points towards temperature as the culprit.

To find the Apple Hardware Test: boot from the install disk while holding down Option. The Hardware Test may show as an alternate session on the Install disk.

[brickcam]

Thanks for your reply. I suppose it could be an issue of temp: FWIW, the case temperature does not seem any different. I'll keep an eye on that.

I booted twice from the Tiger install disk holding down option and the AHT did not show up: it just put me directly into the install process.

I didn't mention in my main post that when I copied over the /Users/ folder I did it according to specific instructions involving the root user, etc., so I don't think that's a suspect step.

Is it reasonable to assume that the preferences aren't the issue given the multiple-user crashing and the system wipe?

[brickcam]

Update: it appears to be the RAM. Can someone tell me what this means? Does it mean that it is for-sure bad?

The reason it didn't come up before is that apparently the memory available for Rember when I ran it before was only a fraction of my total memory. Logging on as a blank user left waaay more RAM free and when I ran it THERE, it spat this:


Memtest version 4.13 (32-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004, 2005 Tony Scaminaci (Macintosh port)
Licensed under the GNU General Public License version 2 only

MacOS X (Darwin) running in multiuser mode
POSIX version 200112
Pagesize is 4096
Requested memory: 932MB (977866752 bytes)
Available memory: 932MB (977866752 bytes)
Allocated memory: 932MB (977866752 bytes) at local address 0x02008000
Attempting memory lock... locked successfully
Creating test buffers...
Buffer A: 466MB (488933376 bytes) at local address 0x02008000
Buffer B: 466MB (488933376 bytes) at local address 0x1f250800

Running 40 test sequences...

Test sequence 1 of 40:
Stuck Address : setting 1 of 16ok
Random Value :  ok
Compare XOR :  ok
Compare SUB :  FAILURE: 0x0b281760 != 0x0ba81760 at offset 0x01ed657b.
Compare MUL :  FAILURE: 0xe3252f80 != 0x3d252f80 at offset 0x01ed657b.
Compare DIV :  FAILURE: 0x00000001 != 0x00000000 at offset 0x01ed657b.
Compare OR :  ok
Compare AND :  ok
Sequential Increment:  ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : setting 1 of 64ok
Bit Spread : ok
Bit Flip :

[Big Mac]

You seem to have hit upon it - I think showing a failure is pretty conclusive.

[P]

Oh, you were running the RAM test from inside OS X? That's not really reliable - always use the Hardware Test disc that Apple supplies.

But yes, you have hardware errors, and almost certainly RAM (at the noted offset) although it could be somewhere else in theory.

[analogika]

The only problem with bad RAM is that EVERYTHING you have copied, or installed since the failure showed up is potentially corrupted.

Meaning that you MUST completely re-install EVERYTHING once the faulty RAM has been replaced.

[brickcam]

Originally Posted by analogika 

The only problem with bad RAM is that EVERYTHING you have copied, or installed since the failure showed up is potentially corrupted.

Meaning that you MUST completely re-install EVERYTHING once the faulty RAM has been replaced.

Wow, geez. Applications, okay: is it safe to copy over my User folder onto the new build?

[Big Mac]

Your user files should be okay.

[brickcam]

RE: the apple hardware test, and me not being able to find it: I didn't realize it was a separate disk that shipped with my computer. Hope that helps someone else avoid my confusion.