<![CDATA[hilferuf debugging]]>also, ich weiss nicht was ich mir hier jetzt erhoffe ggf nen dummen zufall das jemand spontan weiss was hier vorliegen könnte. Bzw irgend nen anhaltspunkt hat.
Ich programmiere seit ca 3 Jahren nun an einen online rollenspiel mit. In letzter Zeit wurden größere änderungen gemacht (inklusive compiler update etc also nicht nur reine Quelltextänderungen) ebenso mussten bestimmte codeteile komplett neu geschrieben werden. Auf alle fälle haben wir nun seit ca 1 Monat gehäuft segfaults an unerklärlichen stellen, erstaunlicherweise aber fast immer an der selben codestelle die an für sich nicht fehlerhaft sein dürfte. Wir haben schon mit diversen debuggern etc versucht den Fehler zu finden, nichts hat bisher wirklich geholfen. Ich greiffe zur Zeit auch nach jeden strohhalm der sich finden lässt. Vielleicht kennt jemand noch gute tools um dem problem etwas auf den grund zu gehen.

hier mal eine typische gdb ausgabe:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222689872 (LWP 15642)]
0x09464710 in ?? ()
(gdb) backtrace
#0 0x09464710 in ?? ()
#1 0x08058422 in boost::detail::sp_counted_base::release (this=0x94a57a0)
at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145
#2 0x0805845a in ~shared_count (this=0xb71f2dd0) at /usr/include/boost/detail/shared_count.hpp:159
#3 0x080584c2 in ~shared_ptr (this=0xb71f2dcc) at /usr/include/boost/shared_ptr.hpp:106
#4 0x080584d8 in ~CommonStruct (this=0xb71f2dc0) at ./TableStructs.hpp:150
#5 0x080606c2 in CContainer::VolOk (this=0xaa557808, item=
{id = 326, number = 1 '\001', wear = 2 '\002', quality = 571, data = 0}) at CContainer.cpp:852
#6 0x08061445 in CContainer::InsertItem (this=0xaa557808, it=
{id = 326, number = 1 '\001', wear = 2 '\002', quality = 571, data = 0}, merge=false) at CContainer.cpp:109
#7 0x080d8326 in CPlayer::load (this=0xaa480e20) at CPlayer.cpp:1423
#8 0x080e4301 in CPlayer (this=0xaa480e20, newConnection=@0xb71f33bc) at CPlayer.cpp:158
#9 0x08247c22 in CPlayerManager::managingLoop (pmanager=0x15d08440) at CPlayerManager.cpp:109
#10 0xb7fd40bd in start_thread () from /lib/tls/libpthread.so.0
#11 0xb7c389ee in clone () from /lib/tls/libc.so.6

die funktion VolOk existiert schon seit jahren im ganzen system und hat bisher noch keine probleme gemacht. Neut ist der managing loop welcher gethreaded ist und das einloggen der spieler steuert. Interessant ist auch das das ganze für Stunden läuft ( mit unter bis zu 16 h ) und dann das problem innerhalb kurzer Zeit auch mehrfach auftritt. Also wenn irgendwer in irgend einer form was dazu beitragen kann ich bin für jede noch so verrückte Theorie offen, denn bisher ist es auch noch nicht gelungen den segfault mit absicht aus zu lösen.

]]>https://www.c-plusplus.net/forum/topic/193874/hilferuf-debuggingRSS for NodeMon, 28 Sep 2026 08:22:24 GMTMon, 01 Oct 2007 08:51:15 GMT60<![CDATA[Reply to hilferuf debugging on Mon, 01 Oct 2007 08:51:15 GMT]]>also, ich weiss nicht was ich mir hier jetzt erhoffe ggf nen dummen zufall das jemand spontan weiss was hier vorliegen könnte. Bzw irgend nen anhaltspunkt hat.
Ich programmiere seit ca 3 Jahren nun an einen online rollenspiel mit. In letzter Zeit wurden größere änderungen gemacht (inklusive compiler update etc also nicht nur reine Quelltextänderungen) ebenso mussten bestimmte codeteile komplett neu geschrieben werden. Auf alle fälle haben wir nun seit ca 1 Monat gehäuft segfaults an unerklärlichen stellen, erstaunlicherweise aber fast immer an der selben codestelle die an für sich nicht fehlerhaft sein dürfte. Wir haben schon mit diversen debuggern etc versucht den Fehler zu finden, nichts hat bisher wirklich geholfen. Ich greiffe zur Zeit auch nach jeden strohhalm der sich finden lässt. Vielleicht kennt jemand noch gute tools um dem problem etwas auf den grund zu gehen.

