Threading, Unerklärlicher Crash, CFRunLoop?

  • Threading, Unerklärlicher Crash, CFRunLoop?

    Meine Kamera-Lib ist jetzt langsam wirklich brauchbar. Darum habe ich jetzt ein Framework draus gebastelt, was ich jetzt erstmals aus einer Cocoa-Anwendung verwenden möchte.
    Eine Testanwendung in C++ (mit OpenCV zum Darstellen der Bilder) funktioniert einwandfrei (mit einer dylib, noch kein Framework dafür, da sollte aber nix falsch sein, Code ist der Gleiche).

    In Cocoa habe ich jetzt eine Anwendung mit einem "CapView" NSView, welches meine Kamera-Klasse im initWithFrame: instanziiert und das Capturing startet. Den NSLogs zufolge klappt das auch erwartungsgemäß problemlos.

    Vorerst hole ich die Bilder jetzt nicht ab, und stell sie auch nicht dar. In meiner C++ Testanwendung kann ich das auch so machen, kein Problem.

    Nach wenigen (Milli?) Sekunden stürzt meine Cocoa-Anwendung jetzt aber in den gdb, und bringt mir keinerlei Begründung dafür. Ein paar Ausschnitte aus dem gdb:

    Quellcode

    1. (gdb) info threads
    2. 3 process 4905 thread 0x3703 0x968f5b6c in __semwait_signal ()
    3. 2 process 4905 thread 0x3137 0x00000000 in ?? ()
    4. * 1 process 4905 thread 0x10b 0x968ef158 in mach_msg_trap ()
    5. (gdb) bt
    6. #0 0x968ef158 in mach_msg_trap ()
    7. #1 0x968f6080 in mach_msg ()
    8. #2 0x90981558 in CFRunLoopRunSpecific ()
    9. #3 0x93c19bc8 in RunCurrentEventLoopInMode ()
    10. #4 0x93c199ec in ReceiveNextEventCommon ()
    11. #5 0x93c1982c in BlockUntilNextEventMatchingListInMode ()
    12. #6 0x92023728 in _DPSNextEvent ()
    13. #7 0x920230e0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
    14. #8 0x9201cd9c in -[NSApplication run] ()
    15. #9 0x91fed7a0 in NSApplicationMain ()
    16. #10 0x000025fc in main (argc=1, argv=0xbffff550) at /Volumes/E/code/svn.ioctl.eu/_UVC_/UVCCap/main.m:13
    17. (gdb) thread 2
    18. [Switching to thread 2 (process 4905 thread 0x3137)]
    19. 0x00000000 in ?? ()
    20. (gdb) bt
    21. #0 0x00000000 in ?? ()
    22. (gdb) thread 3
    23. [Switching to thread 3 (process 4905 thread 0x3703)]
    24. 0x968f5b6c in __semwait_signal ()
    25. (gdb) bt
    26. #0 0x968f5b6c in __semwait_signal ()
    27. #1 0x969323d0 in _pthread_cond_wait ()
    28. #2 0x0003b6a8 in usb::isoch_transfer::wait_for_data (this=0x12ef50) at /Volumes/E/code/svn.ioctl.eu/_UVC_/uvc/src/usb_isoch.cpp:190
    29. #3 0x0004bf64 in uvc::decode_frame::worker_func (vme=0x12fc50) at /Volumes/E/code/svn.ioctl.eu/_UVC_/uvc/src/uvc_decode_frame.cpp:114
    30. #4 0x96931028 in _pthread_start ()
    Alles anzeigen

    Hier scheint diesmal "Thread 2" im nirgendwo zu liegen, kann ich mir grad auch nicht erklären.
    Pthreads zum erzeugen von Threads + CFRunLoop sollte doch keine Probleme erzeugen, oder? Im C++ klappt das ja. Irgendwie hab ich das Gefühl, dass es sich mit dem Cocoa RunLoop beisst.

    Irgendwer irgendwelche Ideen?

    Ich versuche mal, ob ich herausfinden kann, welcher Thread da NULL ist, und warum. Muss ich bei Cocoa + pthreads + CFRunLoop irgendwie generell noch etwas beachten, was ich bei reinem C++ nicht muss?
    ♥C++

  • RE: Threading, Unerklärlicher Crash, CFRunLoop?

    Merkwürdig: Der zweite Thread is jetzt auch immer korrekt und nicht mehr NULL.

    Quellcode

    1. (gdb) info breakpoints
    2. No breakpoints or watchpoints.
    3. (gdb) info threads
    4. 3 process 5408 thread 0x3703 0x968f5b6c in __semwait_signal ()
    5. 2 process 5408 thread 0x3137 0x93f49918 in IODispatchCalloutFromCFMessage ()
    6. * 1 process 5408 thread 0x10b 0x968ef158 in mach_msg_trap ()


    Wenn ich einfach "continue" mache scheint erstmal alles ohne zu murren zu laufen (ausser, dass sich meine Lib beschwert, dass sie Videoframes verlohren hat, das is ja aber verständlich...)
    ♥C++

  • RE: Threading, Unerklärlicher Crash, CFRunLoop?

    Ok, scheint sich vorerst erledigt zu haben:
    1. Ich bin gdb aus Xcode raus nicht gewohnt. Wenn ich direkt im gdb starte (Apfel-Y), bekomm ich sinnvollere ergebnisse
    2. Finde dadurch ein EXC_BAD_ACCESS in meinem Code, dem muss ich erstmal nachgehen. Keine Ahnung, warum das erst jetzt auftritt...
    ♥C++