<div dir="ltr">Am reusit sa repar problema. Aveam un acces invalid de memorie in urma calculelor pe care le facem si procesul parinte crapa si pipe-ul nu mai functiona. Tot ce pot sa spun este ca desi si vmchecker are aceeasi masina virtuala lucrurile cumva difera, cel putin pentru testul cu popen read pe windows.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">În mar., 2 apr. 2019 la 09:34, Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com">molecula2788@gmail.com</a>> a scris:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Afișează-l pe acel br_n după ReadFile ca să vezi.<br>
<br>
On Tue, 2 Apr 2019 at 07:35, Paul Olaru <<a href="mailto:olarupaulstelian97@gmail.com" target="_blank">olarupaulstelian97@gmail.com</a>> wrote:<br>
><br>
> Cred că 0 nu, dar citirile pot returna câte 1 singur octet fiecare teoretic.<br>
><br>
> On Tue, Apr 2, 2019, 07:34 Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> wrote:<br>
>><br>
>> Adică la un moment dat se pot citi 0 octeți fără să se fi ajuns la finalul pipe-ului, corect?<br>
>><br>
>> mar., 2 apr. 2019, 02:12 Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com" target="_blank">molecula2788@gmail.com</a>> a scris:<br>
>>><br>
>>> Pare bine partea de lansat procese și redirectarea din pipe.<br>
>>><br>
>>> Acum, dacă mă uit mai atent, problema la tine pare să fie în logica de<br>
>>> fread. Nu prea înțeleg foarte bine algoritmul, dar se pare că<br>
>>> presupunerea ta este că ReadFile o să întoarcă mereu 4096 de bytes, cu<br>
>>> excepția ultimului bloc care poate fi mai mic.<br>
>>><br>
>>> Ori în cazul pipe-ului nu mai e adevărat asta. ReadFile poate întoarce<br>
>>> orice număr de bytes, depinde câți au fost în pipe la momentul<br>
>>> respectiv.<br>
>>><br>
>>> În ultima variantă de checker am scos sleep-ul și verificarea<br>
>>> numărului de syscalluri pentru testul ăsta. Ar trebui să meargă și<br>
>>> așa.<br>
>>><br>
>>> On Tue, 2 Apr 2019 at 00:46, Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > 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?<br>
>>> ><br>
>>> > În mar., 2 apr. 2019 la 00:32, Paul Olaru <<a href="mailto:olarupaulstelian97@gmail.com" target="_blank">olarupaulstelian97@gmail.com</a>> a scris:<br>
>>> >><br>
>>> >> 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.<br>
>>> >><br>
>>> >> On Tue, Apr 2, 2019, 00:30 Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> wrote:<br>
>>> >>><br>
>>> >>> 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.<br>
>>> >>><br>
>>> >>> În lun., 1 apr. 2019 la 23:30, Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com" target="_blank">molecula2788@gmail.com</a>> a scris:<br>
>>> >>>><br>
>>> >>>> Da, ideea este că la tine se ajunge în pclose prea repede și se<br>
>>> >>>> închide pipe-ul în timp ce type încă încearcă să mai scrie în el, de<br>
>>> >>>> unde și eroarea cu "The process tried to write to a nonexistent pipe".<br>
>>> >>>><br>
>>> >>>> N-ar trebui să se întâmple asta pentru că testul face<br>
>>> >>>> while(!so_feof(f)) și apoi pclose. Deci înseamnă că cumva so_feof<br>
>>> >>>> raportează EOF mai devreme decât trebuie.<br>
>>> >>>><br>
>>> >>>> On Mon, 1 Apr 2019 at 22:52, Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> wrote:<br>
>>> >>>> ><br>
>>> >>>> > Din ce am citit aici [1] problema ar fi de la modul cum functioneaza type.<br>
>>> >>>> ><br>
>>> >>>> > 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.<br>
>>> >>>> ><br>
>>> >>>> > [1] - <a href="https://stackoverflow.com/questions/40066965/my-c-sharp-program-gives-an-error-the-process-tried-to-write-to-a-nonexistent-p?rq=1" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/40066965/my-c-sharp-program-gives-an-error-the-process-tried-to-write-to-a-nonexistent-p?rq=1</a><br>
>>> >>>> ><br>
>>> >>>> > În lun., 1 apr. 2019 la 19:58, Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com" target="_blank">molecula2788@gmail.com</a>> a scris:<br>
>>> >>>> >><br>
>>> >>>> >> Nu, e suficient. Dar vezi să nu ai alt bug sau ceva, pentru că dacă<br>
>>> >>>> >> rulezi cum zic eu îți crapă programul.<br>
>>> >>>> >><br>
>>> >>>> >> On Mon, 1 Apr 2019 at 18:59, Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> wrote:<br>
>>> >>>> >> ><br>
>>> >>>> >> > 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?<br>
>>> >>>> >> ><br>
>>> >>>> >> > lun., 1 apr. 2019, 18:52 Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com" target="_blank">molecula2788@gmail.com</a>> a scris:<br>
>>> >>>> >> >><br>
>>> >>>> >> >> Salut,<br>
>>> >>>> >> >><br>
>>> >>>> >> >> Cred că ai o problemă cu semnalizarea EOF-ului.<br>
>>> >>>> >> >><br>
>>> >>>> >> >> Încearcă următoarea chestie: în test_popen_read.c comentează acel<br>
>>> >>>> >> >> "Sleep(2000)", precum și linia "FAIL_IF(num_ReadFile !=<br>
>>> >>>> >> >> expected_sys_read...".<br>
>>> >>>> >> >><br>
>>> >>>> >> >> În cazul ăsta o să-ți dea eroarea respectivă la fiecare rulare.<br>
>>> >>>> >> >><br>
>>> >>>> >> >> On Sun, 31 Mar 2019 at 09:11, Paul Olaru <<a href="mailto:olarupaulstelian97@gmail.com" target="_blank">olarupaulstelian97@gmail.com</a>> wrote:<br>
>>> >>>> >> >> ><br>
>>> >>>> >> >> > 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.<br>
>>> >>>> >> >> ><br>
>>> >>>> >> >> > Sunt surprins că pe Linux reușește checkerul să preia el toate datele înainte de a apela pclose.<br>
>>> >>>> >> >> ><br>
>>> >>>> >> >> > On Sun, Mar 31, 2019, 02:05 Ionuț Mihalache via so <<a href="mailto:so@cursuri.cs.pub.ro" target="_blank">so@cursuri.cs.pub.ro</a>> wrote:<br>
>>> >>>> >> >> >><br>
>>> >>>> >> >> >> Și acum a mers. Arhiva este aceeași.<br>
>>> >>>> >> >> >><br>
>>> >>>> >> >> >> În dum., 31 mar. 2019 la 02:02, Ionuț Mihalache <<a href="mailto:ipopescu46@gmail.com" target="_blank">ipopescu46@gmail.com</a>> a scris:<br>
>>> >>>> >> >> >>><br>
>>> >>>> >> >> >>> Salut,<br>
>>> >>>> >> >> >>><br>
>>> >>>> >> >> >>> 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.<br>
>>> >>>> >> >> >>><br>
>>> >>>> >> >> >>> În sâm., 30 mar. 2019 la 19:04, Adrian Șendroiu <<a href="mailto:molecula2788@gmail.com" target="_blank">molecula2788@gmail.com</a>> a scris:<br>
>>> >>>> >> >> >>>><br>
>>> >>>> >> >> >>>> Salut,<br>
>>> >>>> >> >> >>>><br>
>>> >>>> >> >> >>>> M-am uitat și pare ok. O fi fost de la vmchecker.<br>
>>> >>>> >> >> >>>><br>
>>> >>>> >> >> >>>> On Sat, 30 Mar 2019 at 18:15, Ionuț Mihalache via so<br>
>>> >>>> >> >> >>>> <<a href="mailto:so@cursuri.cs.pub.ro" target="_blank">so@cursuri.cs.pub.ro</a>> wrote:<br>
>>> >>>> >> >> >>>> ><br>
>>> >>>> >> >> >>>> > Salut,<br>
>>> >>>> >> >> >>>> ><br>
>>> >>>> >> >> >>>> > 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?<br>
>>> >>>> >> >> >>>> > _______________________________________________<br>
>>> >>>> >> >> >>>> > <a href="http://ocw.cs.pub.ro/courses/so/info/lista-discutii" rel="noreferrer" target="_blank">http://ocw.cs.pub.ro/courses/so/info/lista-discutii</a><br>
>>> >>>> >> >> >><br>
>>> >>>> >> >> >> _______________________________________________<br>
>>> >>>> >> >> >> <a href="http://ocw.cs.pub.ro/courses/so/info/lista-discutii" rel="noreferrer" target="_blank">http://ocw.cs.pub.ro/courses/so/info/lista-discutii</a><br>
</blockquote></div>