hier mal eine typische gdb ausgabe:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222689872 (LWP 15642)]
0x09464710 in ?? ()
(gdb) backtrace
#0 0x09464710 in ?? ()
#1 0x08058422 in boost::detail::sp_counted_base::release (this=0x94a57a0)
at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145
#2 0x0805845a in ~shared_count (this=0xb71f2dd0) at /usr/include/boost/detail/shared_count.hpp:159
#3 0x080584c2 in ~shared_ptr (this=0xb71f2dcc) at /usr/include/boost/shared_ptr.hpp:106
#4 0x080584d8 in ~CommonStruct (this=0xb71f2dc0) at ./TableStructs.hpp:150
#5 0x080606c2 in CContainer::VolOk (this=0xaa557808, item=
{id = 326, number = 1 '\001', wear = 2 '\002', quality = 571, data = 0}) at CContainer.cpp:852
#6 0x08061445 in CContainer::InsertItem (this=0xaa557808, it=
{id = 326, number = 1 '\001', wear = 2 '\002', quality = 571, data = 0}, merge=false) at CContainer.cpp:109
#7 0x080d8326 in CPlayer::load (this=0xaa480e20) at CPlayer.cpp:1423
#8 0x080e4301 in CPlayer (this=0xaa480e20, newConnection=@0xb71f33bc) at CPlayer.cpp:158
#9 0x08247c22 in CPlayerManager::managingLoop (pmanager=0x15d08440) at CPlayerManager.cpp:109
#10 0xb7fd40bd in start_thread () from /lib/tls/libpthread.so.0
#11 0xb7c389ee in clone () from /lib/tls/libc.so.6

die funktion VolOk existiert schon seit jahren im ganzen system und hat bisher noch keine probleme gemacht. Neut ist der managing loop welcher gethreaded ist und das einloggen der spieler steuert. Interessant ist auch das das ganze für Stunden läuft ( mit unter bis zu 16 h ) und dann das problem innerhalb kurzer Zeit auch mehrfach auftritt. Also wenn irgendwer in irgend einer form was dazu beitragen kann ich bin für jede noch so verrückte Theorie offen, denn bisher ist es auch noch nicht gelungen den segfault mit absicht aus zu lösen.

]]>https://www.c-plusplus.net/forum/post/1375761https://www.c-plusplus.net/forum/post/1375761Mon, 01 Oct 2007 08:51:15 GMT<![CDATA[Reply to hilferuf debugging on Mon, 01 Oct 2007 08:58:10 GMT]]>Interessant ist vor allem, daß der Fehler in den Destruktor-Aufrufen auftritt (also vermutlich beim Verlassen der VolOK). Ich würde, ohne den Code zu kennen, auf einen zerstörten Heap tippen (vermutlich habt ihr irgendwo über die Grenzen des reservierten Speichers hinausgeschrieben).

]]>https://www.c-plusplus.net/forum/post/1375770https://www.c-plusplus.net/forum/post/1375770Mon, 01 Oct 2007 08:58:10 GMT<![CDATA[Reply to hilferuf debugging on Mon, 01 Oct 2007 09:07:04 GMT]]>ja an eine heap corruption glauben wir auch, die frage ist woher kommt die *gg*

]]>https://www.c-plusplus.net/forum/post/1375773https://www.c-plusplus.net/forum/post/1375773Mon, 01 Oct 2007 09:07:04 GMT<![CDATA[Reply to hilferuf debugging on Mon, 01 Oct 2007 09:15:07 GMT]]>Vermutlich nicht aus dieser Funktion 😉 (ich weiß, das hilft nicht weit)

