Loading...
Logo
Processing Forum
hi processing community,
  i've seen this exception discussed before in the forum, but i think this is a unique situation?...

i'm exhibiting an interactive work and consistently getting a crash at ~4 hours into running my processing app. i'm using a kinect camera with shiffman's library to capture motion and optical flow to translate that movement into the system.  

the application is running on a brand new mac mini (Model: Macmini5,2, Intel Core i5, 2.5 GHz, 4 GB)  with lion and the latest installation of java, everything's updated.  it runs great and everything's perfect for the first 4 hours and then it just crashes with an unexpectedly quit message and the java error report of
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

i think the biggest hint is that in the previous version that i had working fine at 8hours+ i was using frameRate(30) in setup(), and now i'm not using frameRate() at all because it made the movement more fluid.  thought maybe this was causing a memory leak, but added in a
if (Runtime.getRuntime().freeMemory() < 10000000) {
    System.gc(); 
}
and it still crashed.  for people that get this error, how can you figure out what the problem is?
any ideas on what might be going on here?  i have the full error log if that helps.  thanks in advance...

Replies(5)

update... looks like this is a known issue with isochronous transfer frame scheduling problems?:


if you're looking for an easy answer, just run your sketch at frameRate(30).  i'm not running into the error on newer or older macs at 8hrs+ when i run things at this frame rate.

ok, so i'm still going with "Isochronous transfer error" in mac osX as the issue.  but now even at frameRate(30) i'm getting the crash at about 4hours 40minutes, which as you can imagine makes debugging a nightmare because i have to wait 5 hours to see if it's going to crash.

 someone posted a solution to a google group...

The best solution that I've found so far (which is hacky and may make those actually familiar with USB driver programming smack their foreheads), is to edit src/usb_libusb10.c in libfreenect to restart isochronous transfers that die.  After editing, it should read:

         FN_WARNING("Isochronous transfer error: %d ", xfer->status);
         libusb_submit_transfer(xfer);
         //strm->dead_xfers++;

 You'll still get error messages (unless you comment out the warning line, I suppose), and the framerate may be affected, but the streams will at least stop freezing up.

above quote taken from here

and i can find line in shiffman's github src code for the openkinect library here
https://github.com/shiffman/ libfreenect/blob/master/src/ usb_libusb10.c
or maybe it's better to use the one in the the  xcode project in the wrappers folder.

but i don't know how to rebuild his openkinect library and the basic processing library examples all use a build.xml file with ant in eclipse.  think somewhere shiffman said he's using eclipse to compile the library, but i'm not sure what files he's using or how to set it up in eclipse...  could someone  help me with this?  i've managed to rebuild the libKinect.jnilib file (i think) from the  xcode project in the wrappers folder, but not sure if just opening it in xcode and changing the couple lines and hitting build is the correct way to do it, and i'm not sure where to start for recreating the openkinect.jar file.  thanks
ok, now i think there's a memory leak in kinect.getRawDepth() . not sure if this happens on everyone's computer, but i'm seeing the leak even  when i just run the openkinect point cloud demo and getting the crash at about the same time interval (4h45m / 5 hrs).  i'm suspecting getRawDepth because i'm still seeing a memory leak when i comment out everything in the pointcloud demo except kinect.getRawDepth() .  figure this may be an issue with libfreenect?

in any case, i've also posted this as an issue to shiffman's github page: 

unfortunately, i don't know enough about the code that goes into the libfreenect library to figure this one out, but i'll keep you posted if i find something/somebody else fixes it.  

if someone runs into this issue trying to do an 8 hour + install prior to this bug being fixed, i set up a system that has processing quit the app every four hours (using a conditional statement testing the hour / minute / second and then restarting the app with cron. i.e processing app quits at 3:59:58 and cron opens it up again at 4:00:00,  not an ideal solution, but it'll do til this gets worked out  (thanks martyd for the cron help).
so i had a question about how i solved this, so here's more detail:
>note: this solution is for a mac<

step 01: write some script into your processing .app to shut down at certain intervals
step 02: use cron to start up your standalone app

step 01:
insert this into draw() somewhere... i have it at the end of the loop

Copy code
  1.  int h = hour();
  2.   int m = minute();
  3.   int s = second();
  4.   if ( (h == 3) && (m == 59) && (s == 58) ) {  //4am
  5.     robby.keyPress(KeyEvent.VK_ESCAPE);
  6.   }
  7.   else if ( (h == 7) && (m == 59) && (s == 58) ) {  //8am
  8.     robby.keyPress(KeyEvent.VK_ESCAPE);
  9.   }
  10. //etc...

i found i had errors quitting the standalone .app unless i used a robot to push the "esc" key.  you can learn more about using a robot from the processing wiki (which is where i got this portion of the code)... basically before setup you need


Copy code
  1. import java.awt.Robot;
  2. import java.awt.AWTException;
  3. import java.awt.event.InputEvent;
  4. Robot robby;

and in setup() you need

Copy code
  1. try
  2.   {
  3.     robby = new Robot();
  4.   }
  5.   catch (AWTException e)
  6.   {
  7.     println("Robot class not supported by your system!");
  8.     exit();
  9.   }

i also added the kinect.quit() command to the escape key press because i found sometimes the kinect would crash even if kinect.quit() was in void stop()

Copy code
  1. void keyPressed() {
  2.   switch(key) {
  3.       case 27:  //keycode 27 = esc
  4.           kinect.quit();
  5.           super.stop();
  6.           break;
  7.    }
  8. }


step 02: use cron to start up the program again
i used CronniX and two lines to start up the app at 4 and 8am should read something like

0      4      *      *      *      open /Users/Username/Desktop/yourP5app.app
0      8     *      *      *      open /Users/Username/Desktop/yourP5app.app

note, hours are 0-23, also remember to hit save in CronniX
in case anyone is having this issue, my solution was to switch to simple OpenNI (NITE wrapper for processing)... http://code.google.com/p/simple-openni/

don't seem to get this error with simple OpenNI... you lose some of the controls daniel's built into openkinect, but there are a number of nice new ones including skeletal tracking... and it seems to be the better option for running a sketch 4+ hours.