Haptix 1.31 crashes in Kernel32.dll

Discussion in 'HAPTIX' started by wlorenz65, Jul 9, 2016.

  1. This model file causes Haptix 1.31 to crash. It runs into an int3 instruction in Kernel32.dll. If I replace the -1 at line 33 column 113 by -.55, it works.
     

    Attached Files:

  2. Vikash Kumar

    Vikash Kumar Staff Member

    I was able to reproduce the bug. From the primary analysis, it looks like a bug in the box-box collision detection that triggers in this specific configuration of the boxes. I have marked the two boxes (red and green in the pictures) that trigger the bug. Disabling collision on either one of them seems to mitigate the crash, which further confirms that its a box-box collision bug.

    We will take a deeper look and keep you updated. Meanwhile, if you can afford to move the boxes a little bit apart or disable collision on one of them, that will mitigate the issue.

    PS: I have attached the file with the collision disabled on the red box.
    Capture.JPG Capturea.JPG
     

    Attached Files:

  3. Well, I was just moving the beam around trying to find its position so that the beams don't collide and stabilize the thread segments at the center. And then I found that I don't need beams at all ... just a few cubes 1 m apart, connected by black matter. I hadn't thought of that first, physics in MuJoCo is different from the real world. So you can let you time fixing that bug ...
     
  4. Emo Todorov

    Emo Todorov Administrator Staff Member

    Turns out the box-box collider is capable of returning more contact points than I had realized -- and so it was writing outside the pre-allocated memory buffer. This is in principle caught by the MuJoCo error handler, but in practice the compiler inserts some code to check for stack corruption and triggers a low-level error before the MuJoCo error handler gets a chance to complain...

    The bug is already fixed in the codebase. The fix will appear in release 1.40 (in a week?) In the meantime you can rearrange the boxes a bit to avoid this particular collision scenario. Alternatively you could enable the Boxconvex option, which replaces the box-box collider with a general-purpose convex collider returning only one contact point per geom pair; but then the lonely contact point will be running around trying to prevent penetration everywhere, making the simulation less stable.