GDB przy ustawionym breakpointcie freezuje

Witam.

Generalnie jeżeli chodzi o GDB, to kiedyś działał bez zarzutu, teraz działa tylko w pewnych sytuacjach. Kiedy ustawie breakpointa na poszczególnych funkcjach dosłownie się "zawiesza". I przez "zawiesza się" mam na myśli to co napisałem w tytule tego wątku. To znaczy - GDB jako proces mogę tylko zabić z poziomu menadzera zadań (ksysguarda w moim przypadku, bo siedze na linuxie). Utrzymuje swoje zużcie procesora na 16-17%,ntach, i dostep do aplikacji odzyskuje tylko kiedy zabije gdb.

W wielu sytuacjach kiedy ustawiam breakpointa, wszystko jest ok, ale zauważyłem że kiedy ustawiam breakpoint na funkcjach renderujących różne grafiki, to w wielu przypadkach następuje ta sytuacja z freezem. Teraz dla testów ustawiłem breakpoint na funkcji RenderSprite(), za każdym razem mi na niej freezuje. Wiem, że znalazłbym też wiele podobnych funkcji.

Nie mam pojęcia jak to zdiagnozować, gdb jak freezuje to się zachowuje tak, jakby był w pętli nieskończonej, nie da się nic z nim zrobić, można go jedynie zabić.

Miał ktoś do czynienia z podobną sytuacją?
Wrzucam logi z gdb które znalazłem w /tmp/
Widać tam troche ścieżek do moich plików, i nazw różnych funkcji... ale chyba to przeżyje (http://pastebin.com/zW9fBANR)

wersja gdb - GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs

Dodam, że debuguje w netbeansie.

EDIT: Tak generalnie wygląda callstack wywołania tej funkcji:

Core::Core() ->
Core::Loop() ->
Graphics::DrawLoop() ->
Game::renderObjects() ->
Building::Render() -> (ta funkcja jest konkretyzowana w klasach Building, Ship dziedziczace po Entity)
EntityRender::RenderSprite() (Building dziedziczy po Entity, Entity dziedziczy po EntityRender)

Tak wygląda uproszczony model Buildingu (jest jeszcze Ship, Asteroid... ale pomińmy to)

class EntityProporties {
    public:
    int x;
    int y;
    sf::Sprite sprite;
    //......
}
class EntityRender : virtual public EntityProporties {
    public:    
    virtual void Render() = 0;
    void RenderSprite();
    //....
}
class EntityTransform : virtual public EntityProporties {//......}
class EntityActivity : virtual public EntityProporties {//......}

class Entity : public EntityTransform, public EntityRender, public EntityActivity, virtual public EntityProporties {
public:

//.....
}

class Building : Entity {
public:
    void Render();
//......
}

//....gdzies tam w pliku cpp
Building::Render() {
   RenderCostam1();
   RenderCostam2();
   //....
    RenderSprite();
   //....
}

A może gdb --args gdb gra? (:

A jesteś pewien ze wisi? Bo rozumiesz że instrumentacja przez gdb "kosztuje", prawda? Tzn kod pod debugerem działa wolniej, a w pewnych sytuacjach wyraźnie wolniej. Bardzo możliwe że masz właśnie taką sytuację, że twoje renderowanie normalnie śmiga szybko bo np. całe leci gdzieś na GPU, ale jak masz debuger włączony i próbkowanie wszystkich zmiennych i parametrów to niestety ale przestaje to być możliwe.
Eclipse CDT ma nakładkę na gdb i wydaje mi się że miała opcje "pauzowania" procesu, tzn debuger zatrzymuje od razu wykonanie i pokazuje ci w którym miejscu znajduje sie instruction pointer.

Testowałem teraz debugowanie przez konsole, jednak przez konsole na czysto działa. Ustawiam breakpoint, jest breakpoint. Tam gdzie mi się normalnie przez gdb netbeans crashuje. Tylko w netbeansie występuje ta głupia sytuacja. netbeans przesyła do gdb więcej komend niż ja (można zobaczyć sobie w logsach powyżej), może one mają na to jakiś wpływ?

nagrałem na szybko film żeby pokazać jak to wygląda, mam nadzieje że nie jest to w żaden sposób zabronione, a jeżeli jest to proszę moderatora o zlinczowanie.

Skoro jest to problem edytora to zmień edytor. Zobacz jak to wygląda np. pod Eclipse/QtCreator.

alagner napisał(a):

A. Napisz sobie skrypt do gdb.
B. Netbeans ma logowanie tego co przechodzi przez gdb (komendy, odpowiedzi itd.)? Jeśli tak: włącz i spróbuj odtworzyć to spod konsoli, gdzie ponoć działa. Może jakaś konkretna komenda robi Ci kuku.

....

Dawid90dd napisał(a):

Wrzucam logi z gdb które znalazłem w /tmp/
(...) (http://pastebin.com/zW9fBANR)

A co do tego by odworzyć to co netbeans robi.. to może być dobry pomysł, zaraz spróbuje.

alagner napisał(a):

BTW - jak ubijesz zwieszone IDE to gdb dalej "żyje"? To jest lokalny debug czy jakiś gdbserver, do którego możesz podpiąć się telnetem?

Nie wiem zielonego pojęcia co masz na myśli z tym "lokalnym debugiem", "telnetem" i "gdbserverem"...

Przeoczyłem loga, przepraszam :) Tak czy siak tam nie zajrzę, mamy w pracy dość mocno poblokowany internet.

W temacie gdb servera https://sourceware.org/gdb/onlinedocs/gdb/Server.html
Ale z tego co widzę na pierwszy rzut oka to raczej prosto wykonalne nie będzie.