Thanks for the great effort, David.
(1) The extension is not threaded, I mean I don’t create any threads myself or work in any way with threaded code. After compiling with /ML I had one crash, so this has not been the cause, like you explained. I am back to /ML now, to match the way Panda3D is compiled.
Anyway, I have put “compile Panda3D with thread support enabled” on my task list. This will be a good exercise for me. Probably some time after Panda3D 1.4.0 is out.
(2) I use OpenGL, so this is probably not the problem. But I do use single-precision throughout my extension code, and I work with LMatrix4f, LVector3f, LPoint3f. But I will try and first open the window first before doing any other stuff.
My problem is that I can not pin down the error. I didn’t get a crash for several hours now, and if it was crashing it was somewhere during the game loop (hmm… don’t know how to express this right. I mean: not right after loading/starting the game, but after some minutes of game play).
The only thing I know is that it is related to my character controller code. Some parts of the controller work dynamically (e.g. gravity), while other parts work kinematically (e.g. turn or horizontal movement, where forces get applied each frame which are computed from “desired velocity/omega”).
One observation has been that crashes happen only if running without “sync-video 1”. My character turn code is based on mouse movement:
md = base.win.getPointer( 0 )
x = md.getX( )
y = md.getY( )
if base.win.movePointer( 0, self.centerX, self.centerY ):
dx = x - self.centerX
dy = y - self.centerY
else:
dx = 0
dy = 0If synced I get something like this for dx (small mouse movement to the side):
0
0
1
3
7
11
15
14
11
7
3
1
0
0If not sync-ed, and running at several hundred fps, I get something like this (several lines of “0” omitted to make it readable):
0
0
0
0
1 <--
0
0
0
0
3 <--
0
0
0
0
7 <--
0
0
0
11 <--
0
0
...It seems the mouse pointer position gets updated not once a Panda3D-frame, but once every 1/60 secs (or whatever screen refresh rate is ???).
Since the torque applied to the player body is computed from dx, this means that the player turns in a “stutter” way. Maybe the forces and torques simply get too big this way, and the code becomes numerical instable, resulting in NaN/Inf values for the transform matrix.
I will try to average the mouse movement, and see if I get rid of my problem 
Whatever the problem is, I first have to track it down in my code, during the next weeks. I will report back once I can say something more solid. Thank you again for the effort.
enn0x