If you aren't going to delete your interface quite yet, perhaps
CFRunLoopRemoveSource would be the better choice.
- Rob
On Apr 19, 2005, at 11:31 PM, Denis Pelli wrote:
dear rob
i sprinkled my code with printf statements to determine where the
crash happens. I crash when I call CFRunLoopAddSource. I pasted the
stack trace below.
RECAP: setInterruptReportHandlerCallback is a great way to receive
reports from a HID device. It works perfectly. The problem is turning
it off. I have not found any way of stopping the callbacks without
leaving the system in a damaged state. Calling
CFRunLoopSourceInvalidate does stop the callbacks, but after calling
this I can no longer re-enable the callbacks (by calling
createAsyncEventSource, CFRunLoopAddSource, and
setInterruptReportHandlerCallback). There's no error, but the
callbacks don't happen. If I follow the call to
CFRunLoopSourceInvalidate by a call to HIDReleaseDeviceList, to
destroy the interface, then things are ok unless I try to start up
again, calling HIDBuildDeviceList, etc. When I call
CFRunLoopAddSource, I crash. Is there a way to stop the callbacks
without damaging the system?
// Everything works the first time through:
HIDBuildDeviceList();
...
// To enable callbacks, i do the following once for each device
interface. My composite device has 4 interfaces.
{
error=(*interface)-
>createAsyncEventSource(interface,&(source[deviceIndex]));
CFRunLoopAddSource(CFRunLoopGetCurrent(),source[deviceIndex],myRunLoopM
ode);
error=(*interface)-
>setInterruptReportHandlerCallback(interface,buffer,bufferSize,ReportCa
llback,buffer,(void *)deviceIndex);
ready[deviceIndex]=1;
}
// I call this hundreds of times, and it works perfectly. My
callback receives all the reports.
reason=CFRunLoopRunInMode(myRunLoopMode,0.001,false);
...
// When I'm about to be flushed, I disable the callbacks and
destroy the interfaces.
for(deviceIndex=0;deviceIndex<MAXDEVICEINDEXS;deviceIndex++)
if(ready[deviceIndex]){
ready[deviceIndex]=0;
CFRunLoopSourceInvalidate(source[deviceIndex]);
source[deviceIndex]=0;
}
HIDReleaseDeviceList();
// So far so good, but the sequel is not so happy. Calling
CFRunLoopAddSource is fatal.
HIDBuildDeviceList();
...
error=(*interface)-
>createAsyncEventSource(interface,&(source[deviceIndex]));
CFRunLoopAddSource(CFRunLoopGetCurrent(),source[deviceIndex],myRunLoopM
ode);
***CRASH!!!****
The $64 question is: how can I stop the callbacks without bad
consequences later?
best
denis
Denis Pelli
Professor of Psychology and Neural Science
http://psych.nyu.edu/pelli/
p.s.
Do you think I should supplement my call to CFRunLoopSourceInvalidate
by a call to CFRunLoopRemoveSource?
I've pasted below the stack trace of the crash. PsychHID.mexmax is my
MATLAB extension. It was invoked by the MATLAB command
"PsychHID('ReceiveReports',device);". My printout indicates that I
crash in the call to CFRunLoopAddSource. The stack trace indicates
that I'm dying in the Core Foundation.
DaqDIn: reading digital ports.
4: createAsyncEventSource
4: CFRunLoopAddSource
-----------------------------------------------------------------------
-
Segmentation violation detected at Wed Apr 20 01:11:54 2005
-----------------------------------------------------------------------
-
Configuration:
MATLAB Version: 7.0.1.24704 (R14) Service Pack 1
MATLAB License: 238492
Operating System: Darwin 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec
22 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power
Macintosh
Window System: The XFree86 Project, Inc (40300000), display :0.0
Current Visual: 0x22 (class 4, depth 24)
Virtual Machine: Java 1.4.2_05 with "Apple Computer, Inc." Java
HotSpot(TM) Client VM
(mixed mode)
Default Charset: US-ASCII
r0 = 9019dba8 r8 = a0190dcc r16 = f0ffc3f0 r24 = 02c1d2f0
r1 = f0ffb0f0 r9 = 0000001f r17 = 00000162 r25 = f0ffb320
r2 = a0195b68 r10 = 00001f80 r18 = f0ffc450 r26 = 00000000
r3 = 00000001 r11 = 00001f00 r19 = 00000001 r27 = 0ee27ab0
r4 = 0ee27ab0 r12 = 9019db90 r20 = 0e6eca8c r28 = 0e785ab0
r5 = 00000000 r13 = 00000000 r21 = f0ffc910 r29 = 00000000
r6 = 4c6f6f70 r14 = 00000000 r22 = 00000001 r30 = a0193228
r7 = a0190dcc r15 = 00000001 r23 = f0ffb2b0 r31 = 90191224
cr = 24022288 lr = 90191224 xer = 00000004 ctr = 9019db90
vrsave = 00000000
Stack Trace:
[0] CoreFoundation:0x90191244
[1] CoreFoundation:0x9019dba8
[2] CoreFoundation:0x9019137c
[3] CoreFoundation:0x901965f8
[4] CoreFoundation:0x9019d9e8
[5] CoreFoundation:0x90197998
[6] CoreFoundation:0x901b57d8
[7] PsychHID.mexmac:0x0ee13490
[8] PsychHID.mexmac:0x0ee12b00
[9] PsychHID.mexmac:0x0ee0ad00
[10] libmex.dylib:mexRunMexFile + 116 bytes
[11] libmex.dylib:Mfh_mex::dispatch_file(int, mxArray_tag**, int,
mxArray_tag**) + 316 bytes
[12] libmwm_dispatcher.dylib:0x007356ac
[13] libmwm_interpreter.dylib:0x01369e20
...
[40] libmwmcr.dylib:0x0046a2a0
[41] MATLAB:mcrMain(int, char**) + 400 bytes
[42] MATLAB:run_main(void*) + 24 bytes
[43] libSystem.B.dylib:0x900246e8
This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for
information
on debugging MEX-files.
...
Error in ==> DaqDIn at 14
err=PsychHID('ReceiveReports',device);
Error in ==> TestDaq at 147
data=DaqDIn(daq(1));
>> _______________________________________________
