Trying the latest release (Rip-1.0pb2) going to ALAC and each time it seizes. It doesn't crash all the way and needs to be Force Quit
The first time I watched to see how things went. It immediately started overtaking the system, making app switching very sluggish. I fired up Application Monitor to watch. The CD has 6 tracks. By the 3rd AM showed Rip as not responding, but it was ever so slowly doing its thing. By the 5th track nothing would respond but I kept watching. It finally finished the 5th and started on the 6th (about an hour). After about another 10 minutes I need to actually do something and so ForceQuit it. Oddly, doing so through AM was not doable (or not so oddly as AM can eat up quite a bit of resources itself). But alt-cmd-esc did get it gone. When I did it AM showed Rip using 34 GB Virtual Memory and the whole system using 114 GB. Subsequent tries end the same (though I do end as soon as I hear the fans go wild).
Below is all I can find re: the crash
Process: Rip [9085]
Path: Rip
Identifier: Rip
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Date/Time: 2008-12-04 10:38:26.382 -0600
OS Version: Mac OS X 10.5.5 (9F33)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff834f7e2c
Crashed Thread: Unknown
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit):
rax: 0x000000000000237d rbx: 0x0000000000000000 rcx: 0x00007fff834f7e2c rdx: 0x0000000000000001
rdi: 0x00000001010ab000 rsi: 0x00007fff706556e8 rbp: 0x0000000101589e60 rsp: 0x0000000101589c90
r8: 0x00000001010a5070 r9: 0x00007fff83ad4a00 r10: 0x0000000000000001 r11: 0x0000000000000206
r12: 0x0000000000000003 r13: 0x0000000000000a00 r14: 0x0000000000000000 r15: 0x00000008003af3c0
rip: 0x00007fff834f7e2c rfl: 0x0000000000010206 cr2: 0x00007fff834f7e2c
Binary images description not available
ALAC crashes on b2 - a most amazing crash
Re: ALAC crashes on b2 - a most amazing crash
I had a similar result in b1 when trying to rip to ALAC. Rip did keep working until the end of the disk (when it crashed on the last track) but it soaked up pretty much all of both processors on my Dual G5. I havn't had time to try and replicate it yet though, so I haven't reported it. A lot of stuff was being dumped to the system logs as well.
I'll try again tonight on b2 and add some details if it happens again.
I'll try again tonight on b2 and add some details if it happens again.
Re: ALAC crashes on b2 - a most amazing crash
b2 was to have fixed ALAC. Nothing's easy.
2.4 GHZ Core2Duo
2.4 GHZ Core2Duo
Re: ALAC crashes on b2 - a most amazing crash
Since these are debug builds many messages are sent to the console which wouldn't otherwise be- I've noticed that excessive logging can tend to slow things down.
Regarding memory usage, Rip is a garbage collected app so maybe I'll dig around some more with Instruments and see if it would be beneficial to run the collector manually at times.
It's strange that it's crashing- not strange that crashes are happening, but that I can't reproduce any of them. I'll see if I can replicate one so I'll have somewhere to start from.
Regarding memory usage, Rip is a garbage collected app so maybe I'll dig around some more with Instruments and see if it would be beneficial to run the collector manually at times.
It's strange that it's crashing- not strange that crashes are happening, but that I can't reproduce any of them. I'll see if I can replicate one so I'll have somewhere to start from.
Re: ALAC crashes on b2 - a most amazing crash
Dang. So you're not having any problems with ALAC? I've only been using my MacBook Pro but I can try some others (G4 eMac and G3 iBook, as well as earlier Core Duo - no G5).
Re: ALAC crashes on b2 - a most amazing crash
I can now confirm that I see the slowdown with ALAC. I think it might be a problem on the 64-bit build only, because most of my testing has been with the 32-bit build and I hadn't noticed any problems. I'm not sure why the two would differ but for a test, could you Get Info on Rip in Finder and then check the "Open in 32 bit mode" box and see if the same thing happens?
Re: ALAC crashes on b2 - a most amazing crash
I'm also getting a system freeze on this. 2.2 SR MacBook.
CPU usage runs up over %100 by the second track, and everything becomes unresponsive. I give up pretty quick when this happens, and go for a power button restart.
I had this happen three times using an external and the internal drive.
Switched to FLAC, and problem is gone.
I'll dig around for the log files if it will help.
CPU usage runs up over %100 by the second track, and everything becomes unresponsive. I give up pretty quick when this happens, and go for a power button restart.
I had this happen three times using an external and the internal drive.
Switched to FLAC, and problem is gone.
I'll dig around for the log files if it will help.
Re: ALAC crashes on b2 - a most amazing crash
I just switched to 32 bit mode, and survived an ALAC rip 
It also seems to have fixed a problem I was seeing with the log only showing AR results for some of the tracks.
It also seems to have fixed a problem I was seeing with the log only showing AR results for some of the tracks.
Re: ALAC crashes on b2 - a most amazing crash
WOW! A most amazing difference. Switched to 32 bit. Used same CD started to ALAC and immediately switched back to something else, after a minute went down the hall for a few minutes, got back and started something else, then remembered I was ripping so switched. Lo and behold it was done with no issue at all.
So I started a second CD. I didn't restart Rip so the following starts at "where" it was after the 1st.
CPU: would peak to 100% or more when extraction of a track would begin, soon sinking and then hovering into the 20s, rising when each file was created (but only into the 40s or 50s briefly)
RAM: began the 2nd CD rip at 41 MB real and rose to 98 MB then down to 83 MB when CD ejected. Is still there 10 minutes after rip (CPU = 0) - not releasing memory?
VM: hold steady at 1.0 to 1.10 GB
2.4 GHz Core2Duo / 4 GB RAM
So I started a second CD. I didn't restart Rip so the following starts at "where" it was after the 1st.
CPU: would peak to 100% or more when extraction of a track would begin, soon sinking and then hovering into the 20s, rising when each file was created (but only into the 40s or 50s briefly)
RAM: began the 2nd CD rip at 41 MB real and rose to 98 MB then down to 83 MB when CD ejected. Is still there 10 minutes after rip (CPU = 0) - not releasing memory?
VM: hold steady at 1.0 to 1.10 GB
2.4 GHz Core2Duo / 4 GB RAM
Re: ALAC crashes on b2 - a most amazing crash
Well, it seems to be a 64-bit issue then! At least Rip is usable in the meantime until I devise a fix. Rip is the first application I've compiled for 64 bit, but I didn't expect to see radically different behavior like this.
Re: ALAC crashes on b2 - a most amazing crash
I just want to confirm that it seems to be a 64 Bit issue. Switching it to run in 32 bit mode solved the issue for me as well.
In 32 bit mode, Rip's virtual memory size was ~1.2 Gb. In 64 bit mode, it was ~8.5 gb. I don't know if this was just a disk thrashing issue. With pb2, I never actually crashed in 64 bit mode, it just made the machine virtually unresponsive. It did complete it's ripping to ALAC. During the rip, in the activity Monitor, rip was often listed as 'not responding'. At one point, Activity Monitor listed Rip as using 203% of the CPU, which is a neat trick for a machine with 2 single core processors
Here is a brief snippet of the log messages during this time:
Rip was process 3522. These messages repeated continuously over the space of the almost three hours it took to rip the CD. Things got even slower when SpinDump got involved. I haven't tried running with SpinDump diasbled. When running in 32 bit mode, I did not see these messages.
Here is a sample from activity monitor during this time:
I didn't see anything obvious in that though. let me know if you need any more info. This was on a Dual G5 with 2 GB RAM.
In 32 bit mode, Rip's virtual memory size was ~1.2 Gb. In 64 bit mode, it was ~8.5 gb. I don't know if this was just a disk thrashing issue. With pb2, I never actually crashed in 64 bit mode, it just made the machine virtually unresponsive. It did complete it's ripping to ALAC. During the rip, in the activity Monitor, rip was often listed as 'not responding'. At one point, Activity Monitor listed Rip as using 203% of the CPU, which is a neat trick for a machine with 2 single core processors
Here is a brief snippet of the log messages during this time:
Code: Select all
12/4/08 8:53:08 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:53:18 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:53:28 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:53:28 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:53:38 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:53:48 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:53:48 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:53:58 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:54:06 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:54:09 PM /usr/sbin/spindump[4298] process 3522 is being monitored
12/4/08 8:54:12 PM Rip[3522] Extracted sectors 65540 - 77854 to 5a9c4835.wav, 0 C2 block errors. MD5 = caceea522374a3e2bfb0f63150bb68db
12/4/08 8:54:32 PM /usr/sbin/spindump[4298] process 3522 is being no longer being monitored
12/4/08 8:56:32 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:56:32 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:56:42 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:56:44 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!
12/4/08 8:58:02 PM fseventsd[39] callback_client: ERROR: d2f_callback_rpc() => (ipc/send) timed out (268435460) for pid 3522
12/4/08 8:58:02 PM fseventsd[39] client: 0x812c00 : USER DROPPED EVENTS!Here is a sample from activity monitor during this time:
Code: Select all
Sampling process 3522 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling Rip (pid 3522) every 1 millisecond
Call graph:
641 Thread_2503
641 0x7fff5fbffc6c
641 start
641 main
641 NSApplicationMain
641 -[NSApplication run]
641 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
641 _DPSNextEvent
641 BlockUntilNextEventMatchingListInMode
641 ReceiveNextEventCommon
641 RunCurrentEventLoopInMode
641 CFRunLoopRunSpecific
641 __CFRunLoopDoObservers
641 _handleWindowNeedsDisplay
641 -[NSWindow displayIfNeeded]
641 -[NSView displayIfNeeded]
641 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
641 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
641 -[NSView _drawRect:clip:]
641 -[NSTableView drawRect:]
641 -[NSTableView drawRowIndexes:clipRect:]
641 -[NSTableView drawRow:clipRect:]
641 -[NSButtonCell drawInteriorWithFrame:inView:]
641 -[NSButtonCell(NSButtonCellPrivate) _imageRectWithRect:]
641 -[NSButtonCell(NSButtonCellPrivate) _buttonType]
641 +[NSButtonImageSource buttonImageSourceWithName:]
641 _NSAppKitImgLock
641 _CFDoExceptionOperation
641 malloc
641 malloc_zone_malloc
641 szone_malloc
446 __spin_lock_relinquish
446 __spin_lock_relinquish
195 __spin_lock
195 __spin_lock
641 Thread_2603
641 _pthread_start
641 auto_collection_thread(void*)
641 pthread_cond_wait
641 _pthread_cond_wait
641 __semwait_signal
641 __semwait_signal
641 Thread_2703
641 _pthread_start
641 __NSThread__main__
641 -[NSUIHeartBeat _heartBeatThread:]
641 -[NSConditionLock lockWhenCondition:beforeDate:]
641 -[NSCondition waitUntilDate:]
641 pthread_cond_timedwait_relative_np
641 _pthread_cond_wait
641 semaphore_timedwait_signal_trap
641 semaphore_timedwait_signal_trap
641 Thread_2803
641 _pthread_start
641 fe_fragment_thread
641 pthread_cond_wait
641 _pthread_cond_wait
641 __semwait_signal
641 __semwait_signal
641 Thread_2903
641 _pthread_start
641 __NSThread__main__
641 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
641 CFRunLoopRunSpecific
641 mach_msg
641 mach_msg_trap
641 mach_msg_trap
641 Thread_2a03
641 _pthread_start
641 CFURLCacheWorkerThread(void*)
641 CFRunLoopRunSpecific
641 mach_msg
641 mach_msg_trap
641 mach_msg_trap
641 Thread_2b03
641 __CFSocketManager
641 select$DARWIN_EXTSN
641 select$DARWIN_EXTSN
641 Thread_2c03
641 _pthread_start
641 PrivateMPEntryPoint
641 TSystemNotificationTask::SystemNotificationTaskProc(void*)
641 CFRunLoopRun
641 CFRunLoopRunSpecific
641 mach_msg
641 mach_msg_trap
641 mach_msg_trap
641 Thread_2d03
641 _pthread_start
641 PrivateMPEntryPoint
641 TFSEventsNotificationTask::FSEventsNotificationTaskProc(void*)
641 CFRunLoopRun
641 CFRunLoopRunSpecific
641 __CFMachPortPerform
641 FSEventsClientProcessMessageCallback
641 FSEventsD2F_server
641 _Xcallback_rpc
641 implementation_callback_rpc
641 malloc
641 malloc_zone_malloc
641 szone_malloc
453 __spin_lock_relinquish
453 __spin_lock_relinquish
188 __spin_lock
188 __spin_lock
641 Thread_2e03
641 _pthread_start
641 PrivateMPEntryPoint
641 TNodeSyncTask::SyncTaskProc(void*)
641 MPWaitOnQueue
641 TSWaitOnConditionTimedRelative
641 TSWaitOnCondition
641 pthread_cond_wait
641 _pthread_cond_wait
641 __semwait_signal
641 __semwait_signal
641 Thread_2f03
641 __monitor_file_descriptor__
641 kevent
641 kevent
641 Thread_3003
641 _pthread_start
641 __NSThread__main__
641 -[NSOperation start]
641 -[AppleLosslessEncodeOperation main]
641 -[NSConcreteTask launchWithDictionary:]
641 fork
641 fork
641 Thread_3103
641 _pthread_start
641 __NSThread__main__
641 -[NSOperation start]
641 -[ExtractionOperation main]
641 AudioFileClose
641 AudioFileObject::Close()
641 Cached_DataSource::~Cached_DataSource()
641 szone_free
417 __spin_lock_relinquish
417 __spin_lock_relinquish
224 __spin_lock
224 __spin_lock
Total number in stack (recursive counted multiple, when >=5):
10 _pthread_start
5 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
5 CFRunLoopRunSpecific
Sort by top of stack, same collapsed (when >= 5):
__semwait_signal 1923
mach_msg_trap 1923
__spin_lock_relinquish 1316
fork 641
kevent 641
select$DARWIN_EXTSN 641
semaphore_timedwait_signal_trap 641
__spin_lock 607
Re: ALAC crashes on b2 - a most amazing crash
I ran into the same system take-over with B2 ripping to ALAC.
Around track two the who system became completely unresponsive. Unable to switch applications, or even kill one.
So had to force quit Mac OS X.
Around track two the who system became completely unresponsive. Unable to switch applications, or even kill one.
So had to force quit Mac OS X.