Afișează-l pe acel br_n după ReadFile ca să vezi.
On Tue, 2 Apr 2019 at 07:35, Paul Olaru <[email protected]> wrote: > > Cred că 0 nu, dar citirile pot returna câte 1 singur octet fiecare teoretic. > > On Tue, Apr 2, 2019, 07:34 Ionuț Mihalache <[email protected]> wrote: >> >> Adică la un moment dat se pot citi 0 octeți fără să se fi ajuns la finalul >> pipe-ului, corect? >> >> mar., 2 apr. 2019, 02:12 Adrian Șendroiu <[email protected]> a scris: >>> >>> Pare bine partea de lansat procese și redirectarea din pipe. >>> >>> Acum, dacă mă uit mai atent, problema la tine pare să fie în logica de >>> fread. Nu prea înțeleg foarte bine algoritmul, dar se pare că >>> presupunerea ta este că ReadFile o să întoarcă mereu 4096 de bytes, cu >>> excepția ultimului bloc care poate fi mai mic. >>> >>> Ori în cazul pipe-ului nu mai e adevărat asta. ReadFile poate întoarce >>> orice număr de bytes, depinde câți au fost în pipe la momentul >>> respectiv. >>> >>> În ultima variantă de checker am scos sleep-ul și verificarea >>> numărului de syscalluri pentru testul ăsta. Ar trebui să meargă și >>> așa. >>> >>> On Tue, 2 Apr 2019 at 00:46, Ionuț Mihalache <[email protected]> wrote: >>> > >>> > Bun, atunci cred că am găsit problema să zic. Eu închideam capul de >>> > scriere respectiv de citire în părinte imediat ce cream procesul copil. >>> > Cel mai probabil prin schimbarea de context câteodată părintele ajungea >>> > să închidă acel cap de scriere respectiv de citire și atunci pipe-ul >>> > devenea inutilizabil. Însă revin la indicațiile pe care mi le-a dat >>> > Adrian. Dacă nu las sleep nu merge orice aș face. Bănuiesc că sleep >>> > trebuie să fie pentru ca testul să funcționeze corect, nu? >>> > >>> > În mar., 2 apr. 2019 la 00:32, Paul Olaru <[email protected]> >>> > a scris: >>> >> >>> >> Sistemul de operare nu trebuie să raporteze EOF la capătul de citire >>> >> atâta timp cât există un capăt de scriere deschis. Că e Windows, că e >>> >> Linux. >>> >> >>> >> On Tue, Apr 2, 2019, 00:30 Ionuț Mihalache <[email protected]> wrote: >>> >>> >>> >>> Păi dacă procesul copil nu apucă să scrie cu type pe pipe procesul >>> >>> părinte nu-l vede ca fiind gol chiar dacă procesul copil mai are de >>> >>> scris și a fost scos de pe procesor? Încă nu exclud posibilitatea ca eu >>> >>> să am un bug în cod însă am comentat toate liniile unde verific dacă >>> >>> s-a ajuns la EOF, practic testul ar trebui să cicleze însă tot primesc >>> >>> aceeași eroare. Eu chiar nu cred că este ceva din codul meu pentru că >>> >>> sunt câteva linii și nu au o logică dubioasă. Dacă las acel sleep merge >>> >>> pentru așa cum este și în comentariu în test este nevoie de el pentru >>> >>> ca procesul copil să poate scrie datele pe pipe. Nu există șansa ca eu >>> >>> să fi avut ghinion și pur și simplu să fi trimis tema fix când >>> >>> vmchecker a început să fie problematic. Eu sunt destul de sigur că >>> >>> problema este de la preemptare nu de la mine. >>> >>> >>> >>> În lun., 1 apr. 2019 la 23:30, Adrian Șendroiu <[email protected]> >>> >>> a scris: >>> >>>> >>> >>>> Da, ideea este că la tine se ajunge în pclose prea repede și se >>> >>>> închide pipe-ul în timp ce type încă încearcă să mai scrie în el, de >>> >>>> unde și eroarea cu "The process tried to write to a nonexistent pipe". >>> >>>> >>> >>>> N-ar trebui să se întâmple asta pentru că testul face >>> >>>> while(!so_feof(f)) și apoi pclose. Deci înseamnă că cumva so_feof >>> >>>> raportează EOF mai devreme decât trebuie. >>> >>>> >>> >>>> On Mon, 1 Apr 2019 at 22:52, Ionuț Mihalache <[email protected]> >>> >>>> wrote: >>> >>>> > >>> >>>> > Din ce am citit aici [1] problema ar fi de la modul cum functioneaza >>> >>>> > type. >>> >>>> > >>> >>>> > Am incercat sa ma uit pe cod sa vad daca exista vreun bug ciudat si >>> >>>> > chiar nu vad ce ar putea fi. Problema mea este ca 'The process tried >>> >>>> > to write to a nonexistent pipe.' insa testul face fread. Singura >>> >>>> > scriere este generata de comanda type din test si de asta zic eu ca >>> >>>> > ar crapa programul cateodata nefiind neaparat problema la codul >>> >>>> > scris de mine, dar ma mai uit insa chiar nu mai stiu la ce ca sa >>> >>>> > identific problema. >>> >>>> > >>> >>>> > [1] - >>> >>>> > https://stackoverflow.com/questions/40066965/my-c-sharp-program-gives-an-error-the-process-tried-to-write-to-a-nonexistent-p?rq=1 >>> >>>> > >>> >>>> > În lun., 1 apr. 2019 la 19:58, Adrian Șendroiu >>> >>>> > <[email protected]> a scris: >>> >>>> >> >>> >>>> >> Nu, e suficient. Dar vezi să nu ai alt bug sau ceva, pentru că dacă >>> >>>> >> rulezi cum zic eu îți crapă programul. >>> >>>> >> >>> >>>> >> On Mon, 1 Apr 2019 at 18:59, Ionuț Mihalache <[email protected]> >>> >>>> >> wrote: >>> >>>> >> > >>> >>>> >> > Pentru a verifica dacă s-a ajuns la eof verific în fread dacă >>> >>>> >> > ReadFile a întors FALSE și apoi getlasterror și ies dacă este >>> >>>> >> > acea eroare din enunț, ar trebui să mai fac ceva? >>> >>>> >> > >>> >>>> >> > lun., 1 apr. 2019, 18:52 Adrian Șendroiu <[email protected]> >>> >>>> >> > a scris: >>> >>>> >> >> >>> >>>> >> >> Salut, >>> >>>> >> >> >>> >>>> >> >> Cred că ai o problemă cu semnalizarea EOF-ului. >>> >>>> >> >> >>> >>>> >> >> Încearcă următoarea chestie: în test_popen_read.c comentează acel >>> >>>> >> >> "Sleep(2000)", precum și linia "FAIL_IF(num_ReadFile != >>> >>>> >> >> expected_sys_read...". >>> >>>> >> >> >>> >>>> >> >> În cazul ăsta o să-ți dea eroarea respectivă la fiecare rulare. >>> >>>> >> >> >>> >>>> >> >> On Sun, 31 Mar 2019 at 09:11, Paul Olaru >>> >>>> >> >> <[email protected]> wrote: >>> >>>> >> >> > >>> >>>> >> >> > La testul 32, pot fi chestii de scheduler. Cred că ar fi >>> >>>> >> >> > importantă de fapt ordinea (la "r" aștepți și după închizi, la >>> >>>> >> >> > "w" închizi și după aștepți). Nici eu nu am implementat asta >>> >>>> >> >> > tbh. Dar și la "aștepți și după închizi" sunt neajunsuri. >>> >>>> >> >> > >>> >>>> >> >> > Sunt surprins că pe Linux reușește checkerul să preia el toate >>> >>>> >> >> > datele înainte de a apela pclose. >>> >>>> >> >> > >>> >>>> >> >> > On Sun, Mar 31, 2019, 02:05 Ionuț Mihalache via so >>> >>>> >> >> > <[email protected]> wrote: >>> >>>> >> >> >> >>> >>>> >> >> >> Și acum a mers. Arhiva este aceeași. >>> >>>> >> >> >> >>> >>>> >> >> >> În dum., 31 mar. 2019 la 02:02, Ionuț Mihalache >>> >>>> >> >> >> <[email protected]> a scris: >>> >>>> >> >> >>> >>> >>>> >> >> >>> Salut, >>> >>>> >> >> >>> >>> >>>> >> >> >>> Iar mi-a apărut eroarea asta „The process tried to write to >>> >>>> >> >> >>> a nonexistent” pipe. la testul 32. O să trimit iarăși însă >>> >>>> >> >> >>> mi se pare ciudat pentru că am rulat pe mașina virtuală de >>> >>>> >> >> >>> 10 ori la rând și nu am avut eroarea asta. >>> >>>> >> >> >>> >>> >>>> >> >> >>> În sâm., 30 mar. 2019 la 19:04, Adrian Șendroiu >>> >>>> >> >> >>> <[email protected]> a scris: >>> >>>> >> >> >>>> >>> >>>> >> >> >>>> Salut, >>> >>>> >> >> >>>> >>> >>>> >> >> >>>> M-am uitat și pare ok. O fi fost de la vmchecker. >>> >>>> >> >> >>>> >>> >>>> >> >> >>>> On Sat, 30 Mar 2019 at 18:15, Ionuț Mihalache via so >>> >>>> >> >> >>>> <[email protected]> wrote: >>> >>>> >> >> >>>> > >>> >>>> >> >> >>>> > Salut, >>> >>>> >> >> >>>> > >>> >>>> >> >> >>>> > Am trimis pentru prima dată tema2 pe windows și părea că >>> >>>> >> >> >>>> > a intrat în buclă infinită la testul 20. După ce am mai >>> >>>> >> >> >>>> > trimis încă o dată la penultimul test am primit eroare cu >>> >>>> >> >> >>>> > non-existing pipe. După am mai trimis încă de 3 ori și de >>> >>>> >> >> >>>> > fiecare dată am primit 95/95. Este posibil să fie ceva de >>> >>>> >> >> >>>> > la vmchecker sau să mă mai uit pe cod să văd dacă am >>> >>>> >> >> >>>> > niște bug-uri care apar mai rar? >>> >>>> >> >> >>>> > _______________________________________________ >>> >>>> >> >> >>>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii >>> >>>> >> >> >> >>> >>>> >> >> >> _______________________________________________ >>> >>>> >> >> >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
