[ocaml-ctypes] Spinning process on osx

[Daniel Bünzli]

Le lundi, 17 février 2014 à 10:43, Jeremy Yallop a écrit :
> Let me know if this fixes things, and I'll push 0.2.3 to the main
> opam-repository.


Thanks for looking into that ! So, there is some good news and bad news. I think we were facing two separate issues in this discussion.  

The good news is that I confirm the examples I gave and other tsdl programs I have do now survive more than 20s and don't show any bug occuring in ctypes_call. That's already a huge step since it actually allows me to use tsdl/tgsl on osx and I think you should already push that fix.

The bad news is that my initial report, as the title of the thread indicates, was about a spinning process. And the working tsdl programs I mention above while they work, can't be exited when compiled with 4.01.0, they end up spinning, taking 100% cpu time, in that unwind thing.  

For that my analysis about 4.00.1 vs 4.01.0 and the bissect to ocaml's b2636c22d55b15f55a02b3 still holds. A mildly good news (since I don't really understand what I'm doing) is that if I use my switch that applies this patch to 4.01.0:

  https://gist.github.com/dbuenzli/9050340

the programs do not spin on exit. The smallest repro case I have for now is here:

  https://gist.github.com/dbuenzli/9050445

If there is no bug, this program exits immediately otherwise it spins [1]. It should be noted that the bug still has a very heisenbug nature --- which make me nervously wonder if it could still not suddenly show up on 4.00.1 or on 4.01.0 with my patch. For example if I remove the useless `video` addition of line:

  https://gist.github.com/dbuenzli/9050445#file-spin-ml-L29

which equates to ctypes's Unsigned.UInt32.logor, see:

  https://github.com/dbuenzli/tsdl/blob/a3ee691e75ef0635ee4304732aeae53f8352b4b7/src/tsdl.ml#L178

the spin doesn't occur. Trying to remove any other instruction, like the useless call to Sdl.get_event_state followed by the match, to make the test case smaller also make the spin disappear.  

Finally it should also be noted that the spin occurs in the call to Sdl.pump_events before all the other calls so I don't think it's a case of buggy bindings.

Best,

Daniel


[1] It spins in there:

> lldb spin.native  
Current executable set to 'spin.native' (x86_64).
(lldb) run
Process 39079 launched: '/Users/dbuenzli/bug/spin.native' (x86_64)
Pump...
Process 39079 stopped
* thread #1: tid = 0x3b2271, 0x00007fff8f27a334 libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getSavedRegister(libunwind::LocalAddressSpace&, libunwind::Registers_x86_64 const&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::RegisterLocation const&), queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
frame #0: 0x00007fff8f27a334 libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getSavedRegister(libunwind::LocalAddressSpace&, libunwind::Registers_x86_64 const&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::RegisterLocation const&)
libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getSavedRegister(libunwind::LocalAddressSpace&, libunwind::Registers_x86_64 const&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::RegisterLocation const&):
-> 0x7fff8f27a334: pushq %rbp
0x7fff8f27a335: movq %rsp, %rbp
0x7fff8f27a338: movq %rcx, %rax
0x7fff8f27a33b: movq %rdx, %rcx
(lldb) bt
* thread #1: tid = 0x3b2271, 0x00007fff8f27a334 libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getSavedRegister(libunwind::LocalAddressSpace&, libunwind::Registers_x86_64 const&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::RegisterLocation const&), queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
frame #0: 0x00007fff8f27a334 libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getSavedRegister(libunwind::LocalAddressSpace&, libunwind::Registers_x86_64 const&, unsigned long long, libunwind::CFI_Parser<libunwind::LocalAddressSpace>::RegisterLocation const&)
frame #1: 0x00007fff8f27a07b libunwind.dylib`libunwind::DwarfInstructions<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long long, unsigned long long, libunwind::Registers_x86_64&) + 287
frame #2: 0x00007fff8f277538 libunwind.dylib`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() + 100
frame #3: 0x00007fff916e37af libobjc.A.dylib`objc_addExceptionHandler + 79
frame #4: 0x00007fff8d6c5c6c CoreFoundation`_CFDoExceptionOperation + 380
frame #5: 0x00007fff888ea24c AppKit`_NSAppKitLock + 77
frame #6: 0x00007fff888a77f7 AppKit`NSAccessibilityPostNotificationWithUserInfo + 70
frame #7: 0x00007fff889c88db AppKit`-[NSApplication sendEvent:] + 2328
frame #8: 0x0000000100244b84 libSDL2-2.0.0.dylib`Cocoa_PumpEvents + 171
frame #9: 0x00000001001eca3e libSDL2-2.0.0.dylib`SDL_PumpEvents + 23
frame #10: 0x0000000100299124 libffi.6.dylib`ffi_call_unix64 + 76
frame #11: 0x00000001002989f6 libffi.6.dylib`ffi_call + 854
frame #12: 0x0000000100076ad2 spin.native`ctypes_call + 434
frame #13: 0x000000010003ab5c spin.native`.L139 + 24