Buna tuturor, Am reusit sa gasesc care erau problemele care imi cauzau acel comportament ciudat. Am reimplementat unele dintre functiile hashtable-ului care imi creau probleme.
Multumesc mult pentru feedback, Mihai. M-a ajutat sa fac debugging si sa imi rezolv din probleme. Numai bine, Adriana Pe 14 martie 2017, 00:26, Mihai Barbulescu <b12mi...@gmail.com> a scris: > Mai incerc sa inteleg de ce _doar_ pt 8 caractere ai problema asta > insa pana la aia ai unele mai mari: > > 1. aloci pt buffs si params 100000 si 50000 -> e cam mult la alocarea > asta statica si imi zic astea ca poate d-aia pica testele de pe Linux. > 2. hash.c -> nu trebuia sa regenerezi libhash.so. libhash.so SE DA in > tema si tre` doar sa te linkezi cu el. Sursa hash.c am dat-o pt cei > care dezvolta pe masini cu alta arhitectura decat vm-ul de SO. Sa > corectezi acest aspect te rog. > 3. Formularea strcpy( cmd, strtok( buff, " " ) ); nu prea imi place. > strcpy oricum e known to offer buffer overflows. Incearca folosirea > strncpy si salveaza ce genereaza strtok intr-o variabila, poate > de-acolo vin probleme > > Pe langa ele adaug: > > 4. Intr-adevar: pe o masina cu ubuntu 14.04 cu 64 bit tema ta trece > toate testele, dar pe cea de SO nu trece (cea de SO fiind si cea de pe > vmchecker!). Verifica daca si initializezi memoria folosita/alocata. > 5. Vad ca bagi extra lines/whitespaces - nu ca ar fi neaparat asta o > problema, dar ne-am mai fript, vezi atat precizarea din enunt cat si > discutia de aici: > https://www.mail-archive.com/so@cursuri.cs.pub.ro/msg03743.html > 6. Apropo de cifra magica 8, valgrind imi da cu virgula pe testul 2, > verifica outputul de mai jos (si ti-am zis sa rulezi cu valgrind) si > uita-te ce-ai prin functiile add si print ale hashtable-ului. Si n-am > inteles ce vrei sa faci in jur de linia 169 p-acolo cu if-ul ala fara > nimic. > > ==8507== Invalid write of size 1 > ==8507== at 0x4C2E1F3: strcpy (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8507== by 0x402406: createntry (util.c:144) > ==8507== by 0x402571: add (util.c:175) > ==8507== by 0x400E51: readFromStdin (tema1.c:22) > ==8507== by 0x401E73: main (tema1.c:214) > ==8507== Address 0x53fe928 is 0 bytes after a block of size 8 alloc'd > ==8507== at 0x4C2AB80: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8507== by 0x4023E6: createntry (util.c:142) > ==8507== by 0x402571: add (util.c:175) > ==8507== by 0x400E51: readFromStdin (tema1.c:22) > ==8507== by 0x401E73: main (tema1.c:214) > ==8507== > ==8507== Invalid read of size 1 > ==8507== at 0x5084943: vfprintf (vfprintf.c:1661) > ==8507== by 0x508D3D8: printf (printf.c:33) > ==8507== by 0x402A65: print (util.c:312) > ==8507== by 0x401184: readFromStdin (tema1.c:59) > ==8507== by 0x401E73: main (tema1.c:214) > ==8507== Address 0x53fe928 is 0 bytes after a block of size 8 alloc'd > ==8507== at 0x4C2AB80: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==8507== by 0x4023E6: createntry (util.c:142) > ==8507== by 0x402571: add (util.c:175) > ==8507== by 0x400E51: readFromStdin (tema1.c:22) > ==8507== by 0x401E73: main (tema1.c:214) > > NOTE TIP pentru : verificati memory leak-urile si accesele nevalide la > memorie (buffer overflows, acces memorie nealocata etc) folosind > tutorialul de valgrind de aici [1] si gdb [1']. Debugati tema in > masina virtuala de SO si nu altundeva [2] > > [1]: https://ocw.cs.pub.ro/courses/so/laboratoare/laborator-05# > exercitiul_5_-_lucru_cu_memoria_-_valgrind_1p > [1']: https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/gdb > [2]: https://ocw.cs.pub.ro/courses/so/info/mv > > > 2017-03-13 19:28 GMT+02:00 Adriana Dinca <dinca.adria...@gmail.com>: > > Buna din nou, > > > > Am reusit sa reproduc problema descrisa initial. > > > > Codul sursa este cel de pe vmchecker. > > > > Continutul fisierului _test/inputs/test2.in: > > add vilfredo > > print > > > > Rulez urm. comand in Cygwin: > > $./tema1.exe 1 _test/inputs/test2.in > > > > Nu obtin niciun rezultat. > > > > Modific continutul fisiserului _test/inputs/test2.: > > add vilfredo1 > > print > > > > Rulez urm. comand in Cygwin: > > $ ./tema1.exe 1 _test/inputs/test2.in > > vilfredo1 > > > > Am observat ca am aceasta problema daca cuvatul adaugat are 8 caractere. > > > > Eu nu reusesc sa gasesc o explicatie a acestui comportament. > > > > Mihai, daca ai timp si poti sa iti arunci un ochi peste tema mea, as > > aprecia. > > Eu pot sa o urc si pe bitbucket daca iti e mai comod. > > > > Username-ul meu de cs este adriana.dinca. > > Folosesc pentru rularea testelor masina virtuala de SO. > > > > > > Numai bine, > > Adriana > > > > > > > > > > > > > > > > > > > > > > > > Pe 13 martie 2017, 14:57, Mihai Barbulescu <b12mi...@gmail.com> a scris: > >> > >> Buna, > >> > >> M-am uitat pe noua submisie a ta de pe vmchecker, vad niste buffer > >> overflow-uri (nu m-am uitat in cod, doar pe rularile Linux/Windows), > >> da-i si cu un valgrind inainte sa vezi pe unde dai p-afara cu memoria. > >> Nu alocarea e problema ci faptul ca undeva dai peste. > >> > >> Atat la rularea cu GDB (apropo, baga cu cgdb e mai draguta interfata) > >> cat si la cea cu VALGRIND ai grija sa compilezi cu -g si sa stergi > >> orice alta -O optiune de optimizare pentru a prinde mai usor problema. > >> Si dai cu valgrind peste unul din testele care pica in Linux. > >> > >> Alt hint pe care il vad e la 24) Test double... -> pare ca outputul > >> tau e bun dar ai bagat un funny character in forma de triunghi > >> p-acolo, nu stiu cum reusesti sa il bagi, poate nu pui \0 cand prntezi > >> stringu`, nu imi dau seama. > >> > >> -marci nona megen jerry rachmaninoff frederique vanny alyss carlee > >> betsey winona daphna cindie wynn jeanie > >> +marci nona megen jerry rachmaninoff frederique vanny alyss carlee > >> betsey winona daphna cindie wynn jeanie > >> > >> Momentan astea sunt singurele idei acum. > >> > >> 2017-03-13 14:11 GMT+02:00 Adriana Dinca <dinca.adria...@gmail.com>: > >> > Buna Mihai, > >> > > >> > Pe vmchecker e urcata ultima arhiva care care la rulare din Cygwin imi > >> > genereaza outputuri diferite pt testul 2. > >> > Username-ul meu de cs este adriana.dinca. > >> > > >> > Cred ca acest comportament se datoreaza modului in care programul meu > >> > aloca > >> > memoria. > >> > > >> > Am incercat astazi sa reproduc problema si nu am mai reusit. > >> > > >> > In schimb obtin outputuri diferite la rularea aceluiasi executabil cu > >> > aceleasi argumente pentru un alt test. > >> > > >> > O sa rulez cu gdb sa vad daca gasesc problema. > >> > > >> > Multumesc pt raspuns. > >> > > >> > O zi faina, > >> > Adriana > >> > > >> > > >> > > >> > > >> > > >> > > >> > On 13 Mar 2017 7:59 a.m., "Mihai Barbulescu" <b12mi...@gmail.com> > wrote: > >> > > >> > 2017-03-12 20:05 GMT+02:00 Adriana Dinca via so <so@cursuri.cs.pub.ro > >: > >> >> Buna tuturor, > >> >> > >> >> Am urmatoarea problema atunci cand rulez test2.in. > >> >> > >> >> Pe Linux testul imi trece fara probleme. > >> >> > >> >> Pe Windows are urmatorul comportament: > >> >> - daca rulez executabilul din Cygwin si dau comenzile de la stdin > obtin > >> >> outputul corect > >> >> - daca rulez executabilul din Cygwin si dau ca parametru fisier-ul cu > >> >> aceleasi comenzi nu imi afisaza nimic. (nici macar printf de pe > primul > >> >> rand > >> >> al main-ului) > >> >> - daca rulez executabilul din Visual Studio Power Shell imi afisaza > >> >> printf > >> >> de pe primul rand din main, insa crapa si cand citesc de la stdin sau > >> >> din > >> >> fisier. > >> >> > >> >> Mentionez ca folosesc doar functii ANSI C si ca lucrez pe masina > >> >> virtuala > >> >> pusa la dispozitie de catre echipa de SO. > >> >> > >> >> Daca modific continutul fisierului test2.in prin modificarea > lungimii > >> >> cuvantului adaugat (fie < 8 caractere / > 8 caractere) nu apar > >> >> problemele > >> >> descrise mai sus. > >> >> > >> >> Am observat ca testul imi crapa daca adaug cuvinte care au lungimea > >> >> egala > >> >> cu > >> >> 8 caractere. > >> >> Daca inlocuiesc "vilfredo" cu "aaaaaaaa" obtin acelasi comportament. > >> >> In schimb daca inlocuiesc cu "aaa" sau "aaaaaaaaaaaaa" merge fara > >> >> probleme. > >> >> > >> >> Daca ati mai intalnit aceasta problema sau aveti vreo idee din ce > cauza > >> >> obtin acest comportament ciudat, v-as ruga sa imi dati de stire. > >> >> > >> >> Multumesc! > >> >> > >> > > >> > Buna, > >> > > >> > Nu am reusit inca sa ma prind de acest comportament ciudat al tau. Pe > >> > vmchecker e ultima versiune a codului care reproduce acest > >> > comportament? > >> > Eventual poti rula test2.in pas cu pas si sa ne dai aici pe lista tot > >> > output-ul + descrierea comportamentului? E OK, ca nu dai cod sursa. > >> > Asta ca sa stiu ce fac cand reproduc cu tema ta. > >> > > >> > De asemenea, pe Windows singurul scenariu valid este rularea din > >> > Cygwin, nu va stresati cu rulat din visual studio debug shell sau > >> > power shell sau windows cmd. Atat vmchecker cat si testele presupun > >> > rularea din cygwin. > >> > > >> > -- > >> > Cu stimă, > >> > Mihai Bărbulescu > >> > > >> > > >> > >> > >> > >> -- > >> Cu stimă, > >> Mihai Bărbulescu > > > > > > > > -- > Cu stimă, > Mihai Bărbulescu >
_______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
