Dual G5, 10.3.1 unexpected quit

[GarySome1]

Dual 2.0GHz G5 stock equipped with Panther 10.3.1. Working on a Metro file created from a file that was saved as a portable bundle from another machine (B&W G3) then edited on the G5.

The good news is that it always seems to be after I take an action like a mouse click (not just randomly in time), the bad news is that the action isn't always consistent. The Mac reports that Metro unexpectedly quit. If I try to restart Metro again the Mac nearly immediately reports that Metro unexpectedly quit. If I reboot I can run Metro again BUT sometimes Metro will complain that it needs the Aloisen font in the System folder (and the font is there) after the reboot. No other apps appear affected including MIDI & audio apps.

Remote control window: This one was fairly consistent. I was editing the remote control items, deleted a whole mess of them and then added many more. When I added the 4th channel volume I got an unexpected quit right after choosing controller 67 with the mouse. After rebooting several times and getting the same response I started taking actions between adding remote controllers (most notably saving my controller presets!). The thing that seems to keep the crash from happening was moving the section editor and graphic editor windows before making the next addition. I'm sure this is dumb luck but after I did it the problem went away.

Others: There are a some others and I will start keeping better track of them. Sorry, can't give specifics yet. I didn't see these on the G3 in Mac OS 9 but then again I wasn't using files from other machines.


On the bright side, maybe this is a reason to get a dual G5 in house .

Thanks and sorry so vague.

[Jerm]

What version of Metro are you using?

It may be helpful to go to the console program (in utilities) and turn on crash reporting. This will give a log when Metro quits so that we can point fingers.

[GarySome1]

OK, I will. I am using 6.1.0.4.

[Scoot]

Since you're a little vague......I'll be vague too.

Just a thought......since you said you were bringing in bundles from another computer.....so basically a different setup.....my thought would be......do you still have the same outputs available in both setups?

Lets say on the G3 you had QT, built in audio and a external synth connected, and you saved the bundle like that.

If the external synth is not connected to the G5 but the ports are still in the setup, you may run into trouble.


I've run into the setup problem above on the same machine......just be having my prefs saved with external synth ports available and then later working in metro with the external synth offline/unavailable.
Bringing in a soundfont would make metro quit as it was trying to select the DLSmusicdevice as the port.

Then again Jerm would say I'm a jinx!


scoot.

[GarySome1]

I do have one that's easily repeated. Open Metro (so a new Untitled document is up). Then open my cursed "portable bundle" project. The "Change Ports" dialog comes up with:
- all 8 Old Ports being listed as "Off" in the pop-menus
- all 8 New Ports being listed as "Off" in the pop-menus

I close the dialog choosing "OK". Now if I make no changes and the choose "New..." from the File menu I get a dialog from the Mac OS stating:
"The application Metro G4 has unexpectedly quit. The system and other applications have not been affected. Would you like to submit a bug report to Apple?"
NOTE: If I close the the "Change Ports" dialog using the "Cancel" button, this problem does not occur.

The good news is I can start Metro again with no problems.

Here is the output from the system.log:
===== Sun Nov 30 2003 ===== 23:06:10 US/Central =====
Nov 30 23:06:12 localhost /usr/libexec/fix_prebinding: /Applications/MIDI:Music/Metro G4/Metro G4.app/Contents/MacOS/Metro G4 could not be launched prebound.
Nov 30 23:06:12 localhost /usr/libexec/fix_prebinding: The file /Applications/MIDI:Music/Metro G4/Metro G4.app/Contents/MacOS/Metro G4 changed after the prebinding problem was noted.
Nov 30 23:06:12 localhost /usr/libexec/fix_prebinding: 2003-11-30 23:06:12 -0600: prebinding for Metro G4 done.
Nov 30 23:06:14 localhost kernel: TASCAM USB Audio Device: newUserClient
Nov 30 23:06:14 localhost kernel: TASCAM User Client: start
Nov 30 23:06:14 localhost kernel: TASCAM User Client: clientMemoryForType
Nov 30 23:06:14 localhost kernel: TASCAM USB Audio Device: SetAsyncPort - wake port 0x01AC22F0
Nov 30 23:06:14 localhost kernel: TASCAM USB Audio Device: SetParameter - proc 0x00245DD4 arg 0x01803648
Nov 30 23:06:51 localhost kernel: TASCAM User Client: clientClose
Nov 30 23:06:51 localhost kernel: TASCAM User Client: free
Nov 30 23:06:51 localhost crashdump: Started writing crash report to: /Users/gary/Library/Logs/CrashReporter/Metro G4.crash.log
Nov 30 23:06:51 localhost crashdump: Finished writing crash report to: /Users/gary/Library/Logs/CrashReporter/Metro G4.crash.log
Nov 30 23:08:12 localhost /usr/libexec/fix_prebinding: fix_prebinding quitting for now.

Here is /Users/gary/Library/Logs/CrashReporter/Metro G4.crash.log:
**********

Host: BlahBlahBlah.local
Date/Time: 2003-11-30 23:06:51 -0600
OS Version: 10.3.1 (Build 7C107)

Command: Metro G4 (/Applications/MIDI:Music/Metro G4/Metro G4.app/Contents/MacOS/Metro G4)
PID: 475
Thread: 3

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

