Bin kein Programmierer, aber versucht doch einfach mal statt readlock zum Ursache finden die Channels zu duplizieren so dass jeder Thread seine eigene Kopie hat. Dann kann es ja keine doppelten Zugriffe mehr geben. Ist nur zum Fehler ausschließen, nicht für später.
Die Kanalliste "gehört" dem VDR, um die lesen zu dürfen muss man sich einen readlock holen, sonst ist Chaos vorprogrammiert.
Da sowohl die originale Variante, als auch die wirbel, als auch meine, das exakt gleich Verhalten zeigen, wird es am readlock selber wohl eher nicht liegen.
Man könnte testweise den VDR so modifizieren, dass nur ein Thread readlock auf die Channels gewährt bekommt, das müsste vergleichbar einfach machbar sein.
So würde dann nur noch einer der VNSI-Plugin-Threads gleichzeitig laufen.
Die Änderung würde einiges durcheinander werfen, was das gesamte Timing im VDR betrifft. Unter Umständen geht damit dann gar nichts mehr.
[...] (war doppelt)
writing 1 byte into .... und cc1plus : dest... is likely at address zero.
geben diese compiler Warnungen nicht Hinweise auf das Fehlverhalten?
Leider nicht.
Das ist auch an einer völlig anderen Stelle, der Code wird hier gar nicht verwendet.
ich hab jetzt mal mit -O0 übersetzt, dann gibt es bei mir auch keine warnings ebenso keine mit
-Wno-stringop-overflow
. Es crasht dennoch:
Dass es mit der Optimierung zu tun hat, habe ich schon öfters gelesen.
Vermutlich liegt es am am inlinen, das dürfte -O0 nicht machen.
Die Warnung ist aber generell wohl fehlerhaft, wenn man den GCC-Entwicklern trauen kann.
(Siehe Link in #69.) Die sind sich da auch einig, dass man die Warnung entfernen will.
Kann also gut sein, dass man das inzwischen gemacht hat und Warnung ab GCC Version 12.5 oder 12.6 verschwunden ist.
Generell ist dieses Konstrukt aber eher speziell (leerer Constructor dafür eine Initialisierungsliste), einen auffälligen Fehler sehe ich aber nicht.
Man könnte mal versuchen die Reihenfolge in der Initialisierungsliste zu tauschen, vielleicht bringt das was. Patch im Anhang.(Entfernt, da es nicht funktioniert hat!)
#1 0x00007f9fe0041176 __GI_raise (libc.so.6 + 0x41176)
#2 0x00007f9fe0028917 __GI_abort (libc.so.6 + 0x28917)
heißt aber AFAIK, dass das geplant aborted wurde, also dass ggf. das kaputt ist, was in den vasprintf gesteckt wurde.
Prinzipiell richtig, nur kommen die Meldung vom *alloc() nicht vasprintf(), wie wirbel auch schon geschrieben hat.
Der Beitrag hat mich veranlasst mir endlich mal malloc() näher anzusehen, das hätte ich früher tun sollen...
Die Fehlermeldung malloc(): unaligned tcache chunk detected kommt von hier: malloc.c:3183
Wie man unschwer sieht, kommt die, wenn mit dem Zeiger auf den Speicherbereich etwas nicht stimmt.
Nach dem "Durchklicken" einiger der Links, sieht es mir so aus, als ob das beim anfordern eines neuen Speicherblocks passiert und die Safe-Linking Pointer Protection anschlägt.
100% sicher bin ich da zwar nicht, die Ursache müsste aber immer sein, dass jemand ausserhalb seines angeforderten Speichers etwas geschrieben hat.
Der Tcache enthält kürzlich freigegebene Blöcke und ist Thread bezogen, jeder hat seinen eigenen.
Ob man daraus aber schlussfolgern kann, dass der Übeltäter im gleichen Thread sitzt, bin ich nicht sicher.
Wenn man nach "tcache" sucht findet man, dass es auch Attacken darauf gibt.
Ich denke, unser Fehler besteht schon lange, fällt aber erst jetzt durch eine neu eingeführte Abwehrmaßnahme auf.
Primär verdächtig ist alles was mit dynamischer Speicherverwaltung (malloc() und Co.) zu tun hat.
Die Funktionen von cResponsePacket machen das dauernd.
Ich habe da mal etwas Puffer eingebaut und hole den Speicher in größeren Blöcken. Das löst das Problem zwar nicht, sollte die Wahrscheinlichkeit für einen Crash aber senken.
Wenn es mit den Patch besser wird, weiß man also wenigstens, wo man suchen muss.
.
.
)
.
:
.