4. gdb zu sensibel?

gdb zu sensibel?

  • F

    ich nutze GDB zum debuggen nun hab ich aber mitbekommen das der wohl zu sensibel ist? Er wirft mir segfaults an wildesten stellen um die ohren wo die anwendung wenn sie real läuft niemals segfaultet. Ist der so? Kann man da was dran drehen das er das ganze besser macht?

    0
  • N

    Normalerweise sollte Deine Anwendung im gdb keine segfaults produzieren, wenn alles in Ordnung ist. Sieh Dir die entsprechenden Stellen lieber mal ganz genau an, könnte gut sein, dass Dein Programm "normalerweise" nur zufällig nicht abschmiert.

    0
  • F

    ok da werd ich wohl mal so nach und nach hier posten was er anmeckert und was ich selber nicht irgendwie zu beheben bekomme.

    Ggf kann man mir hier tipps geben auf was ich zu achten habe etc.

    erstes problem

    void * CReceiver::receive_loop( CReceiver * receiver )
{
            receiver->recvOK = true;
            //create waittime struct so the thread waits for 20 ms 
            timespec waittime; 
            waittime.tv_sec = 0;
            waittime.tv_nsec = 50000000; //20 ms;

            //stores how often the data can't be stored in the buffer
            //if this number to large the server seems to be crashed and the 
            //connection will be canceled
            receiver->setrlrunning( true );
            //pthread_cleanup_push(pthread_mutex_unlock,(void*)&receiver->bufferMutex);
            while ( receiver->getrlrunning() )
            {
                //there is space in the buffer
                if ( receiver->buffer->getNumberToWrite() > 0 && receiver->connection->online)
                {
                        //last buffer saved so we can receive new data
                        int count = 0;
                        try
                        {
                            count = recv( receiver->connection->m_read_socket, receiver->buffer->getWritingPos(), receiver->buffer->getNumberToWrite(),MSG_NOSIGNAL);
                            pthread_testcancel();
                            pthread_mutex_lock( &receiver->bufferMutex );
                            receiver->buffer->bytesWritten( count );
                            pthread_mutex_unlock( &receiver->bufferMutex );
                        }
                        catch ( std::exception const &e )
                        {
                            std::cerr<<"error in reive loop: "<<e.what()<<std::endl;
                        }
                        if ( count < 1 )
                        {
                            try
                            {
                                std::cout<<"count < 1 closing connection!"<<std::endl;
                                if ( receiver->connection->online)receiver->connection->closeConnection();
                            }
                            catch ( std::exception const &e )
                            {
                                std::cerr<<e.what()<<std::endl;
                            }
                            catch (...) {} 
                        }

                }
                else
                {
                    if ( receiver->buffer->writeinactive > 100 )
                    {
                        receiver->connection->closeConnection();
                    }
                    try
                    {
                        nanosleep(&waittime,NULL);

                    }
                    catch ( std::exception e )
                    {
                    }
                    pthread_testcancel();
                }

            }
            try
            {
                std::cout<<"receiver end!"<<std::endl;
            }
            catch( std::exception const &e )
            {
                std::cerr<<e.what()<<std::endl;
            }
            catch (...) {} 
            //pthread_cleanup_pop( 0 );

            receiver->recvOK = false;
            pthread_exit( 0 );
            return NULL;
}

    es wird die zeile

    std::cout<<"receiver end!"<<std::endl;

    angemeckert. Das ist eine Thread funktion die eigentlich mit pthread_cancel gestoppt werden soll. Das geschieht nun im destructor der thread klasse.

    folgende gdb meldungen kommen:

    #0  0xb7c0183b in raise () from /lib/tls/libc.so.6
#1  0xb7c02fa2 in abort () from /lib/tls/libc.so.6
#2  0xb7fde2f8 in unwind_cleanup () from /lib/tls/libpthread.so.0
#3  0xb7d12b08 in _Unwind_DeleteException () from /lib/libgcc_s.so.1
#4  0xb7dca100 in __cxa_end_catch () from /usr/lib/libstdc++.so.5
#5  0xb7daea9f in std::ostream::flush () from /usr/lib/libstdc++.so.5
#6  0xb7daef7f in std::flush<char, std::char_traits<char> > () from /usr/lib/libstdc++.so.5
#7  0xb7daef1a in std::endl<char, std::char_traits<char> > () from /usr/lib/libstdc++.so.5
#8  0xb7dad56f in std::ostream::operator<< () from /usr/lib/libstdc++.so.5
#9  0x0820cf7f in CReceiver::receive_loop (receiver=0x12ca2280) at netinterface/CReceiver.cpp:335

    es fehlen noch zwei stackrahmen aber das ist ja eh wurscht das ist nur das thread_create und so.

    Und dort gleich noch ne andere frage. Wie kann ich jetzt in einen anderen thread umschalten und schauen wo genau er dort gerade am werkeln ist?

    0
  • R

    mit t oder so kannst du umschalten. Siehe im GDB Handbuch.

    Ansonsten können natürlich Segfaults fliegen, wenn du irgend wo etwas komplett falsch machst. zB Wenn du den Heap zerstörst. Vielleicht hilft dir Valgrind weiter, den Fehler zu finden.

    0
  • F

    hmm vielleicht kan man mir zu dem oben noch weiterhelfen ich versuche gerade valgrind zu installieren, hab aber auf dem server keine SU rechte versuch also die pfade etwas an zu passen aber das ist erstmal nicht die frage. Wie schon gesagt das problem oben ist noch offen.

    0
  • F

    hier mal noch nen querverweis zu einem anderen problem wo die komplette klasse mit als Quelltext angegeben wurde.

    http://www.c-plusplus.net/forum/viewtopic-var-t-is-172467.html

    Nur falls jemand mehr infos als die schnipselchen braucht.

    0
  • F

    ein problem konnte ich nun klären, das mit Exception not rethrown. Dazu gibts nen artikel

    http://groups.google.com/group/comp.programming.threads/browse_thread/thread/652bcf186fbbf697/f63757846514e5e5

    Aber nun kommen die nächsten probleme.

    grundsätzlich segfaultet er nun im gdb des öfteren bei ganz einfachen new operationen???

    CPlayer * newPlayer = new CPlayer(Connection);

    und das versteh ich nun überhaupt nicht.
    Wenns probleme im Constructor gibt sollte er da nicht auf den verweisen? der stackframe ist hier

    #0 0xb7c4c0a1 in mallopt () from /lib/tls/libc.so.6
    #1 0xb7c4b8fb in mallopt () from /lib/tls/libc.so.6
    #2 0xb7c4ac43 in malloc () from /lib/tls/libc.so.6
    #3 0xb7dcb2fe in operator new () from /usr/lib/libstdc++.so.5
    #4 0x08123cea in main (argc=2, argv=0xbfffddf4) at main.cpp:198

    0
Anmelden zum Antworten