Thread 0:
#0 0x90281998 in CompareAndSwap (CompareAndSwap + 20)
#1 0x90281d0c in AddAtomic (AddAtomic + 44)
#2 0x90282fb0 in AllocateHandleFromHandleBlock (AllocateHandleFromHandleBlock + 32)
#3 0x902834dc in AllocateHandleFromPoolList (AllocateHandleFromPoolList + 52)
#4 0x9028243c in AllocateHandleFromPool (AllocateHandleFromPool + 40)
#5 0x902835d8 in CSMemNewEmptyHandle (CSMemNewEmptyHandle + 24)
#6 0x90283208 in CSMemNewHandleClear (CSMemNewHandleClear + 32)
#7 0x91571780 in NewRectRgn (NewRectRgn + 104)
#8 0x9156c524 in CommonBits (CommonBits + 284)
#9 0x91592a68 in CopyDeepMask (CopyDeepMask + 196)
#10 0x92d3af2c in PlotCIcon (PlotCIcon + 256)
#11 0x0006ee34 in __code_start__ (__code_start__ + 440252)
#12 0x0006eccc in __code_start__ (__code_start__ + 439892)
#13 0x0006d1a8 in __code_start__ (__code_start__ + 432944)
#14 0x0006c700 in __code_start__ (__code_start__ + 430216)
#15 0x0006c5ec in __code_start__ (__code_start__ + 429940)
#16 0x0006c578 in __code_start__ (__code_start__ + 429824)
#17 0x0006f594 in __code_start__ (__code_start__ + 442140)
#18 0x0006bb58 in __code_start__ (__code_start__ + 427232)
#19 0x0006bab0 in __code_start__ (__code_start__ + 427064)
#20 0x000880ec in __code_start__ (__code_start__ + 543348)
#21 0x00087fcc in __code_start__ (__code_start__ + 543060)
#22 0x00087a04 in __code_start__ (__code_start__ + 541580)
#23 0x0000eb5c in __code_start__ (__code_start__ + 46308)
#24 0x0000eac8 in __code_start__ (__code_start__ + 46160)
#25 0x00034d64 in __code_start__ (__code_start__ + 202476)
#26 0x000968f8 in __code_start__ (__code_start__ + 602752)
#27 0x00086e68 in __code_start__ (__code_start__ + 538608)
#28 0x00086d48 in __code_start__ (__code_start__ + 538320)
#29 0x00010fc4 in __code_start__ (__code_start__ + 55628)
#30 0x0000f600 in __code_start__ (__code_start__ + 49032)
#31 0x000883a8 in __code_start__ (__code_start__ + 544048)
#32 0x00087d14 in __code_start__ (__code_start__ + 542364)
#33 0x000879e4 in __code_start__ (__code_start__ + 541548)
#34 0x00087ac8 in __code_start__ (__code_start__ + 541776)
#35 0x00086a20 in __code_start__ (__code_start__ + 537512)
#36 0x00003828 in __code_start__ (__code_start__ + 432)
#37 0x000036a8 in __code_start__ (__code_start__ + 48)

Thread 1:
#0 0x90018ce8 in semaphore_timedwait_signal_trap (semaphore_timedwait_signal_trap +
#1 0x9000e888 in _pthread_cond_wait (_pthread_cond_wait + 616)
#2 0x902aaddc in TSWaitOnSemaphoreCommon (TSWaitOnSemaphoreCommon + 176)
#3 0x902becb4 in TimerThread (TimerThread + 60)
#4 0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 2:
#0 0x900075c8 in mach_msg_trap (mach_msg_trap +
#1 0x90007118 in mach_msg (mach_msg + 56)
#2 0x81ebdc9c in XServerMachPort::ReceiveMessage(int&, void*, int&) (XServerMachPort::ReceiveMessage(int&, void*, int&) + 84)
#3 0x81eb0d58 in MIDIInPortThread::Run() (MIDIInPortThread::Run() + 316)
#4 0x81eb4e50 in XThread::RunHelper(void*) (XThread::RunHelper(void*) + 60)
#5 0x900247e8 in _pthread_body (_pthread_body + 40)

Thread 3 Crashed:
#0 0x000f77f4 in __code_start__ (__code_start__ + 999804)
#1 0x90723874 in IOADevice::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) (IOADevice::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 792)
#2 0x90723cc8 in HPIOThread::PerformIO(AudioTimeStamp const&) (HPIOThread::PerformIO(AudioTimeStamp const&) + 532)
#3 0x90722e7c in HPIOThread::WorkLoop() (HPIOThread::WorkLoop() + 1100)
#4 0x90739368 in HPIOThread::ThreadEntry(HPIOThread*) (HPIOThread::ThreadEntry(HPIOThread*) + 28)
#5 0x907393ac in CAPThread::Entry(CAPThread*) (CAPThread::Entry(CAPThread*) + 48)
#6 0x900247e8 in _pthread_body (_pthread_body + 40)

PPC Thread State:
srr0: 0x000f77f4 srr1: 0x0200f030 vrsave: 0x00000000
cr: 0x48000444 xer: 0x20000000 lr: 0x000f7774 ctr: 0x00000400
r0: 0x00000008 r1: 0xf0203a90 r2: 0x00000008 r3: 0x002faff8
r4: 0x00000004 r5: 0x00000000 r6: 0x04d2b164 r7: 0x00000002
r8: 0x00000400 r9: 0x00000002 r10: 0x00234c78 r11: 0x00224c68
r12: 0x00000001 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000
r20: 0x00000000 r21: 0xf0203d60 r22: 0xf0203c50 r23: 0x002faff8
r24: 0x00000400 r25: 0x00000001 r26: 0x04d2b164 r27: 0x00002000
r28: 0x00001000 r29: 0x000f7110 r30: 0x04d2b160 r31: 0x000f7774

[GarySome1]

I do have all the other crash logs as well if you'd like to see them (I had crash reporting on all along). There seems to be 3 common themes.
Thanks,
Gary

[GarySome1]

Scoot - it certainly sounds related!

[Scoot]

6.105 may iron out your problem when it is released.


scoot.

[GarySome1]

It is fixed in 6.1.0.5.
Thanks,
Gary

[Jerm]

Yippie!!!!