Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cancel setInterruptReportHandlerCallback?



dear rob

thanks. what you say makes sense and gives me some things to try.

however, could you clarify one point?

as far as i know, i never explicitly free/release the source. i only call CFRunLoopSourceInvalidate or CFRunLoopRemoveSource and HIDReleaseDeviceList (yes, i know, it's a HID Utility). do they free the source? should I be freeing the source before calling HIDReleaseDeviceList?

is it possible that the source persists across the destruction and recreation of the interface (HIDReleaseDeviceList and HIDBuildDeviceList), so it's still there when i call createAsyncEventSource with my "new" interface? should i retain the old source and refrain from calling createAsyncEventSource? (it's not easy to retain anything, since my code is flushed, but i'm sure i could lock down a bit of memory somewhere, perhaps as a MATLAB global variable, and find it when i'm invoked anew.)

thanks for the continuing help. i now see light at the end of the tunnel.

best

denis



On Apr 21, 2005, at 5:55 PM, Rob Yepez wrote:

Hi denis,

Since you have already created the event source earlier, there is no need to make additional calls to createAsyncEventSource.  Doing so results in it returning back to you the original event source, which may be part of the problem.  I do notice that the IOHIDDeviceInterface does not maintain its own reference to the event source.  Therefore if you release the interface's eventsource manually and then attempt to call createAsyncEventSource again, you will be returned a freed object.  That's not good and is most certainly a bug, but hardly the end the of the world.

I'm assuming that you are maintaining a list of interfaces that corresponds to your list of eventSources and ready flags.  Just make sure to only create the event source at interface init time and to release it ONLY at interface destruction time.

One thing to keep in mind is that the HID Utilities is not supported API and that I DO NOT advocate its use.  For the most part it adds more moving pieces that can go wrong and make it harder for me to debug "real" issues.  If you can do without using it, I would highly recommend just using the HID Manager directly.

- Rob

P.S.
There is also no need to call setInterruptReportHandlerCallback a second time unless you are changing the callback being used.


On Apr 21, 2005, at 12:54 AM, Denis Pelli wrote:

dear rob

yes, you're right. If I call CFRunLoopRemoveSource instead of CFRunLoopSourceInvalidate then I can immediately re-enable the callback (by calling createAsyncEventSource, CFRunLoopAddSource, and setInterruptReportHandlerCallback). my test program toggled the callback on and off dozens of times in this way without any trouble. That's progress. thank you.

i'm still concerned about the other case. here i must stop the callback and delete the interface, because i'm about to be flushed. everything that i've tried so far leaves things in a damaged state so that when i subsequently call HIDBuildDeviceList and try to enable the callback my call to CFRunLoopAddSource crashes, as indicated below. (I've tried calling CFRunLoopSourceInvalidate or CFRunLoopRemoveSource or both, with exactly the same results.)

at present, once the user uses my extension and then flushes it, any second attempt to run it crashes. that's quite embarrassing.

how should i shut down the callback when i am about to delete the interface?

best

denis


On Apr 20, 2005, at 8:10 PM, Rob Yepez wrote:


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],myRunLoo pMode);
  error=(*interface)- >setInterruptReportHandlerCallback(interface,buffer,bufferSize,Report Callback,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],myRunLoo pMode);


***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));

>> _______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden

This email sent to email@hidden



Denis Pelli
Professor of Psychology and Neural Science
http://psych.nyu.edu/pelli/



_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/usb/email@hidden

This email sent to email@hidden
References: 
 >cancel setInterruptReportHandlerCallback? the crash is in CFRunLoopAddSource (From: Denis Pelli <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.