Problem with clock_fdelay() under Xcode

Mar 7, 2007 at 11:58am

Problem with clock_fdelay() under Xcode

hello,

i’m porting an external from Codewarrior to Xcode. It uses
clock_fdelay() etc. to schedule events. The functions run fine when
compiled with CW and running under Max 4.5.7 but give an
EXC_BAD_ACCESS KERN_PROTECTION_FAILURE crash in a nested clock_fdelay2
() function when compiled under Xcode and running under Max 4.6.2.

when i look at the arguments for clock_fdelay2() in the debugger i
_do_ see the correct clock pointer and delay and offset times.

the object uses 4 different clocks which i declare as an array of
clocks like so:

void *c_new(t_symbol *fn)
{
// snipp
x->l_clock[0] = clock_new(x,(method)tick);
// snipp
}

clock_fdelay() gets called like this:

void cdm_run(t_myob *x)
{
// snipp
clock_fdelay(x->l_clock[n], (double)(read->data[1].a_w.w_long * x-
>l_tempofactor[n]));
// snipp
}

void tick(t_myob *x)
{
// snipp
clock_fdelay(x->l_clock[n], (double)(read->data[1].a_w.w_long * x-
>l_tempofactor[n]));
// snipp
}

where the second argument gets calc’ed from an element in a
linked_list and a factor and n is a dynamic clock selector.

all of this works fine in CW !!

i’ve been digging with GDB and comparing debugger-variables from CW
to Xcode but i can’t seem to make out a difference (apart from the
fact that the CW-debugger doesn’t let me see the clock_function’s
states in the max-kernel, which is shown with GDB)

one thing i’ve tried is to set local pointers for the clocks, trying
to dereference by on layer the clock-pointer.

what i noticed is that in the ext_proto.h file clock_fdelay is
declared twice with just nuances in the signature.

oh, and the same problem also occurs when using clock_delay()

any ideas and help is very welcome.

