segfault bei new bzw malloc



  • nunja wie schon der titel sagt Gibts dort manchmal nen segfault bei einem new auf ein grundlegenden datentyp?

    Ich weiss nicht ob das hier oder im linux forum besser aufgehoben ist. Ich glaube man kann mir da wohl nur helfen wenn jemand zufälligerweise den fehler schonmal hatte und weiss wo man hingreifen muss.

    Hier der Code den ich ausführe

    CByteBuffer::CByteBuffer( uint16_t s ) : writeinactive(0), readinactive(0), readingpos(0), writingpos(1), size( s ), wir( false )
    {
    
        try 
        {
            data = (unsigned char *)malloc(s); //<-- da crashts
        }
        catch ( ... )
        {
            std::cout<<"err on creating buffer"<<std::endl;
        }
    
        vlock = new pthread_mutex_t;
        if (pthread_mutex_init(vlock,NULL)) 
        {
    		std::cout << "Mutex couldn't get initialized... throwing exception!" << std::endl;
    		throw std::exception();
    	}    
    }
    

    Ich habs schon mit new und mit malloc probiert. Der constructor wird innerhalb eines constructors einer anderen klasse aufgerufen. Es gebt in beiden auch keine Virtuellen funktionen etc. Das einzige was ich sagen muss das die klassen innerhalb von Posix threads erzeugt werden. Vielleicht hängt es damit zusammen.



  • wie groß is den s?



  • 1000 also im grunde 1000 byte 😉 nicht so übermässig.



  • hmm das problem taucht nicht nur dort auf. Kann es sein das ein programm rumspinnt wenn zuviele new operationen auf einmal benutzt werden? Irgendwie macht das programm bei mehreren solcher new's macken. Hoffe mir kann da jemand helfen.



  • Vermutlich hast du dir vorher irgendwo durch einen Schreibzugriff über Arraygrenzen hinweg den Heap zerlegt.



  • hmmm mittlerweile hab ich bei allem was ich geändert habe am Source vor jedem schreibzugriff auf ein array sogar ein assert drinnen das mir abprüft ob die grenzen überschritten werden.... Aber selbst dort ist nie was passiert.



  • was heißt den:

    data = (unsigned char *)malloc(s); //<-- da crashts
    

    wird "err on creating buffer" ausgegeben?
    oder gibs 'nen core-dump?

    Wievile Threads haste am laufen?



  • am laufen sind hmmm gute Frage, ich denke zu der Zeit so an die 20 Threads. Der Crash kommt vor allem im GDB (Debugger) auch ohne aber dort lässt er länger auf sich warten 😉 das programm segfaultet halt einfach.



  • Ist data Threadsicher ?
    Den Lock sehe ich erst nach dem new - nicht das da mehrere Threads gleichzeitig mit data arbeiten wollen



  • ja der wird ja dort erstmal initialisiert.

    Das problem ist halt das es nicht nur diese stelle ist, sondern es hier besonders häuffig auftritt. 😞



  • Ich hab mit multithreading herzlich wenig erfahrung aber der gezeigte Quellcode lässt erst mal keinen Schluss auf falschen Zugriff einer Variablen zu (sofern uint16_t kein Zeiger oder referenz ist).

    Also bleibt eigentlich nurnoch :

    Probleme mit dem Threading
    oder

    Vermutlich hast du dir vorher irgendwo durch einen Schreibzugriff über Arraygrenzen hinweg den Heap zerlegt.

    weitere möglichkeiten wären imHo ggf. noch wildes rumschreiben innerhalb des eigenen Speicherbereiches. Prüfe mal ob alle Zeiger richtig Initialisiert sind vor Verwendung und bei einem delete auf 0 gesetzt werden.

    Wenn das alles gesichert ist, darf einer der Threading spezies nen Kommentar zu geben 🤡



  • Fedaykin schrieb:

    ja der wird ja dort erstmal initialisiert.

    Das problem ist halt das es nicht nur diese stelle ist, sondern es hier besonders häuffig auftritt. 😞

    Wo den noch?

    Köntest Du auch mal den Teil posten wo der ctor aufgerufen wird und wie Du die klasse wieder freigibs. Stack oder new?



  • also vielen vielen dank für die viele hilfe.... ich denke das problem hat sich dahingehend geklärt das es einfach am Multithreading lag. Irgendwie scheint beim abbrechen der Threads was in die hose gelaufen zu sein 😞 es scheint jetzt ganz gut zu klappen, hab zwar wieder neue probleme aber da will ich mich selber erstmal dran festbeissen und wenn ich so nicht weiterkomme nachfragen.


Log in to reply