David Beaudry

My patch has been crashing quite a bit lately. I'm really having some difficulty, tho, tracking down the problem. What is consistent in each crash is the text of the thread that wasn't happy (see below). Any pointers on how to issolate this so I can be a better (potential) bug reporter? ;)

0 sfplay~     0x1759997c sfplay_calc_pos + 96

2 sfplay~     0x17598ff0 sfplay_perform + 1132

3 MaxAudioLib     0x007cf06c dspchain_tick + 80

4 poly~     0x0bd4d108 poly_run + 132

5 poly~     0x0bd4cd48 poly_processnormal + 92

6 poly~     0x0bd4ccb0 poly_perform + 140

7 MaxAudioLib     0x007cf06c dspchain_tick + 80

8 MaxAudioLib     0x007cd20c ad_process + 392

9 CoreAudiod     0x048b4b34 coreaudio_onedevice_ioproc + 276

10 com.apple.audio.CoreAudio     0x9145bed0 IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 376

11 com.apple.audio.CoreAudio     0x9145bbe4 HP_IOThread::PerformIO(AudioTimeStamp const&) + 532

12 com.apple.audio.CoreAudio     0x91459bf4 HP_IOThread::WorkLoop() + 1156

13 com.apple.audio.CoreAudio     0x9145975c HP_IOThread::ThreadEntry(HP_IOThread*) + 16

14 com.apple.audio.CoreAudio     0x9144a5dc CAPThread::Entry(CAPThread*) + 96

15 libSystem.B.dylib     0x9002ba68 _pthread_body + 96

Hi all,
My patch has been crashing quite a bit lately. I'm really having some difficulty, tho, tracking down the problem. What is consistent in each crash is the text of the thread that wasn't happy (see below). Any pointers on how to issolate this so I can be a better (potential) bug reporter? ;)

Thread 20 Crashed:
0   sfplay~                        	0x1759997c sfplay_calc_pos + 96
1   <> 	0x43300000 0 + 1127219200
2   sfplay~                        	0x17598ff0 sfplay_perform + 1132
3   MaxAudioLib                    	0x007cf06c dspchain_tick + 80
4   poly~                          	0x0bd4d108 poly_run + 132
5   poly~                          	0x0bd4cd48 poly_processnormal + 92
6   poly~                          	0x0bd4ccb0 poly_perform + 140
7   MaxAudioLib                    	0x007cf06c dspchain_tick + 80
8   MaxAudioLib                    	0x007cd20c ad_process + 392
9   CoreAudiod                     	0x048b4b34 coreaudio_onedevice_ioproc + 276
10  com.apple.audio.CoreAudio      	0x9145bed0 IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 376
11  com.apple.audio.CoreAudio      	0x9145bbe4 HP_IOThread::PerformIO(AudioTimeStamp const&) + 532
12  com.apple.audio.CoreAudio      	0x91459bf4 HP_IOThread::WorkLoop() + 1156
13  com.apple.audio.CoreAudio      	0x9145975c HP_IOThread::ThreadEntry(HP_IOThread*) + 16
14  com.apple.audio.CoreAudio      	0x9144a5dc CAPThread::Entry(CAPThread*) + 96
15  libSystem.B.dylib              	0x9002ba68 _pthread_body + 96

maxmsp-crash-sfplay_calc_pos

On around May 7, 2006, at 6:13, david beaudry said something like:

> My patch has been crashing quite a bit lately. I'm really having some 

> difficulty, tho, tracking down the problem. What is consistent in each 

> crash is the test of the thread that wasn't happy (see below). Any 

> pointers on how to issolate this so I can be a better (potential) bug 

Tracking down bugs can be hard, no question.

In this case, Crash Log lines (0) and (2) indicate the immediate 

problem is in sfplay~, and lines 4-6 indicate it's inside a poly~. The 

function call in line (0) indicates a problem with calculating playback 

position, which you probably guessed yourself. Sfplay~ itself is pretty 

reliable, so the problem may be with the sound file.

You might try isolating your poly~s, see if any crashes by itself or in 

a patch using just a few instantiations of a single poly.

> 0 sfplay~     0x1759997c sfplay_calc_pos + 96

> 2 sfplay~     0x17598ff0 sfplay_perform + 1132

> 3 MaxAudioLib     0x007cf06c dspchain_tick + 80

> 4 poly~     0x0bd4d108 poly_run + 132

> 5 poly~     0x0bd4cd48 poly_processnormal + 92

> 6 poly~     0x0bd4ccb0 poly_perform + 140

| Litter Power & Litter Bundle for Jitter

pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building

http://www.dspaudio.com/software/software.html

On around May 7, 2006, at 6:13, david beaudry said something like:
> My patch has been crashing quite a bit lately. I'm really having some 
> difficulty, tho, tracking down the problem. What is consistent in each 
> crash is the test of the thread that wasn't happy (see below). Any 
> pointers on how to issolate this so I can be a better (potential) bug 
> reporter? ;)

In this case, Crash Log lines (0) and (2) indicate the immediate 
problem is in sfplay~, and lines 4-6 indicate it's inside a poly~. The 
function call in line (0) indicates a problem with calculating playback 
position, which you probably guessed yourself. Sfplay~ itself is pretty 
reliable, so the problem may be with the sound file.

You might try isolating your poly~s, see if any crashes by itself or in 
a patch using just a few instantiations of a single poly.

> Thread 20 Crashed:
> 0   sfplay~                        	0x1759997c sfplay_calc_pos + 96
> 1   <> 	0x43300000 0 + 1127219200
> 2   sfplay~                        	0x17598ff0 sfplay_perform + 1132
> 3   MaxAudioLib                    	0x007cf06c dspchain_tick + 80
> 4   poly~                          	0x0bd4d108 poly_run + 132
> 5   poly~                          	0x0bd4cd48 poly_processnormal + 92
> 6   poly~                          	0x0bd4ccb0 poly_perform + 140
>
--------------    http://www.bek.no/~pcastine/Litter/    --------------
Peter Castine    |                             ^
                  |         Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no  | iCE:  Sequencing, Recording, and Interface Building
4-15@kagi.com    |       for Max/MSP
                  |                                      Extremely cool
                  |      http://www.dspaudio.com
                  |      http://www.dspaudio.com/software/software.html


max/msp crash: sfplay_calc_pos?