/*j

an example crash_report:

Date/Time: 2007-03-07 12:49:15.366 +0100
OS Version: 10.4.8 (Build 8L127)
Report Version: 4

Command: MaxMSP
Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
Parent: WindowServer [61]

Version: ??? (4.6.2)

PID: 1302
Thread: 0

Exception: EXC_BAD_ACCESS (0×0001)
Codes: KERN_PROTECTION_FAILURE (0×0002) at 0x0000000d

Thread 0 Crashed:
0 com.cycling74.MaxMSP46 0×00019794 clock_fdelay2 + 56
(clock.c:136)
1 com.cycling74.MaxMSP46 0x0001981c clock_fdelay + 48
(clock.c:144)
2 com.cycling74.MaxAPI 0x0180be80 clock_fdelay + 68
3 ch.jasch.myob 0x228f5c8c myob_run + 700 (myob.c:701)
4 ch.jasch.myob 0x2290d2bc wrap_myob_run + 204
(myob.c:1339)
5 ch.jasch.myob 0x2290cd54 myob_playcurrent + 292
(myob.c:1265)
6 com.cycling74.MaxMSP46 0x0002daac ob_funcall + 684
(funcall..c:219)
7 com.cycling74.MaxMSP46 0x00044b70 typedmess_fun + 3176
(message.c:682)
8 com.cycling74.MaxMSP46 0x0014a8ac outlet_anything + 536
(inletoutlet.c:960)
9 com.cycling74.MaxMSP46 0x000440b4 typedmess_fun + 428
(message.c:492)
10 com.cycling74.MaxMSP46 0x0014a8ac outlet_anything + 536
(inletoutlet.c:960)
11 com.cycling74.MaxMSP46 0x000e43f4 send_anything(send*,
symbol*, short, atom*) + 80 (send.c:57)
12 com.cycling74.MaxMSP46 0x000440b4 typedmess_fun + 428
(message.c:492)
13 com.cycling74.MaxMSP46 0x0014a8ac outlet_anything + 536
(inletoutlet.c:960)
14 com.cycling74.MaxMSP46 0x000440b4 typedmess_fun + 428
(message.c:492)
15 com.cycling74.MaxMSP46 0x00044e2c typedmess + 104
(message.c:399)
16 com.cycling74.MaxMSP46 0x00045ef4 aeval + 1804
(message.c:1061)
17 com.cycling74.MaxMSP46 0x0000bbc0 atombuf_eval + 156
(atombuf.c:232)
18 com.cycling74.MaxMSP46 0x0010639c vmessage_float
(_vmessage*, double) + 144 (vmessage.c:74)
19 com.cycling74.MaxMSP46 0x00149de8 outlet_float + 496
(inletoutlet.c:831)
20 com.cycling74.MaxMSP46 0x000e0678 real_bang(real*) + 52
(real.c:25)
21 com.cycling74.MaxMSP46 0×00149754 outlet_bang + 476
(inletoutlet.c:654)
22 com.cycling74.MaxMSP46 0x000a9d14 vbutton_bang(vbutton*)
+ 84 (button.c:192)
23 com.cycling74.MaxMSP46 0x00149a98 outlet_int + 488
(inletoutlet.c:740)
24 com.cycling74.MaxMSP46 0x000cb680 vnumber_int(_vnumber*,
long) + 100 (number.c:382)
25 com.cycling74.MaxMSP46 0x00149a98 outlet_int + 488
(inletoutlet.c:740)
26 com.cycling74.MaxAPI 0x0180b3dc outlet_int + 68
27 com.cycling74.counter 0×20197860 counter_bang + 96
28 com.cycling74.MaxMSP46 0×00149754 outlet_bang + 476
(inletoutlet.c:654)
29 com.cycling74.MaxMSP46 0x000a9c68 vbutton_click
(vbutton*, Point) + 60 (button.c:179)
30 com.cycling74.MaxMSP46 0x0001574c box_click + 224 (box.c:
123)
31 com.cycling74.MaxMSP46 0x0004d37c patcher_boxclick + 652
(patcher.c:2175)
32 com.cycling74.MaxMSP46 0x0004ff6c patcher_click + 1692
(patcher.c:2424)
33 com.cycling74.MaxMSP46 0x00099b28 wind_click + 212
(window.c:1118)
34 com.cycling74.MaxMSP46 0x000a0e40 wind_event + 644
(window.c:818)
35 com.cycling74.MaxMSP46 0x00038f2c app_eventhandler
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1512 (main.c:
1597)
36 com.apple.HIToolbox 0×93202554 DispatchEventToHandlers
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
37 com.apple.HIToolbox 0x93201cac
SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*) + 372
38 com.apple.HIToolbox 0x93208a60 SendEventToEventTarget
+ 40
39 com.apple.HIToolbox 0x93294d48
HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned
short) + 236
40 com.apple.HIToolbox 0x932942c0 HandleMouseEvent
(OpaqueEventRef*) + 368
41 com.apple.HIToolbox 0x93208dcc
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*) + 496
42 com.apple.HIToolbox 0x932027a4 DispatchEventToHandlers
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
43 com.apple.HIToolbox 0x93201cac
SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*) + 372
44 com.apple.HIToolbox 0x93208a60 SendEventToEventTarget
+ 40
45 com.apple.HIToolbox 0x932497a0 ToolboxEventDispatcher
+ 92
46 com.apple.HIToolbox 0x9324972c HLTBEventDispatcher + 16
47 com.apple.HIToolbox 0x93247ce4
RunApplicationEventLoop + 148
48 com.cycling74.MaxMSP46 0x0003859c app_run + 96 (main.c:
1458)
49 com.cycling74.MaxMSP46 0×00038870 main + 704 (main.c:415)
50 com.cycling74.MaxMSP46 0x00001f5c _start + 340 (crt.c:272)
51 com.cycling74.MaxMSP46 0x00001e04 start + 60

Thread 0 crashed with PPC Thread State 64:
srr0: 0×0000000000019794 srr1:
0x000000000200f030 vrsave: 0×0000000000000000
cr: 0×24022244 xer: 0×0000000020000004 lr:
0x000000000001981c ctr: 0x00000000000197ec
r0: 0×0000000000000001 r1: 0x00000000bfffca00 r2:
0×0000000000000001 r3: 0x0000000022807c68
r4: 0×0000000000000000 r5: 0×0000000000000000 r6:
0x00000000ffffffff r7: 0×0000000080808080
r8: 0×0000000000000030 r9: 0x00000000229359fc r10:
0x000000002d2f2f2f r11: 0×0000000022932034
r12: 0x00000000000197ec r13: 0×0000000000000002 r14:
0×0000000000000000 r15: 0x00000000a32022b8
r16: 0x00000000214bc2d0 r17: 0x00000000bffff640 r18:
0x000000006d6f7573 r19: 0×0000000000000001
r20: 0x0000000000c36550 r21: 0x00000000ffffd96e r22:
0×0000000000000000 r23: 0x00000000bffff7c0
r24: 0×0000000000000000 r25: 0x00000000bffff640 r26:
0x00000000214bc2d0 r27: 0×0000000000000000
r28: 0x00000000bffff644 r29: 0x0000000000c1f090 r30:
0x00000000bfffca00 r31: 0x000000000180be54

#30670
Mar 7, 2007 at 5:36pm

On Mar 7, 2007, at 3:58 AM, /*j wrote:

> i’m porting an external from Codewarrior to Xcode. It uses
> clock_fdelay() etc. to schedule events. The functions run fine when
> compiled with CW and running under Max 4.5.7 but give an
> EXC_BAD_ACCESS KERN_PROTECTION_FAILURE crash in a nested
> clock_fdelay2() function when compiled under Xcode and running
> under Max 4.6.2.
>
> when i look at the arguments for clock_fdelay2() in the debugger i
> _do_ see the correct clock pointer and delay and offset times.
>
> the object uses 4 different clocks which i declare as an array of
> clocks like so:=

Well, since I can confirm that clock_fdelay works fine for many of
our own externals, I can only assume that there’s one of three problems:

1. You are using an old version of MaxAPI.framework (you can grab the
latest from inside the application bundle if necessary).

2. You are accessing an invalid clock in your clock array. This might
not crash on CW depending on memory layout.

3. Some other part of your code is overwriting some elements in your
clock array. Again, this might not crash on CW depending on memory
layout.

Not saying it’s definitely one of these, but I can’t think of
anything else in the absence of more code.

-Joshua

#98522

You must be logged in to reply to this topic.