malloc: *** error for object 0x143604: incorrect checksum for freed object

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • malloc: *** error for object 0x143604: incorrect checksum for freed object

    Ich bin echt verzeifelt, ich bekomme andauernd soetwas wie
    malloc: *** error for object 0x143604: incorrect checksum for freed object - object was probably modified after being freed.
    oder auch ganz fiese Sachen wie EXC_BAD_INSTRUCTION

    Multithreaded Anwendung, Framework mit pthreads, Cocoa Anwendung.
    Die Cocoa Anwendung scheint ersteinmal keine grösseren Fehler zu haben, und läuft problemlos. Wenn ich jetzt im Framework
    (mein UVC Webcam-Treiber...) das Streaming starte und wieder stoppe, sollte ich wieder den ursprünglichen Zustand haben,
    aber ich bekomme eben solche Fehler.
    Die treten auf mit Objekten und in Threads, die eigentlich nichts mit dem Framework zu tun haben, also bspw. in irgendwelchen
    Apple-internen NSView und NSWindow funktionen.

    Ich spekuliere jetzt, dass hier irgendwelche Dinge überschrieben werden, irgendwelche RunLoops sich nicht vertragen oder sonst
    etwas.
    Instruments kann mir nicht helfen.
    Valgrind nennt mir auch keine Fehler.
    Dieses tolle Tool von Intel gibt es nicht für den Mac (und wird es wohl auch nicht geben...)

    Hat jemand noch irgendeine Idee, wie ich das Debugging besser angehen kann? Code hier pasten hat wenig Sinn, ich wills auch
    solange es nicht stabil ist, nicht ins SVN einchecken. Aber bei Interesse gerne ;)
    ♥C++

  • Chris schrieb:

    free() auf einer nicht initialisierten Variablen? Oder auf einem incrementiertem Pointer? Kenn das aus eigener Erfahrung.

    Läuft Valgrind mittlerweile auf OS X?

    Chris

    Das free() kommt mit hoher Sicherheit nicht von mir persönlich. Ich hab das Gefühl, dass es irgendein autorelease ist von irgendeinem NSInterneDünneLinieImFenster. Und halt das etwas überschrieben wurde. 0x143604 gehört zwar in mein Addresspace, aber keine Ahnung. Jemand eine Idee, wie ich herausfinden kann, wem das gehört? Kann man Instruments o.ä. sagen "Halt an, sobald jemand Speicher bei 0x143604 fordert"?

    Ansonsten: Valgrind scheint ganz gut zu laufen! Er hat nur andauern Fehler genannt "Conditional Jump depends on uninitialized value", was merkwürdig war, weil in dem genannten Abschnitt/Funktion definitiv keine uninitialisierte Variable war (es sei denn, gcc hat Mist gebaut). Der Fehler kam dann aber noch bei 100000 Apple-Library-Funktionen, auf die ich keinen Einfluss habe, darum habe ich die Meldungen deaktiviert...
    ♥C++

  • MallocStackLogging ist echt schön. Jetzt kann ich schauen, wo dieses Objekt alloziiert wurde, was jetzt angeblich eine incorrect checksum hat:

    Quellcode

    1. $ MallocStackLogging=1 ./build/Debug/UVCCap.app/Contents/MacOS/UVCCap
    2. ...
    3. UVCCap(26586,0xa0012500) malloc: *** error for object 0x423e34: incorrect checksum for freed object - object was probably modified after being freed


    anderes Fenster

    Quellcode

    1. $ malloc_history 26586 0x423e34
    2. ...
    3. ALLOC 0x423e30-0x423f07 [size=216]: thread_a0012500 |start | main | NSApplicationMain | -[NSApplication run] | -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] | _DPSNextEvent | BlockUntilNextEventMatchingListInMode | ReceiveNextEventCommon | RunCurrentEventLoopInMode | CFRunLoopRunInMode | CFRunLoopRunSpecific | __CFRunLoopRun | __CFRunLoopDoObservers | _handleWindowNeedsDisplay | -[NSWindow displayIfNeeded] | -[NSView displayIfNeeded] | -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] | -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] | -[NSView _drawRect:clip:] | -[NSControl drawRect:] | -[NSTextFieldCell drawWithFrame:inView:] | -[NSTextFieldCell drawInteriorWithFrame:inView:] | _NSDrawTextCell | _NSStringDrawingCore | -[NSLineFragmentRenderingContext drawAtPoint:inContext:] | CGContextShowGlyphsWithAdvances | draw_glyphs | ripc_DrawGlyphs | ripc_RenderGlyphs | CGGlyphLockLockGlyphBitmaps | create_missing_bitmaps | CGFontCreateGlyphBitmap8 | CGGlyphBitmapCreate | calloc | malloc_zone_calloc
    4. ----
    5. FREE 0x423e30-0x423f07 [size=216]: thread_a0012500 |start | main | NSApplicationMain | -[NSApplication run] | -[NSApplication sendEvent:] | CGFontCacheReset | CGFontStrikeRelease | free


    Was habe ich mit CGGlyphBitmapCreate zu schaffen? NICHTS. Bringt mich also auch nicht wirklich weiter...
    ♥C++

  • zerm schrieb:

    Was habe ich mit CGGlyphBitmapCreate zu schaffen?

    Im Zweifel malst du in irgend ein View irgend einen Text.
    Liest sich für mich nach nem dangling pointer.

    Entspricht dein UVC-Framework denn den Framework-Guidelines von Apple?
    Wenn du ohne dieses keine Probleme hast, kann es ja eigentlich nur daran liegen...
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • hertzchen schrieb:

    ist die View oder das Fenster oder was auch immer in dem Moment denn überhaupt noch 'vorhanden'?

    ich hatte das mal bei einem 'Dokument' nach dem Schließen, weil ich es nicht ordentlich 'aufgeräumt' habe

    Mhh, ja, ich überlege, ob es sowas sein könnte.
    Ich habe vorher ein Fenster zu gemacht, das beendet das Streaming.

    Funktioniert aber alles, wenn ich das Streaming nicht benutze, darum bin ich mir nicht ganz sicher......
    ♥C++

  • zerm schrieb:

    hertzchen schrieb:

    ist die View oder das Fenster oder was auch immer in dem Moment denn überhaupt noch 'vorhanden'?

    ich hatte das mal bei einem 'Dokument' nach dem Schließen, weil ich es nicht ordentlich 'aufgeräumt' habe

    Mhh, ja, ich überlege, ob es sowas sein könnte.
    Ich habe vorher ein Fenster zu gemacht, das beendet das Streaming.

    Funktioniert aber alles, wenn ich das Streaming nicht benutze, darum bin ich mir nicht ganz sicher......
    hast du da noch irgendwelche 'Notifications' oder 'Timer' am Laufen?
    Warum Boshaftigkeit unterstellen, wenn Unvermögen als Erklärung vollkommen ausreicht.

  • Chris schrieb:

    Mit CGGlyphBitmapCreate wird das nicht zu tun haben. Irgendwo schreibst über Bereichsgrenzen.

    Ja, wahrscheinlich. Ich verändere ja Speicher, der von CGGlyphBitmapCreate angelegt wurde. Also bin ich auch ganz schön ab vom Schuss....(das ist ja schon ein off-by-10000 oder so...)
    Guard Pages muss ich noch einmal probieren, aber wenn Valgrind schon nichts findet....

    hertzchen schrieb:

    hast du da noch irgendwelche 'Notifications' oder 'Timer' am Laufen?

    Ja, die habe ich aber alle invalidated und released...

    Ich habe jetzt nochmal überlegt, und glaube, mein pthread-threading-code ist mehr als ungünstig, und daher auch schwer zu warten/debuggen. Ausserdem benutze ich, wie ich glaube, conditions falsch. Ich stell das mal alles um, vielleicht hängt es ja damit zusammen. Solche Fehler treten halt immer in den komischten Gestalten an den seltsamsten Enden auf, und manchmal auch gar nicht...
    ♥C++

  • So, jetzt läuft es erst einmal viel robuster.

    Ich konnte jetzt auch einen der Übeltäter ausfindig machen:
    Ich habe USB Callbacks, die an das System gehen, so für die einzelnen USB Packete, wenn die eintrudeln. Jetzt scheint es so, dass das aller letzte Packet, was ich schicke und bevor ich abbreche eben niemals seinen Callback auslöst.
    Bisher habe ich das Packet am Ende einfach gelöscht.
    Es scheint aber, als würde irgendwann irgendwer auf die Idee kommen, mit dem Speicher vom Packet noch etwas anfangen zu wollen. Und das geht dann ordentlich schief. Eventuell will auch jemand das Päckchen noch zustellen, aber der RunLoop ist schon weg. Sehr merkwürdig.

    Das Päckchen am leben zu lassen bedeutet jetzt prinzipiell ein Leak, aber...komisch, so ist es deutlich stabiler.

    EDIT
    Hahaha, irgendwann kommen diese "Zombie" Päckchen sogar nochmal. Obwohl der RunLoop dann ein ganz anderer ist. Schöne Sache. Ich schiebs auf Apple bis mir etwas besseres einfällt :P
    ♥C++

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zerm ()

  • zerm schrieb:

    So, jetzt läuft es erst einmal viel robuster.

    Ich konnte jetzt auch einen der Übeltäter ausfindig machen:
    Ich habe USB Callbacks, die an das System gehen, so für die einzelnen USB Packete, wenn die eintrudeln. Jetzt scheint es so, dass das aller letzte Packet, was ich schicke und bevor ich abbreche eben niemals seinen Callback auslöst.
    Bisher habe ich das Packet am Ende einfach gelöscht.
    Es scheint aber, als würde irgendwann irgendwer auf die Idee kommen, mit dem Speicher vom Packet noch etwas anfangen zu wollen. Und das geht dann ordentlich schief. Eventuell will auch jemand das Päckchen noch zustellen, aber der RunLoop ist schon weg. Sehr merkwürdig.

    Das Päckchen am leben zu lassen bedeutet jetzt prinzipiell ein Leak, aber...komisch, so ist es deutlich stabiler.

    EDIT
    Hahaha, irgendwann kommen diese "Zombie" Päckchen sogar nochmal. Obwohl der RunLoop dann ein ganz anderer ist. Schöne Sache. Ich schiebs auf Apple bis mir etwas besseres einfällt :P

    Schickst du kein AbortPipe()? Danach sollten sie sofort kommen.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.