Keskustelu: Ohjelmointikysymykset: Ylivuoto-ongelma (Linux C++)

Elikkäs olen tässä jonkunaikaa kehittänyt sovellusta ja nyt olen törmännyt ylipääsemättömään bugiin. Olen debugannut useat bugit helposti pois gdb:llä mutta nytten kun haen backtracen kaatumisen jälkeen niin saan tälläisen tulosteen.
http://pastebin.com/f4ba0a560

Sovelluksessa on erittäin paljon koodia, mutta minulla on epäilys seuraavista 2 tiedostosta joissa bugi voi olla.

http://www.koodari.org/nicklist.hpp ja http://www.koodari.org/nickclass.hpp

Tuosta pastebiniin työntämästäsi pätkästä ei voi kyllä heittää edes arvailuja missä bugi voisi olla. Nopeasti vilkaisin koodiasi niin ei siitäkään mitään isompaa silmään pistänyt - tarkempaan arvioon tarvitsisi esim. lisäinfoa gdb:ltä. Kokeilepa ajaa valgrindin lävitse.

Käännä ohjelmasi debug-infon kanssa (-g) ja ota optimoinnit (-O) pois, niin GDB kertoo sata kertaa fiksumpaa asiaa. (Paste-pätkästäsi ei muuten edes näy virheilmoitus, mikähän se olisi?)

Tiedän että softa pitää kääntää ilman optimointeja ja -g -flägillä jos haluaa debuggerilla saada selvää. Olen tehnyt näin mutta gdb:llä ei ainakaan mitään irtoa.

Epäilykseni noihin tiedostoihin johtuu siitä, että nuo kuuluvat ircbottiin. Kyseiset moduulit ylläpitää nimimerkkilistaa kanavilta jne jne... Botti kaatuu aina kun se liittyy tietylle kanavalle. Ainoastaan vasta sitten kun se liittyy sinne.

GDB:n koko tuloste -> http://pastebin.com/m42fadfee

Valgrindillä botti toimi niin hitaasti että se kerkesi pingaa ulos ennenku sain sen liitettyä kyseiselle kanavalle.

Pistä gdb:llä breakpointteja kohtiin joiden uskot hajoavan, ja katso minne ongelmasi johtaa. Toisaalta ongelma voi olla aika syvälläkin kun kerran muistinvapautus epäonnistuu. Suosittelisin kyllä C++:ssa pointterikikkailujen minimoimista niin ei tarvitsisi muistivuodoissa hajoilla.

Kuulostaa myös aika erikoiselta että ohjelmasi ei ollut tarpeeksi nopea valgrindilla, sillä vaikka valgrind hidastaakin ohjelmaa todella paljon niin luulisi että ping timeout -rajat olisivat aika korkealla.

Veikkaisin että vaatii aika syvällistä porautumista ohjelmaan että saat ongelman korjattua. Joko raskasta breakpointtien kirjoittelua gdb:llä tai "vanhanaikaisten" debug-viestien kirjoittamista (jotka soveltuvat mielestäni usein hyvin gdb:n kanssa debuggaamiseen), tai sitten koko ohjelman uudelleenstrukturointia enemmän C++:maiseksi, joka ei kuitenkaan liene kovin mukava vaihtoehto ;).

EDIT: Siis lyhyesti: luultavasti vapautat jotain joka on jo vapautettu. Tarkistapa kohdat joissa vapautat muistia.

EDIT2: Joku häiskä internetissä suositteli mtracea varsinkin jos valgrind toimii liian hitaasti C++:n kanssa.

Voit myös koittaa tehdä ohjelmasta prototyypin, joka ei käytä kaikkia lopullisen ohjelman ominaisuuksia. Tämä voi auttaa etsimään virhekohdan.

Outoa, kyllä jossain on oltava vikaa, jos et saa gdb:ltä kunnon viestejä, esimerkiksi näin:

(gdb) bt
#0  0xb7f16424 in __kernel_vsyscall ()
#1  0xb7cc0720 in raise () from /lib/libc.so.6
#2  0xb7cc2058 in abort () from /lib/libc.so.6
#3  0xb7cfbc8d in __libc_message () from /lib/libc.so.6
#4  0xb7d01a74 in malloc_printerr () from /lib/libc.so.6
#5  0xb7d033ec in free () from /lib/libc.so.6
#6  0x0804865d in A::operator delete (p=0x916c008) at koe.cpp:9
#7  0x080485de in main () at koe.cpp:14

Tarkista siis vielä käännösasetukset ja muut, kyllä elämää helpottaa gdb:n toiminta.

Muistiongelmien kanssa yksi melko kätevä tutkintatapa on omien malloc- ja free-funktioiden (new- ja delete-operattorien) kirjoittaminen niin, että ne tulostavat varatut ja vapautetut osoitteet.

Ihmettelin samaa kuin Metabolix, vaikka tuo nyt ei aivan ennenkuulumatonta olekaan ettei gdb anna mitään järkevää. Tarkista tosiaan nyt vielä ettei se -g ole vahingossa jossain käännössä unohtunut. (Jos vaikka luulit että ohjelma toimii jo oikein ja käänsit optimointiflageilla yms.)

En tosin ole koskaan debugannut gdb:llä ohjelmaa jossa olisi todella paljon tavaraa ennen kuin se kaatuu, tällöin saattaa tosiaan joutua kelaamaan paljon tuossa press <return> to scroll tjsp. -kohdassa.