Ich tippe darauf, daß ihr irgendwo über die Grenzen des zulässigen Speicherbereiches hinausgeschrieben habt (wenn du Speicher per arr=new T[x]; anforderst, sind 'arr[0]' bis 'arr[x-1]' erlaubt - 'arr[x]' liegt außerhalb deiner Zuständigkeit (und könnte sogar Steuerdaten des Heap-Managers enthalten).
(vielleicht ist's ja nur ein überflüssiges Zeichen wie in "for(i=0;i<=x;++i)arr[i]=...;")

]]>https://www.c-plusplus.net/forum/post/1375783https://www.c-plusplus.net/forum/post/1375783Mon, 01 Oct 2007 09:15:07 GMT<![CDATA[Reply to hilferuf debugging on Tue, 02 Oct 2007 02:36:29 GMT]]>hm bisher hab ich noch überhaupt nichts gefunden. Keine Ansätze überhaupt nichts weiter, das ist langsam so nach 1 Monat frustrierend. Das ganze stürzt zwar nicht mehr all zu oft ab aber so ein mal aller 24 h ist auch nicht tragbar für unsere spieler. Selbst sowas wie valgrind und co hat nicht geholfen.

]]>https://www.c-plusplus.net/forum/post/1376273https://www.c-plusplus.net/forum/post/1376273Tue, 02 Oct 2007 02:36:29 GMT<![CDATA[Reply to hilferuf debugging on Tue, 02 Oct 2007 17:03:08 GMT]]>Die Tatsache, dass es so selten auftritt, könnte darauf schließen,
dass eine Stelle als Threadsicher angenommen wird, aber es nicht wirklich ist.

Nur ne Vermutung...

Gruß,
CSpille

]]>https://www.c-plusplus.net/forum/post/1376775https://www.c-plusplus.net/forum/post/1376775Tue, 02 Oct 2007 17:03:08 GMT<![CDATA[Reply to hilferuf debugging on Tue, 02 Oct 2007 17:17:53 GMT]]>CSpille schrieb:

Die Tatsache, dass es so selten auftritt, könnte darauf schließen,
dass eine Stelle als Threadsicher angenommen wird, aber es nicht wirklich ist.

Würde ich auch sagen, vor allem, weil der OP meint, der "managing-pool ist jetzt gethreaded" (frei zitiert).

Vielleicht laufe ich auch gerade auf einem hölzernen Weg herum, aber in der Ausgabe steht ja etwas von einer CommonStruct, die anscheinend von einem shared_ptr verwaltet wird. Wird der shared_ptr evtl in mehr als einem Thread benutzt? Da könnte ja beim ref-zählen ein Thread-Sprung stattfinden, der das ein wenig zerschiesst..?

]]>https://www.c-plusplus.net/forum/post/1376784https://www.c-plusplus.net/forum/post/1376784Tue, 02 Oct 2007 17:17:53 GMT<![CDATA[Reply to hilferuf debugging on Wed, 03 Oct 2007 18:33:56 GMT]]>also es werden einige shared_ptr in threads verwendet, dort aber nur in thread save vectoren 😉

ich denke auch das irgendwas nicht ganz 100 % thread save ist aber noch nicht genau wo.

Alles was hier aufgeführt wurde wo der server gerade crasht geschieht sozusagen in der main loop und da achte ich penibel genau das dort kein thread irgendwie reinspielt, die einzige schnittstelle zur main world ist beim login und logout von spielern und die läuft auch wieder über ein thread save vector klasse.

]]>https://www.c-plusplus.net/forum/post/1377426https://www.c-plusplus.net/forum/post/1377426Wed, 03 Oct 2007 18:33:56 GMT<![CDATA[Reply to hilferuf debugging on Wed, 03 Oct 2007 20:22:51 GMT]]>Badestrand schrieb:

CSpille schrieb:

Die Tatsache, dass es so selten auftritt, könnte darauf schließen,
dass eine Stelle als Threadsicher angenommen wird, aber es nicht wirklich ist.

Würde ich auch sagen, vor allem, weil der OP meint, der "managing-pool ist jetzt gethreaded" (frei zitiert).

Vielleicht laufe ich auch gerade auf einem hölzernen Weg herum, aber in der Ausgabe steht ja etwas von einer CommonStruct, die anscheinend von einem shared_ptr verwaltet wird. Wird der shared_ptr evtl in mehr als einem Thread benutzt? Da könnte ja beim ref-zählen ein Thread-Sprung stattfinden, der das ein wenig zerschiesst..?

Ahh ich depp danke für den tipp ich glaube das war eine der heissesten spuren bisher, ich hab nun was gefunden was genau damit zu tun hatte. Danke danke, ich hoffe der kleine workaround hilft.

]]>https://www.c-plusplus.net/forum/post/1377472https://www.c-plusplus.net/forum/post/1377472Wed, 03 Oct 2007 20:22:51 GMT