Re: [so] [Tema 3][Genera] Punctaj

2020-05-28 Fir de Conversatie Mihai Barbulescu via so
Salut,

Asa cum s-a discutat si pe forum [1], decizia ramane neschimbata.
Regulamentul este destul de clar [2] in ce priveste deadline-urile
temelor.

[1] https://acs.curs.pub.ro/2019/mod/forum/discuss.php?d=4854
[2] https://ocw.cs.pub.ro/courses/so/meta/notare#intarzieri

On Wed, 27 May 2020 at 23:57, Theodor-Nicolae STOICA (78294) via so
 wrote:
>
> Salutare, asa cum mi s-a sugerat, vin cu rugamintea catre echipa de 
> responsabili de teme daca se poate, va rog frumos, tema3 de pe linux. Vin cu 
> precizarea
> ca, pe langa faptul ca am muncit mult, am rezolvat-o inaintea celei de pe 
> windows(cum fac toti,de altfel), insa cand am trimis, am testat-o doar pe cea 
> de pe win,
> depasind astfel deadline-ul hard cu 1 min(apoi am trimis alta arhiva depasind 
> cu 10 minute, dar se poate face revert) Readmeul este in arhiva de linux. Se 
> poate observa, de asemenea, data crearii fisierelor..Cunosc regulamentul, 
> insa avand in vedere cele mentionate, precum si faptul ca a existat 
> bunavointa la alte materii in situatii de genul, v-as ruga mult de tot sa se 
> ia in considerare.
> Stoica Theodor Nicolae
> 334CB
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][General] Programe open-source

2020-05-03 Fir de Conversatie Mihai Barbulescu via so
+ lista de discutii - foloseste butonul reply all

Singura idee care imi vine ca e \r\n pe Windows vs \n pe Unix - deci o
problema pe la terminatorii de linie.

Alte idei n-am in afara sa repari punctual erorile in masina virtuala
de windows si sa il faci fericit acolo.

On Sun, 3 May 2020 at 19:28, Dorin Geman  wrote:
>
> On Sun, May 3, 2020, 15:22 Dorin Geman via so  wrote:
>>
>> Salutare!
>>
>> Avem voie să folosim proiecte open-source cu licență MIT pentru lucruri 
>> extra, de genul parsatul unui fișier? Dacă da, checkpatch-ul nu va trece pe 
>> ele. Ce poate fi făcut în această situație?
>>
>> Zi frumoasă,
>> Dorin Geman
>
>
> On Sun, May 3, 2020 at 6:21 PM Mihai Barbulescu  wrote:
>>
>> Pai poți folosi atât timp cât menționezi sursa codului în Readme mai ales 
>> (pe lângă păstrarea licenței)
>>
>> Legat de checkpatch el le considera parte a sursei tale deci ori repari ori 
>> folosești o bucată rezonabilă din cod și repari problemele de checkpatch
>>
>>>
>>> ___
>>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
> Pe vmchecker am urcat aceeași arhiva pentru Linux și Windows, dar pe Windows 
> nu-mi trece checkstyle-ul.
> Idei?



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][General] Programe open-source

2020-05-03 Fir de Conversatie Mihai Barbulescu via so
Pai poți folosi atât timp cât menționezi sursa codului în Readme mai ales
(pe lângă păstrarea licenței)

Legat de checkpatch el le considera parte a sursei tale deci ori repari ori
folosești o bucată rezonabilă din cod și repari problemele de checkpatch

On Sun, May 3, 2020, 15:22 Dorin Geman via so  wrote:

> Salutare!
>
> Avem voie să folosim proiecte open-source cu licență MIT pentru lucruri
> extra, de genul parsatul unui fișier? Dacă da, checkpatch-ul nu va trece
> pe ele. Ce poate fi făcut în această situație?
>
> Zi frumoasă,
> Dorin Geman
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] Publicare Tema 4 - Planificator Threaduri

2020-04-12 Fir de Conversatie Mihai Barbulescu via so
Salut,

A fost publicată tema de casă numărul 4 - Planificator threaduri pe wiki [1].

Deadline-uri:

soft - 3 mai 2020, ora 23:55
hard - 10 mai 2020, ora 23:55

Nu uitați să testați implementarea voastră în mașinile virtuale [3]
înainte de a uploada pe vmchecker [4]. Testele sunt publice și sunt
disponibile pe GitHub [2] și pe pagina de wiki a temei.

Pe forum am creat 2 topicuri: 1 dedicat enuntului si 1 dedicat strict
infrastructurii unde vreau sa centralizam neclaritatile legate de
aceste 2 subiecte necesare realizarii temei. Pentru orice alta
problema puteti deschide thread nou sau puteti pune intrebarea pe
mailing list.

[1] https://ocw.cs.pub.ro/courses/so/teme/tema-4
[2] https://github.com/systems-cs-pub-ro/so-assignments
[3] http://ocw.cs.pub.ro/courses/so/info/mv
[4] https://vmchecker.cs.pub.ro/

-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] Laborator 335CB - cu Mihai Barbulescu

2020-03-16 Fir de Conversatie Mihai Barbulescu via so
Studentii de la grupa mea sunt rugati sa imi dea un email privat
intrucat MS teams este picat ASAP



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Corectare submisie diferita de cea finala

2020-03-15 Fir de Conversatie Mihai Barbulescu via so
Buna Anca,

Verifica acum si confirma-mi daca e totul ok

On Sun, 15 Mar 2020 at 14:33, Mihai Barbulescu  wrote:
>
> Finally acum îmi e clar. Când ajung la un calculator o fac. Dacă uit mai 
> dă-mi reminder privat
>
> On Sun, Mar 15, 2020, 14:28 Anca Millio  wrote:
>>
>> Buna ziua!
>>
>> Am observat ca acum pe vmchecker apare tot ultima versiune incarcata de 
>> mine, pe care nu o doresc.
>>
>> Doresc sa imi faceti revert daca se poate la versiunea incarcata miercuri, 
>> 11 martie, ora aproximativa 23:39.
>>
>> Imi cer scuze ca nu am fost suficient de clara.
>>
>> Multumesc pentru intelegere!
>> Anca Millio
>>
>>
>> On Sun, Mar 15, 2020 at 1:15 PM Mihai Barbulescu  wrote:
>>>
>>> Am facut revert pt 1-multi-linux si 1-multi-windows la versiunea
>>> "anterioara" (tot n-am inteles care e aia)
>>>
>>> Te rog zi-mi daca e totul in regula. Pe viitor foloseste butonul reply
>>> aall sa ajunga pe mailing list. Mailurile private le ratez.
>>>
>>> On Sat, 14 Mar 2020 at 11:31, Anca Millio  wrote:
>>> >
>>> > Buna ziua,
>>> >
>>> > 1. Da, la versiunea mentionata in mail-ul anterior.
>>> > 2. Daca va referiti la username-ul de cs.curs si vmchecker, atunci acesta 
>>> > este: anca.millio
>>> >
>>> > Multumesc,
>>> > Anca Millio
>>> >
>>> > > On Mar 13, 2020, at 17:03, Mihai Barbulescu  wrote:
>>> > >
>>> > > Nu am inteles nimic din toata povestea asa ca raspunde clar la
>>> > > urmatoarele 2 intrebari:
>>> > >
>>> > > 1. Vrei sa iti fac revert la o versiune anterioara?
>>> > > 2. Care e username-ul de LDAP?
>>> > >
>>> > >> On Fri, 13 Mar 2020 at 16:44, Anca Millio via so 
>>> > >>  wrote:
>>> > >>
>>> > >> Buna ziua!
>>> > >>
>>> > >> Am incarcat miercuri seara, pe vmchecker, o arhiva care lua 76 sau 74 
>>> > >> de puncte(nu mai stiu exact)si pe linux, si pe windows, cu toate ca 
>>> > >> local aveam 90 pe linux. Cred ca m-am incurcat in fisiere cand am 
>>> > >> facut arhiva, pentru ca aveam pe laptop mai multe versiuni. Am mai 
>>> > >> incercat sa fac modificari si sa incarc alte arhive chiar daca eram la 
>>> > >> limita de a avea intarziere de doua zile(ultimele doua au depasit ora 
>>> > >> 23:55), deoarece ar fi meritat sa iau 90 de puncte cu depunctare 10 
>>> > >> decat 74 cu depunctare 5. Din pacate nu am reusit sa iau mai mult de 
>>> > >> 74 pe windows si 90 pe linux. Asadar am ramas cu punctajul de la care 
>>> > >> pornisem, chiar daca acum aveam 90 pe linux, pt ca se alege minimul 
>>> > >> dintre ele, insa fiind trecut de ora 23:55, m-am ales si cu o 
>>> > >> depunctare mai mare.
>>> > >>
>>> > >> Intrebarea mea este : exista vreo sansa sa se poata corecta arhiva 
>>> > >> incarcata miercuri, 11 martie, ora aproximativa 23:39, in locul 
>>> > >> ultimei arhive incarcate? Nu stiu daca numele arhivei se pastreaza 
>>> > >> dupa incarcare, dar arhiva se numea: AncaMillio.zip .
>>> > >>
>>> > >> Multumesc,
>>> > >>
>>> > >> Anca Millio
>>> > >>
>>> > >> ___
>>> > >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > 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

Re: [so] Corectare submisie diferita de cea finala

2020-03-15 Fir de Conversatie Mihai Barbulescu via so
Finally acum îmi e clar. Când ajung la un calculator o fac. Dacă uit mai
dă-mi reminder privat

On Sun, Mar 15, 2020, 14:28 Anca Millio  wrote:

> Buna ziua!
>
> Am observat ca acum pe vmchecker apare tot ultima versiune incarcata de
> mine, pe care nu o doresc.
>
> Doresc sa imi faceti revert daca se poate la versiunea incarcata miercuri,
> 11 martie, ora aproximativa 23:39.
>
> Imi cer scuze ca nu am fost suficient de clara.
>
> Multumesc pentru intelegere!
> Anca Millio
>
>
> On Sun, Mar 15, 2020 at 1:15 PM Mihai Barbulescu 
> wrote:
>
>> Am facut revert pt 1-multi-linux si 1-multi-windows la versiunea
>> "anterioara" (tot n-am inteles care e aia)
>>
>> Te rog zi-mi daca e totul in regula. Pe viitor foloseste butonul reply
>> aall sa ajunga pe mailing list. Mailurile private le ratez.
>>
>> On Sat, 14 Mar 2020 at 11:31, Anca Millio  wrote:
>> >
>> > Buna ziua,
>> >
>> > 1. Da, la versiunea mentionata in mail-ul anterior.
>> > 2. Daca va referiti la username-ul de cs.curs si vmchecker, atunci
>> acesta este: anca.millio
>> >
>> > Multumesc,
>> > Anca Millio
>> >
>> > > On Mar 13, 2020, at 17:03, Mihai Barbulescu 
>> wrote:
>> > >
>> > > Nu am inteles nimic din toata povestea asa ca raspunde clar la
>> > > urmatoarele 2 intrebari:
>> > >
>> > > 1. Vrei sa iti fac revert la o versiune anterioara?
>> > > 2. Care e username-ul de LDAP?
>> > >
>> > >> On Fri, 13 Mar 2020 at 16:44, Anca Millio via so <
>> so@cursuri.cs.pub.ro> wrote:
>> > >>
>> > >> Buna ziua!
>> > >>
>> > >> Am incarcat miercuri seara, pe vmchecker, o arhiva care lua 76 sau
>> 74 de puncte(nu mai stiu exact)si pe linux, si pe windows, cu toate ca
>> local aveam 90 pe linux. Cred ca m-am incurcat in fisiere cand am facut
>> arhiva, pentru ca aveam pe laptop mai multe versiuni. Am mai incercat sa
>> fac modificari si sa incarc alte arhive chiar daca eram la limita de a avea
>> intarziere de doua zile(ultimele doua au depasit ora 23:55), deoarece ar fi
>> meritat sa iau 90 de puncte cu depunctare 10 decat 74 cu depunctare 5. Din
>> pacate nu am reusit sa iau mai mult de 74 pe windows si 90 pe linux. Asadar
>> am ramas cu punctajul de la care pornisem, chiar daca acum aveam 90 pe
>> linux, pt ca se alege minimul dintre ele, insa fiind trecut de ora 23:55,
>> m-am ales si cu o depunctare mai mare.
>> > >>
>> > >> Intrebarea mea este : exista vreo sansa sa se poata corecta arhiva
>> incarcata miercuri, 11 martie, ora aproximativa 23:39, in locul ultimei
>> arhive incarcate? Nu stiu daca numele arhivei se pastreaza dupa incarcare,
>> dar arhiva se numea: AncaMillio.zip .
>> > >>
>> > >> Multumesc,
>> > >>
>> > >> Anca Millio
>> > >>
>> > >> ___
>> > >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>> > >
>> > >
>> > >
>> > > --
>> > > Cu stimă,
>> > > Mihai Bărbulescu
>>
>>
>>
>> --
>> Cu stimă,
>> Mihai Bărbulescu
>>
>
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Corectare submisie diferita de cea finala

2020-03-15 Fir de Conversatie Mihai Barbulescu via so
Am facut revert pt 1-multi-linux si 1-multi-windows la versiunea
"anterioara" (tot n-am inteles care e aia)

Te rog zi-mi daca e totul in regula. Pe viitor foloseste butonul reply
aall sa ajunga pe mailing list. Mailurile private le ratez.

On Sat, 14 Mar 2020 at 11:31, Anca Millio  wrote:
>
> Buna ziua,
>
> 1. Da, la versiunea mentionata in mail-ul anterior.
> 2. Daca va referiti la username-ul de cs.curs si vmchecker, atunci acesta 
> este: anca.millio
>
> Multumesc,
> Anca Millio
>
> > On Mar 13, 2020, at 17:03, Mihai Barbulescu  wrote:
> >
> > Nu am inteles nimic din toata povestea asa ca raspunde clar la
> > urmatoarele 2 intrebari:
> >
> > 1. Vrei sa iti fac revert la o versiune anterioara?
> > 2. Care e username-ul de LDAP?
> >
> >> On Fri, 13 Mar 2020 at 16:44, Anca Millio via so  
> >> wrote:
> >>
> >> Buna ziua!
> >>
> >> Am incarcat miercuri seara, pe vmchecker, o arhiva care lua 76 sau 74 de 
> >> puncte(nu mai stiu exact)si pe linux, si pe windows, cu toate ca local 
> >> aveam 90 pe linux. Cred ca m-am incurcat in fisiere cand am facut arhiva, 
> >> pentru ca aveam pe laptop mai multe versiuni. Am mai incercat sa fac 
> >> modificari si sa incarc alte arhive chiar daca eram la limita de a avea 
> >> intarziere de doua zile(ultimele doua au depasit ora 23:55), deoarece ar 
> >> fi meritat sa iau 90 de puncte cu depunctare 10 decat 74 cu depunctare 5. 
> >> Din pacate nu am reusit sa iau mai mult de 74 pe windows si 90 pe linux. 
> >> Asadar am ramas cu punctajul de la care pornisem, chiar daca acum aveam 90 
> >> pe linux, pt ca se alege minimul dintre ele, insa fiind trecut de ora 
> >> 23:55, m-am ales si cu o depunctare mai mare.
> >>
> >> Intrebarea mea este : exista vreo sansa sa se poata corecta arhiva 
> >> incarcata miercuri, 11 martie, ora aproximativa 23:39, in locul ultimei 
> >> arhive incarcate? Nu stiu daca numele arhivei se pastreaza dupa incarcare, 
> >> dar arhiva se numea: AncaMillio.zip .
> >>
> >> Multumesc,
> >>
> >> Anca Millio
> >>
> >> ___
> >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> >
> >
> >
> > --
> > Cu stimă,
> > Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema 2][README] 2x README

2020-03-14 Fir de Conversatie Mihai Barbulescu via so
la README puteti avea acelasi fisier sa fie identic pe cele doua
platforme, dar asigurati-va ca fiecare arhiva il are.

On Sat, 14 Mar 2020 at 21:28, Paul Olaru via so  wrote:
>
> Un singur fișier README este suficient cu excepția cazului în care ai 
> variații suficient de mari să fie nevoie să le scrii într-un alt fișier.
>
> Dacă diferențele le poți exprima în câteva fraze un singur fișier e destul. 
> Dacă diferențele sunt suficient de mari în implementarea ta încât să merite o 
> discuție separată poți avea fișiere suplimentare.
>
> On Sat, Mar 14, 2020, 21:26 Antonio-Dan MACOVEI (94298) via so 
>  wrote:
>>
>> Buna seara,
>>
>> Este nevoie de 2x fisiere README, cate unul pentru fiecare platforma, sau 
>> putem sa il folosim pe acelasi scris astfel incat sa cuprinda ambele 
>> implementari? Ma gandesc ca ar fi la fel intr-o proportie foarte mare.
>>
>> Multumesc,
>> Antonio Macovei, 334CA
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Corectare submisie diferita de cea finala

2020-03-13 Fir de Conversatie Mihai Barbulescu via so
Nu am inteles nimic din toata povestea asa ca raspunde clar la
urmatoarele 2 intrebari:

1. Vrei sa iti fac revert la o versiune anterioara?
2. Care e username-ul de LDAP?

On Fri, 13 Mar 2020 at 16:44, Anca Millio via so  wrote:
>
> Buna ziua!
>
> Am incarcat miercuri seara, pe vmchecker, o arhiva care lua 76 sau 74 de 
> puncte(nu mai stiu exact)si pe linux, si pe windows, cu toate ca local aveam 
> 90 pe linux. Cred ca m-am incurcat in fisiere cand am facut arhiva, pentru ca 
> aveam pe laptop mai multe versiuni. Am mai incercat sa fac modificari si sa 
> incarc alte arhive chiar daca eram la limita de a avea intarziere de doua 
> zile(ultimele doua au depasit ora 23:55), deoarece ar fi meritat sa iau 90 de 
> puncte cu depunctare 10 decat 74 cu depunctare 5. Din pacate nu am reusit sa 
> iau mai mult de 74 pe windows si 90 pe linux. Asadar am ramas cu punctajul de 
> la care pornisem, chiar daca acum aveam 90 pe linux, pt ca se alege minimul 
> dintre ele, insa fiind trecut de ora 23:55, m-am ales si cu o depunctare mai 
> mare.
>
> Intrebarea mea este : exista vreo sansa sa se poata corecta arhiva incarcata 
> miercuri, 11 martie, ora aproximativa 23:39, in locul ultimei arhive 
> incarcate? Nu stiu daca numele arhivei se pastreaza dupa incarcare, dar 
> arhiva se numea: AncaMillio.zip .
>
> Multumesc,
>
> Anca Millio
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Folosire Microsoft Teams pentru activitati online

2020-03-11 Fir de Conversatie Mihai Barbulescu via so
On Wed, 11 Mar 2020 at 18:12, Razvan Deaconescu via so
 wrote:
>
> Razvan Deaconescu  writes:
> > Salutare.
> >
> > Pentru foarte probabilele activități online pe care le vom desfășura la
> > cursul de Sisteme de operare, vom folosi Microsoft Teams[1]. Puteți
> > folosi varianta din browser sau varianta desktop.
> >
> > Pentru a accesa echipa "Sisteme de operare (CTI, ACS, UPB)" unde vom
> > desfășura activitățile, folosiți link-ul acesta[2]. Vom filma cursul de
> > azi, miercuri, 11 martie 2020, 18:00-20:00, PR001 de la seria 3CC și va
> > fi disponibil pe canalul "Curs 3CC".
>
> Greșisem link-ul[2. Cel corect este acesta[3].
>
> > [1] https://teams.microsoft.com/
> > [2]
> > https://teams.microsoft.com/l/team/19%3ae58fbcea3d8d40c0bb869773af7fbd2a%40thread.tacv2/conversations?groupId=a1157cc5-4740-4261-b2b1-fe9a6c8a17ff&tenantId=2d8cc8ba-8dda-4334-9e5c-fac2092e9bac
>
> [3] 
> https://teams.microsoft.com/l/team/19%3a92cca3c153db4c45b0dd2c035d9061a1%40thread.tacv2/conversations?groupId=08eed8bc-32a9-4ebd-906c-344630ea2522&tenantId=2d8cc8ba-8dda-4334-9e5c-fac2092e9bac
>

Pentru studentii de luni 18-20 (335CB) care fac cu mine: Va rog sa imi
dati email __privat__ cei care sunteti la grupele mele daca nu ati
fost adaugati in echipa. In emailul privat vreau: adresa de email
@stud.acs.upb.ro - daca nu va functioneaza am mai rezolvat pe cineva -
stipulati in mail ce nu va merge la loginul prin office 365 (probleme
n-ar trebui sa fie).

Daca ati intrat deja va rog sa confirmati prin like react la mesajele
mele de pe canal.


-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema1] Lipsa teste Vmchecker Windows

2020-03-11 Fir de Conversatie Mihai Barbulescu via so
Faptul ca iti lipsesc pe vmchecker inseamna ca aplicatia ta pe undeva
se blocheaza. Cativa pasi pe care ar trebui sa ii faci:

1. Asigura-te ca masinii virtuale de SO de Windows nu i-ai alocat mai
multe resurse din Vmware decat cele cu care vine ea default
2. Verifica-ti accesele invalide la memorie cu gdb/valgrind
3. Verifica-ti leak-urile de memorie cu valgrind --leak-check=full
4. Asigura-te ca toate apelurile de malloc/calloc/fopen le verifici
pentru erori de NULL pointers

Punctele 2. si 3. le poti rezolva doar daca ai compilat cu -g tema ta.

Testele 2-4 le poti face si pe Linux.

On Wed, 11 Mar 2020 at 11:51, Andreea Sandru via so
 wrote:
>
> Buna ziua!
>
> Imi lipsesc testele de la 24 in sus pe Vmchecker pe Windows. Am rulat tema pe 
> masina virtuala de la SO de Windows si primesc acelasi punctaj ca pe Linux. 
> Intrucat pare o problema care tine de Vmchecker, ce ar trebui sa fac in 
> continuare?
>
> Multumesc anticipat,
> Andreea Sandru, 335CB
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Test38] calloc nu intoarce NULL

2020-03-09 Fir de Conversatie Mihai Barbulescu via so
Imi poti spune __ce__ returneaza calloc?

Alternativ (si nu vad o problema) poti face:
- malloc
- memset(your_ptr, 0, sizeof(your_ptr_datatype))

Checkerul din cate stiu face LD_PRELOAD la malloc dar nu si la calloc,
asa ca mai multe informatii ne-ar ajuta

On Mon, 9 Mar 2020 at 12:41, Dorin Geman via so  wrote:
>
> Salut,
>
> La testul 38, in (mini-preprocessor.c, 17), calloc-ul nu întoarce NULL, drept 
> urmare nu pot ieși cu return code-ul 12.
> Dacă înlocuiesc calloc-ul cu malloc-ul, treaba merge bine.
> Aveți idee care ar putea fi problema?
> Nici dacă fac un if pentru a testa dacă acel pointer este NULL nu trece de 
> acea parte.
>
> Mulțumesc și o zi frumoasă,
> Dorin Geman
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][General] Folosire macro DIE

2020-03-08 Fir de Conversatie Mihai Barbulescu via so
da, e ok

vezi si indicatiile de aici:
https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die - in special
partea cu "alta abordare"

On Sun, 8 Mar 2020 at 14:35, Mihaila Corina via so  wrote:
>
> Buna ziua!
>
> Este in regula daca folosim DIE dupa fiecare alocare dinamica nereusita?
> Sau o sa ni se scada pentru ca nu dezalocam resursele inainte de a da exit?
>
> Mihaila Corina, 335CB
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Windows] Standard C89

2020-03-05 Fir de Conversatie Mihai Barbulescu via so
Salut,

Eu totusi te rog sa mentionezi in feedback nu doar experienta cu C89
ci si experienta ta cu Windows programming: ti-a fost utila? ai
invatat ceva util pentru viitor? etc.

On Thu, 5 Mar 2020 at 12:03, David Gherghita via so
 wrote:
>
> Salutare,
>
> Multumesc mult pentru raspunsul detaliat. Acum am inteles motivatia din 
> spatele acestei decizii si o sustin.
>
> Cat despre necesitatea punctarii acestui lucru in formularul de feedback, am 
> ajuns la concluzia ca in timpul cat mi-a luat sa scriu mail-urile as fi 
> terminat cu usurinta transformarea codului, deci nu il consider necesar.
>
> O zi placuta,
> Gherghita David, 334CA
>
> On Thu, Mar 5, 2020 at 12:26 AM Razvan Crainea  
> wrote:
>>
>> Salut, David!
>>
>> Standardele C99 și C11 vin cu o serie de îmbunătățiri ale calității
>> codului, doar că acestea sunt în detrimentul portabilității.
>> Dacă vrei să scrii o aplicație de uz general, care să poată fi
>> folosita de oricine, atunci vrei ca ea să fie cât mai portabilă, să
>> poată fi compilată pe cât mai multe platforme, ideal pe toate. Atunci
>> ai de făcut un compromis: A) fie scrii cod conform standardelor celor
>> mai răspândite, în cazul de față un standard adoptat de peste 20 de
>> ani (C89), B) fie limitezi persoanele care folosesc niște
>> sisteme/compilatoare mai vechi să folosească aplicația ta. Costul
>> variantei A) este declararea unor variabile câteva linii mai sus, sau
>> folosirea lui alloca() vs variable-length arrays (C99), comparativ cu
>> B) imposibilitatea de a rula aplicația ta pe anumite sisteme. Dacă
>> scopul tău este ca aplicația să fie cât mai larg folosită, atunci
>> consider că A) este varianta preferată. Dacă scopul tau este să
>> termini cât mai repede implementarea, să poți rula aplicația, dar ea
>> să fie folosită doar de tine, atunci poți alege B).
>> În cadrul cursului de SO încurajăm dezvoltarea cât mai generică și
>> portabilă a aplicațiilor, de aceea încurajăm dezvoltarea folosind
>> standardul C89.
>>
>> Am notat feedback-ul legat de faptul că nu este specificat explicit în
>> temă că trebuie să folosiți standardul c89, mulțumim pentru
>> atenționare! Dacă într-adevăr este o problemă atât de mare pentru
>> tine, te rog să punctezi acest lucru în forumularul de feedback pe
>> care o să-l primiți la final de semestru.
>>
>> Spor la temă,
>> Răzvan
>>
>> On Wed, Mar 4, 2020 at 11:29 PM David Gherghita via so
>>  wrote:
>> >
>> > Multumesc pentru raspuns, o sa o transform in C89. Mi s-ar fi parut 
>> > normal, totusi, ca acest aspect sa fie precizat in cerinta (am vazut ca 
>> > este in FAQ o intrebare referitoare la asta dar nu mi se pare suficient).
>> >
>> > Din cate am vazut nici versiunile mai noi de Visual Studio nu ofera suport 
>> > pentru c99 sau c11, pentru ca cl e focusat pe c++, si nu mi se pare ok sa 
>> > fie nevoie sa folosim un standard atat de vechi, avand in vedere ca 
>> > versiunile noi au adus multe imbunatatiri.
>> >
>> > On Wed, Mar 4, 2020 at 11:14 PM Paul Olaru  
>> > wrote:
>> >>
>> >> Din păcate trebuie făcută în C89 tema asta (și eu m-am confruntat cu asta 
>> >> anul trecut).
>> >>
>> >>
>> >>
>> >> (de ar fi mai actualizate mașinile virtuale să nu mai fie Visual Studio 
>> >> 2010 ci 2017 care
>> >>
>> >> are un compilator mai modern...)
>> >>
>> >>
>> >>
>> >> Eu personal recomand să pui -std=c89 pe compilerul gcc pe Linux pt că 
>> >> acesta dă erori
>> >>
>> >> mai clare decât cel de Windows când, spre ex, ai declarații amestecate cu 
>> >> restul codului.
>> >>
>> >>
>> >>
>> >> Sent from Mail for Windows 10
>> >>
>> >>
>> >>
>> >> From: David Gherghita via so
>> >> Sent: Wednesday, March 4, 2020 11:11 PM
>> >> To: so@cursuri.cs.pub.ro
>> >> Subject: [so] [Tema1][Windows] Standard C89
>> >>
>> >>
>> >>
>> >> Salutare,
>> >>
>> >>
>> >>
>> >> In urma obtinerii cu succes a punctajului maxim pe linux, compiland codul 
>> >> cu standardul C11, la testarea pe windows am observat extrem de mult 
>> >> erori de compilare, datorate folosirii de cl a standardului C89.
>> >>
>> >>
>> >>
>> >> Cautand pe net cum pot seta folosirea unui standard mai nou, am inteles 
>> >> ca nu se poate. Sper totusi ca acest lucru sa nu fie adevarat, deoarece 
>> >> nu inteleg de ce s-ar alege pt SO pe windows acest compilator de la 
>> >> microsoft care nu suporta versiuni mai noi de C, avand in vedere 
>> >> multitudinea de alternative disponibile.
>> >>
>> >>
>> >>
>> >> Multumesc,
>> >>
>> >> Gherghita David
>> >>
>> >>
>> >
>> > ___
>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>>
>> --
>> Răzvan Crainea
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux]Diferenta rulare checker

2020-03-04 Fir de Conversatie Mihai Barbulescu via so
Buna Andreea,

Sa inteleg ca e problema din cauza spatiului si VAR0 in loc de VAR?

Verifica ce-a zis Razvan eventual ruland cu scriptul ./run_all.sh sau
rulandu-ti tema dintr-un mic script de bash care ruleaza ./so-cpp
test9.in

On Wed, 4 Mar 2020 at 08:40, Deea O  wrote:
>
> Buna,
>
> Acestea sunt output-urile pentru test9.
> - rezultatul in urma ruralii ./so-cpp test9.in:
>
> int main() {
>  int y = 1 + 1;
>  printf("%d\n", 1);
>  printf("%d\n", VAR0);
>
>  return 0;
> }
>
> - diff-ul checkerului:
> -
>  int main() {
>   int y = 1 + 1;
>   printf("%d\n", 1);
> - printf("%d\n", 1);
> -
> +printf("%d\n", VAR));
>
> On Tue, 3 Mar 2020 at 21:21, Deea O  wrote:
> >
> > Imi cer scuze, am o problema cu conexiunea la Internet pe laptop si  am 
> > preferat sa trimit cat mai rapid un raspuns. Voi retrimite indata ce am 
> > posibilitatea.
> >
> > On Tue, 3 Mar 2020 at 21:18, Mihai Barbulescu  wrote:
> >>
> >> Gaseste o metoda prin care sa dai copy paste la outputuri sau print screen 
> >> (snipping tool) si sa le urci pe un server de imagini eu nu pot sa 
> >> urmaresc imaginile astea oribile de pe telefon. Eu nu o sa stau sa 
> >> descifrez pozele alea embed html pe care nici nu le pot descarca in 
> >> calculator.
> >>
> >>
> >> --
> >> Cu stimă,
> >> Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][General] Checkpatch si const struct

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Folosește butonul reply all

Nu știam că ai rulat checkpatch în loc de wrapper. El e făcut de echipa de
so tocmai pentru scopurile de la noi.

E foarte interesant ca cel original da astfel de erori, ia să văd de ce
vrea așa ceva.

În general nu recomand typedef pentru că atunci când citești cod mare vrei
sa distingi struct de tip de date simplu cum ar fi uint8_t


On Tue, Mar 3, 2020, 22:27 Alin-Andrei GEORGESCU (94722) <
alin.george...@stud.acs.upb.ro> wrote:

> Ba uite ca dădea warningul acela, cerând să fie const, pe structura „kkmk”,
> așa simplă cum e ea. Mai dădea și pentru node, că nu prea îi plăceau
> typedef-urile, dar asta nu era o problemă așa mare, având alternativă. Am
> rezolvat chestiunile prin rularea wrapperului, care dă mult mai puține
> warninguri și erori decât rularea directă a checkpatch.pl, am specificat
> pe forum.
>
>
>
> Seară bună!
>
>
>
> *From: *Mihai Barbulescu 
> *Sent: *marți, 3 martie 2020 21:37
> *To: *Paul Olaru ; Sisteme de Operare
> 
> *Cc: *Alin-Andrei GEORGESCU (94722) 
> *Subject: *Re: [so] [Tema1][General] Checkpatch si const struct
>
>
>
> Ce inseamna "map-ul se modifica si nu ramane constant"? Ca asta e
> tautologie.
>
> Poti arata aici cam cum arata structura sa imi dau si eu seama despre
> ce e vorba. Ca idee daca ai
>
> struct kkmk {
> int data;
> struct kkmk *next;
> }
>
> typedef struct node {
> int val;
> struct node *next;
> } node_t
>
> Nu ar trebui sa dea erorarea respectiva deci 
>
> Asta daca nu cumva te-ai apucat sa imi declari structuri const precum
> obiectele prin C++ motiv pentru care urla warningul. Aici nu avem
> referinte "imutabile" - in C ai doar pass by value sau pass by
> pointer.
>
> On Mon, 2 Mar 2020 at 22:39, Paul Olaru via so 
> wrote:
> >
> > Această eroare în particular poate fi ignorată. Vezi de restul dacă ai.
> >
> >
> >
> > From: Alin-Andrei GEORGESCU (94722) via so
> > Sent: Monday, March 2, 2020 10:38 PM
> > To: so@cursuri.cs.pub.ro
> > Subject: [so] [Tema1][General] Checkpatch si const struct
> >
> >
> >
> > Salut!
> >
> >
> >
> > În implementarea hashmapului am folosit structuri, însă checkpatch are
> un warning atunci când folosesc structuri care nu sunt constante (WARNING:
> struct  should normally be const). Ce ar trebui să fac în cazul acesta,
> ținând cont că mapul se modifică și nu rămâne constant?
> >
> >
> >
> > Mulțumesc,
> >
> > Georgescu Alin
> >
> > 335CA
> >
> >
> >
> > ___
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu
>
>
>
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][General] Checkpatch si const struct

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Ce inseamna "map-ul se modifica si nu ramane constant"? Ca asta e tautologie.

Poti arata aici cam cum arata structura sa imi dau si eu seama despre
ce e vorba. Ca idee daca ai

struct kkmk {
int data;
struct kkmk *next;
}

typedef struct node {
int val;
struct node *next;
} node_t

Nu ar trebui sa dea erorarea respectiva deci 

Asta daca nu cumva te-ai apucat sa imi declari structuri const precum
obiectele prin C++ motiv pentru care urla warningul. Aici nu avem
referinte "imutabile" - in C ai doar pass by value sau pass by
pointer.

On Mon, 2 Mar 2020 at 22:39, Paul Olaru via so  wrote:
>
> Această eroare în particular poate fi ignorată. Vezi de restul dacă ai.
>
>
>
> From: Alin-Andrei GEORGESCU (94722) via so
> Sent: Monday, March 2, 2020 10:38 PM
> To: so@cursuri.cs.pub.ro
> Subject: [so] [Tema1][General] Checkpatch si const struct
>
>
>
> Salut!
>
>
>
> În implementarea hashmapului am folosit structuri, însă checkpatch are un 
> warning atunci când folosesc structuri care nu sunt constante (WARNING: 
> struct  should normally be const). Ce ar trebui să fac în cazul acesta, 
> ținând cont că mapul se modifică și nu rămâne constant?
>
>
>
> Mulțumesc,
>
> Georgescu Alin
>
> 335CA
>
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux]Diferenta rulare checker

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Ai cum sa ne arati diferentele de output __de pe masina virtuala__ ?
Nu imi este clar care e problema

On Tue, 3 Mar 2020 at 17:16, Deea O  wrote:
>
> Da
>
> On Tue, 3 Mar 2020 at 17:13, Mihai Barbulescu  wrote:
>>
>> Testele le rulezi pe mașina virtuala livrata de echipa de so?
>>
>> Cu stimă,
>> Mihai Bărbulescu
>>
>>
>>  Original message 
>> From: Deea O via so 
>> Date: Tue, Mar 3, 2020, 16:24
>> To: so@cursuri.cs.pub.ro
>> Subject: [so] [Tema1][Linux]Diferenta rulare checker
>>
>> Buna,
>>
>> În cadrul temei am întâmpinat următoarea problemă pentru testele 9 si
>> 29. În momentul în care rulez tema utilizând ./so-cpp test9.in,
>> rezultatul este cel corect, dar atunci când testez folosind checkerul
>> (./run_all.sh), outputul pentru cele doua teste este unul diferit, în
>> sensul că încă realizează înlocuirea deși am realizat undef.
>> Comportamentul este diferit doar la rulare, executabilul este exact
>> același.
>>
>> Cum aș putea să procedez?
>>
>> Am urcat pe GitLab codul (branch test), iar ldap-ul meu este
>> Andreea-Diana OLTEAN (94622)
>>
>> Multumesc,
>> Andreea-Diana Oltean
>>
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux] Segfault checker test38

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Salut
Folosește butonul de reply all data viitoare

Ma bucur ca te-a ajutat sugestia mea


On Tue, Mar 3, 2020, 18:04 David Gherghita  wrote:

> Multumesc mult, am analizat dump-ul cu gdb si am gasit cauza. Ramasese un
> malloc la care uitasem sa verific valoarea de retur.
>
> On Tue, Mar 3, 2020 at 5:28 PM Mihai Barbulescu 
> wrote:
>
>> Salut,
>>
>> Primul pas este sa rulezi pe mașina virtuală
>>
>> Al doilea e sa nu folosești valgrind sau gdb, sa rulezi binarul tău, sa
>> te asiguri ca sistemul generează core dump file și sa analizezi offline în
>> gdb core dump
>>
>> Lucrez (dar nu am timp) la o pagină care să exemplifice ce zic mai sus ca
>> să știți mai ușor ce să căutați
>>
>> Cu stimă,
>> Mihai Bărbulescu
>>
>>
>>  Original message 
>> From: David Gherghita via so 
>> Date: Tue, Mar 3, 2020, 17:14
>> To: so@cursuri.cs.pub.ro
>> Subject: [so] [Tema1][Linux] Segfault checker test38
>>
>> Salutare,
>>
>> La rularea checkerului primesc segfault pe testul 38. La rularea manuala
>> a comenzii, cu argumentele mentionate in fisierul test38.param:
>> ./so-cpp -D DEBUG=1 -D CUSTOM_DBG=custom-debugging -I
>> _test/inputs/test38.dir _test/inputs/test38.in > _test/outputs/test38.out
>> nu primesc segfault, nu returneaza nicio eroare cu valgrind si se creeaza
>> fisierul de iesire corect.
>>
>> Ce face diferit checkerul fata de aceasta comanda? Adica, cum as putea
>> replica comportamentul checkerului, ca sa pot identifica cauza
>> segfault-ului?
>>
>> Multumesc,
>> David Gherghita, 334CA
>>
>>
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux] Segfault checker test38

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Salut, Primul pas este sa rulezi pe mașina virtualăAl doilea e sa nu folosești valgrind sau gdb, sa rulezi binarul tău, sa te asiguri ca sistemul generează core dump file și sa analizezi offline în gdb core dump Lucrez (dar nu am timp) la o pagină care să exemplifice ce zic mai sus ca să știți mai ușor ce să căutați Cu stimă,Mihai Bărbulescu Original message From: David Gherghita via so Date: Tue, Mar 3, 2020, 17:14To: so@cursuri.cs.pub.roSubject: [so] [Tema1][Linux] Segfault checker test38Salutare,La rularea checkerului primesc segfault pe testul 38. La rularea manuala a comenzii, cu argumentele mentionate in fisierul test38.param:./so-cpp -D DEBUG=1 -D CUSTOM_DBG=custom-debugging -I _test/inputs/test38.dir _test/inputs/test38.in > _test/outputs/test38.outnu primesc segfault, nu returneaza nicio eroare cu valgrind si se creeaza fisierul de iesire corect.Ce face diferit checkerul fata de aceasta comanda? Adica, cum as putea replica comportamentul checkerului, ca sa pot identifica cauza segfault-ului?Multumesc,David Gherghita, 334CA
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux]Diferenta rulare checker

2020-03-03 Fir de Conversatie Mihai Barbulescu via so
Testele le rulezi pe mașina virtuala livrata de echipa de so? Cu stimă,Mihai Bărbulescu Original message From: Deea O via so Date: Tue, Mar 3, 2020, 16:24To: so@cursuri.cs.pub.roSubject: [so] [Tema1][Linux]Diferenta rulare checkerBuna,În cadrul temei am întâmpinat următoarea problemă pentru testele 9 si29. În momentul în care rulez tema utilizând ./so-cpp test9.in,rezultatul este cel corect, dar atunci când testez folosind checkerul(./run_all.sh), outputul pentru cele doua teste este unul diferit, însensul că încă realizează înlocuirea deși am realizat undef.Comportamentul este diferit doar la rulare, executabilul este exactacelași.Cum aș putea să procedez?Am urcat pe GitLab codul (branch test), iar ldap-ul meu esteAndreea-Diana OLTEAN (94622)Multumesc,Andreea-Diana Oltean___http://ocw.cs.pub.ro/courses/so/info/lista-discutii___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux] Import failed in VMWare

2020-03-02 Fir de Conversatie Mihai Barbulescu via so
Nu va mai temeti

Incercati, stricati-le, scrieti-ne ce ati facut aici.

Nu aveti la ce sa dati foc

Spor!

On Sun, 1 Mar 2020 at 15:27, Antonio-Dan MACOVEI (94298)
 wrote:
>
> Am incercat acum si a mers. Citisem in mesajul de eroare ca daca as da retry 
> nu ar mai functiona corect si nu am incercat din prima.
>
> Mersi,
> Antonio Macovei
>
> Get Outlook for Android
>
> 
> From: Mihai Barbulescu 
> Sent: Sunday, March 1, 2020 9:53:12 AM
> To: Antonio-Dan MACOVEI (94298) ; 
> Sisteme de Operare 
> Subject: Re:[so] [Tema1][Linux] Import failed in VMWare
>
> Ai apăsat acel buton de retry? Ce se întâmplă când îl apeși?
>
> Cu stimă,
> Mihai Bărbulescu
>
>
>  Original message 
> From: "Antonio-Dan MACOVEI (94298) via so" 
> Date: Sat, Feb 29, 2020, 22:11
> To: so@cursuri.cs.pub.ro
> Subject: [so] [Tema1][Linux] Import failed in VMWare
>
> Buna seara,
>
> Am tot incercat sa import masina virtuala de Linux descarcata din 
> repository-ul oficial de SO in VMWare Player (v 12 si 15.5) si mereu primesc 
> aceasta eroare:
>
> The import failed because so-ubuntu-18-04.ova did not pass OVF specification 
> conformance or virtual hardware compliance checks.
> Click Retry to relax OVF specification and virtual hardware compliance checks 
> and try the import again, or click Cancel to cancel the import. If you retry 
> the import, you might not be able to use the virtual machine in VMware Player.
>
> Din ce am inteles de pe internet, problema ar fi ca masina a fost exportata 
> din VirtualBox si nu e compatibila cu VMWare, insa pe ocw scrie ca ar trebui 
> sa fie. Fac eu ceva gresit?
>
> Multumesc,
> Antonio Macovei, 334CA



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema1] Neclaritate enunt - parsare argumente

2020-03-02 Fir de Conversatie Mihai Barbulescu via so
Salut,

Da este GNU dar poti cauta portari pentru windows si regulamentul nu
interzice folosirea unui cod existent atat timp cat pastrati
copyright-ul si mentionati clar si explicit sursa:
https://gist.github.com/superwills/5815344
Teoretic exista si o implementare a Microsoft:
https://github.com/iotivity/iotivity/tree/master/resource/c_common/windows

Sugeram de getopt mai mult ca sa va luati subsetul relevant pentru
tema si sa-l faceti portabil daca cu strcmp e chinuiala mare.

Codul pt structuri de date n-aveti voie sa il copiati in tema asta.


On Sun, 1 Mar 2020 at 15:21, Pasmangia Ovidiu  wrote:
>
> Functia getopt functioneaza atat pe linux cat si pe windows? Din ce am vazut, 
> ea este doar pt linux.
>
> Sent from Yahoo Mail on Android
>
> On Sat, 29 Feb 2020 at 21:36, Mihai Barbulescu via so
>  wrote:
> On Sat, 29 Feb 2020 at 10:10, Mihaila Corina via so
>  wrote:
> >
> > test1.param: bad.file
> > Ar trebui considerat un fisier de input valid si deschis?
>
> Parsezi argumentul, nu merge deschis fisierul - pica programul cu eroare
>
> >
> > test2.param: -X bad param
> >  Aici -X bad trebuie ignorat, iar param e un fisier de input?
> > Sau ignor toata linia in momentul in care gasesc un alt parametru decat -D, 
> > -o, -I?
>
> iei in seama -X da daca parametrul e gresit treci la urmatorii. In C
> puteti folosi getopt pt a va face viata usoara
>
> >
> > test3.param: _test/inputs/test3.in test3.out test3.err
> >  Aici deschid un fisier de input si 2 de output sau e o linie nevalida si 
> > programul
> >  nu trebuie sa faca nimic?
>
> Jur ca nu am inteles intrebarea ta: formuleaz-o mai clar. In enunt
> zice destul de clar:
>
> so-cpp [-D [=]] [-I ] [] [ [-o] ]
>
> test3.err il poti ignora conform  cu aceasta semnatura. Vezi si in
> sursele testului ce face eu daca ar fi sa implementez comanda asa as
> face programul sa pice.
>
>
> --
> Cu stimă,
> Mihai Bărbulescu
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1][Linux] Import failed in VMWare

2020-02-29 Fir de Conversatie Mihai Barbulescu via so
Ai apăsat acel buton de retry? Ce se întâmplă când îl apeși? Cu stimă,Mihai Bărbulescu Original message From: "Antonio-Dan MACOVEI (94298) via so" Date: Sat, Feb 29, 2020, 22:11To: so@cursuri.cs.pub.roSubject: [so] [Tema1][Linux] Import failed in VMWare

Buna seara,




Am tot incercat sa import masina virtuala de Linux descarcata din repository-ul oficial de SO in VMWare Player (v 12 si 15.5) si mereu primesc aceasta eroare:




The import failed because so-ubuntu-18-04.ova did not pass OVF specification conformance or virtual hardware compliance checks.
Click Retry to relax OVF specification and virtual hardware compliance checks and try the import again, or click Cancel to cancel the import. If you retry the import, you might not be able to use the virtual machine in VMware Player.





Din ce am inteles de pe internet, problema ar fi ca masina a fost exportata din VirtualBox si nu e compatibila cu VMWare, insa pe ocw scrie ca ar trebui sa fie. Fac eu ceva gresit?




Multumesc,

Antonio Macovei, 334CA

___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema1] Neclaritate enunt - parsare argumente

2020-02-29 Fir de Conversatie Mihai Barbulescu via so
On Sat, 29 Feb 2020 at 10:10, Mihaila Corina via so
 wrote:
>
> test1.param: bad.file
> Ar trebui considerat un fisier de input valid si deschis?

Parsezi argumentul, nu merge deschis fisierul - pica programul cu eroare

>
> test2.param: -X bad param
>  Aici -X bad trebuie ignorat, iar param e un fisier de input?
> Sau ignor toata linia in momentul in care gasesc un alt parametru decat -D, 
> -o, -I?

iei in seama -X da daca parametrul e gresit treci la urmatorii. In C
puteti folosi getopt pt a va face viata usoara

>
> test3.param: _test/inputs/test3.in test3.out test3.err
>  Aici deschid un fisier de input si 2 de output sau e o linie nevalida si 
> programul
>  nu trebuie sa faca nimic?

Jur ca nu am inteles intrebarea ta: formuleaz-o mai clar. In enunt
zice destul de clar:

so-cpp [-D [=]] [-I ] [] [ [-o] ]

test3.err il poti ignora conform  cu aceasta semnatura. Vezi si in
sursele testului ce face eu daca ar fi sa implementez comanda asa as
face programul sa pice.


-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema 1][General] Functia Hash

2020-02-29 Fir de Conversatie Mihai Barbulescu via so
Salut Într-adevăr poți folosi orice funcție hash Cu stimă,Mihai Bărbulescu Original message From: Paul Olaru via so Date: Sat, Feb 29, 2020, 12:54To: "Theodor-Nicolae STOICA (78294)" , Sisteme de Operare Subject: Re: [so] [Tema 1][General] Functia HashCred că s-a zis mai devreme, orice funcție rezonabilă. Trebuie doar să nu ai o distribuție extrem de proastă care să afecteze performanța hashtable-ului în sine.On Sat, Feb 29, 2020, 12:52 PM Theodor-Nicolae STOICA (78294) via so  wrote:






Salut,

Putem folosi orice functie hash?




Multumesc,

Stoica Theodor Nicolae

334CB



___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema1] Coding Style - Conditii lungi

2020-02-28 Fir de Conversatie Mihai Barbulescu via so
Salut Teodor,

Iti recomand sa folosesti setarile astyle pentru kernelul de Linux
(astyle --style=linux). E mai simplu decat sa iti bati tu capul. Mai
exista si indent da nu mi-am batut capul cu asta. Si o poti face mai
agresiva sub urmatoarea forma:

astyle --style=linux --indent=force-tab=8 --align-pointer=name -p -H -U

Daca folosesti Visual Studio code poti configura de exemplu ca la
autosave sa se ruleze astyle, uite mai jos un exemplu de intrare in
settings.json (invalida pt Linux, o folosesc in alt context)
{
...
"astyle.cmd_options": [
"--style=kr",
"--indent=spaces=4",
"--indent-col1-comments",
"--convert-tabs",
"--pad-oper",
"--pad-header",
"--unpad-paren",
"--lineend=linux",
"--max-code-length=120",
"--add-brackets",
"--align-reference=type",
"--align-pointer=type"
],

...
}

Daca folosesti gitlab poti configura hook de post/receive sa ruleze
checkpatch.pl si astyle pt codul tau cand pushezi.

Punctual la intrebarea ta: din punct de vedere al codului nu mi-as
bate capul atat timp cat indeplineste 2 conditii:
1. checkpatch.pl il valideaza fara erori
2. tie personal ti se pare usor de citit

Orice review de genul: mie imi place mai mult asa decat cum propui tu,
domnu' developer, mi se pare ca genereaza discutii infinite inutile si
de-aia sunt fanul automatizarii lui prin astyle/indent/checkpatch.

On Fri, 28 Feb 2020 at 09:21, Paul Olaru via so  wrote:
>
> Eu unul sunt familiarizat cu a doua opțiune fiind cel mai des folosită în 
> porțiunea de kernel Linux în care lucrez eu deci aș recomanda să o folosești 
> pe aceasta. Prima variantă poate fi bună în situații rare în care condiția e 
> într-adevăr complexă și ar avea nevoie de un nume sau comentariu.
>
> A treia variantă nu văd să aibă un avantaj.
>
> Deci eu unul recomand să mergi pe a doua variantă, cu excepția cazului în 
> care a crea funcția cu un nume relevant poate ajuta înțelegerea codului. Dacă 
> funcția s-ar numi "cond7", don't bother. Dacă funcția s-ar numi 
> "is_valid_open_request", o poți crea.
>
>
> On Fri, Feb 28, 2020, 9:17 AM Teodor Popescu via so  
> wrote:
>>
>> Bună ziua,
>>
>> Putem întâlni situații în care avem suficient de multe condiții
>> într-un if încăt linia să depășească un prag de bun simț (să spunem,
>> 100 de caractere).
>> Presupunem următoarea secvență de cod:
>> if (CONDIȚIE_1 || CONDIȚIE_2 || CONDIȚIE_3 || CONDIȚIE_4 || CONDIȚIE_5) {
>> instr;
>> }
>>
>> Nu am găsit în standardul pentru Linux Kernel o soluție pentru aceste
>> situații, dar am identificat 3 metode prin care am putea aborda aceste
>> cazuri:
>>
>> 1) Refactorizarea codului prin adăugarea unei funcții (care nu va
>> apărea și în fișierul .h) astfel:
>> int my_function()
>> {
>> return CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5;
>> }
>> if (my_function()) {
>> instr;
>> }
>>
>> Dezavantaj: Nu este imediat evidentă condiția, fiind nevoie să
>> cauți funcția pentru a înțelege codul.
>>
>> 2) "Spargerea" condiției pe mai multe linii, astfel:
>> if (CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5) {
>> instr;
>> }
>>
>> Dezavantaj: Indentarea instrucțiunilor este identică celei a
>> condițiilor, și nu este imediat clar unde se termină condițiile și
>> unde încep instrucțiunile.
>>
>> 3) "Spargerea" condiției pe mai multe linii, astfel:
>> if (CONDIȚIE_1 ||
>> CONDIȚIE_2 ||
>> CONDIȚIE_3 ||
>> CONDIȚIE_4 ||
>> CONDIȚIE_5)
>> {
>> instr;
>> }
>>
>> Dezavantaj: Nu se respectă recomandarea generală de a avea acolada
>> deschisă pe aceeași linie cu închiderea condiției unui 'if'.
>>
>> Aveți vreo recomandare legată de acest aspect?
>>
>> Mulțumesc frumos.
>>
>> O seară plăcută
>> Teodor Popescu
>> +40 770 498 496   |   teodor.popescu2005   |   335CB
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO] Contestație Tema 4 Linux

2019-05-24 Fir de Conversatie Mihai Barbulescu via so
Buna Ioana,

Verifica catalogul te rog. A fost o problema generala la temele 4, am
verificat particular cazul tau si ai nota trecuta acolo.

Valabil si pentru ceilalti studenti. Insa rugamintea ar fi sa urmati
indicatiile lui Razvan si anume procedura de contestatii fiind aceasta
[1]

[1] https://ocw.cs.pub.ro/courses/so/teme/contestatii

On Fri, 24 May 2019 at 20:24, Ioana Vitomireanu via so
 wrote:
>
> Buna ziua,
>
> Ma numesc Vitomireanu Ioana, sunt de la grupa 333CC. Username: 
> Ioana.vitomireanu.
>
> Nu am nota trecută in catalog la tema3 Linux.
>
> Sent from my iPhone
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO] Contestație Tema 4 Linux

2019-05-24 Fir de Conversatie Mihai Barbulescu via so
Subiectul zice tema 4 conținutul mailului tema 3.Cum e pana la urma? Cu stimă,Mihai Bărbulescu Original Message Subject: [so] [SO] Contestație Tema 4 LinuxFrom: Ioana Vitomireanu via so To: so@cursuri.cs.pub.roCC: Buna ziua,Ma numesc Vitomireanu Ioana, sunt de la grupa 333CC. Username: Ioana.vitomireanu.Nu am nota trecută in catalog la tema3 Linux.Sent from my iPhone___http://ocw.cs.pub.ro/courses/so/info/lista-discutii___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema 5][Linux] Base64 encode luat de pe github

2019-05-18 Fir de Conversatie Mihai Barbulescu via so
Păstrezi licența inițială, precizezi sursa în Readme și eventualele modificări și folosești ce vrei de pe internet Cu stimă,Mihai Bărbulescu Original Message Subject: [so] [SO][Tema 5][Linux] Base64 encode luat de pe githubFrom: George Diaconu via so To: Sisteme de Operare CC: Salut,Vreau sa adaug autentificare in implementarea mea si am nevoie debase64 encode. Trebuie sa o implementez eu si pe aceasta sau e ok dacao iau de pe github? Nu-mi place sa reinventez roata, desi, probabil,ar fi ceva de invatat si din implementarea algoritmului asta.Numai bine,George Diaconu___http://ocw.cs.pub.ro/courses/so/info/lista-discutii___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema 5][Linux] netcat opreste conexiunea prea devreme

2019-05-17 Fir de Conversatie Mihai Barbulescu via so
Salut George,

Mesajele tale sunt foarte bune si explicatiile pe care le dai la fel,
ar trebui sa ajute si pe altii. Nu este nici un deranj ca le dai pe
bucati, apreciem faptul ca impartasesti experienta ta de debugging, te
rog sa nu iti faci griji in privinta numarului mare de mesaje.

On Fri, 17 May 2019 at 19:17, George Diaconu via so
 wrote:
>
> Salut,
>
> Imi cer scuze pentru toate mesajele, acesta e ultimul in acest thread.
> Am gasit problema. Server-ul meu nu astepta sa primeasca tot
> request-ul de la client. Imediat ce parsa calea, incepea sa trimita
> raspunsul. Acum astept sa trimita clientul toata cererea, apoi trimit
> raspunsul si fisierul daca este cazul si merge perfect.
> Stack overflow m-a salvat din nou [1].
>
> Numai bine,
> George
>
> https://stackoverflow.com/questions/31168131/http-server-not-sending-complete-file-to-wget-firefox-connection-reset-by-peer
>
> În vin., 17 mai 2019 la 18:01, George Diaconu  a scris:
> >
> > Revin cu o completare.
> > La testul 16, server-ul afiseaza ca a trimis raspunsul "200 OK", apoi
> > fisierul si ca a inchis conexiunea, chair daca wget spune ca a fost
> > inchisa conexiunea inainte sa primeasca macar "200 OK".
> > Am rulat testul si am obitnut 2 fisiere .pcap, unul pentru o executie
> > cu succes a testului si altul cand esueaza testul. Las arhiva cu cele
> > doua fisiere la [1].
> > La [2] este link-ul catre repo-ul meu.
> >
> > Numai bine,
> > George Diaconu
> >
> > [1] https://drive.google.com/open?id=1JG98HjEDUO7kZM0UmOiHid62gF0OWqNY
> > [2] https://gitlab.cs.pub.ro/george.diaconu2208/l3-so-assignments
> >
> > În vin., 17 mai 2019 la 16:48, George Diaconu  a 
> > scris:
> > >
> > > Salut,
> > >
> > > Am reusit sa rezolv problema asta intre timp. Las la [1] link-ul unde
> > > am inteles care a fost problema. Pe scurt, din ce am inteles, netcat
> > > anunta ca este gata sa opreasca conexiunea, dar server-ul considera ca
> > > s-a si deconectat si dadea drop conexiunii. Acum in momentul in care
> > > recv intoarce 0, nu inchid imediat conexiunea, verific in ce stadiu
> > > este conexiunea (am o masina de stari cum este recomandat in enuntul
> > > temei), si inchid conexiunea dupa ce a fost trimis tot fisierul.
> > >
> > > Acum am probleme cu testul 16. Uneori merge, alteori nu merge. Acest
> > > test foloseste wget. Cand nu merge, mesajul intors de wget este "Read
> > > error (Connection reset by peer) in headers." Interesant este ca daca
> > > adaug flag-ul '-d' comenzii wget, testul trece mereu (am testat cu 100
> > > de rulari succesive, fara '-d' merge foarte rar). Flag-ul acesta ar
> > > trebui doar sa produca mai mult output, dar cumva face mai mult.
> > >
> > > Numai bine,
> > > George
> > >
> > > [1] 
> > > https://stackoverflow.com/questions/41776718/what-exactly-does-the-q-option-of-netcat-do
> > >
> > > În vin., 17 mai 2019 la 15:12, Razvan Crainea
> > >  a scris:
> > > >
> > > > Salut, George!
> > > >
> > > > Poți face un trace pcap (folosind wireshark sau tcpdump) pe portul
> > > > , să vedem exact comunicația TCP între client și server?
> > > >
> > > > Numai bine,
> > > > Răzvan
> > > >
> > > > On Fri, May 17, 2019 at 1:28 AM George Diaconu via so
> > > >  wrote:
> > > > >
> > > > > Salut,
> > > > >
> > > > > Am o problema la testul 13. Checker-ul executa urmatoarea comanda:
> > > > > echo -ne "GET /static/small00.dat HTTP/1.0\r\n\r\n" | nc -q 1
> > > > > 192.168.169.128 
> > > > >
> > > > > Inteleg de aici ca cere fisierul /static/small00.dat.
> > > > > Problema mea este ca dupa ce clientul trimite toata cererea (unesc
> > > > > bucatile trimise de client), server-ul apuca sa parseze cererea, dar
> > > > > apoi client-ul inchide conexiunea fara sa mai astepte raspunsul.
> > > > > Am reusit sa reduc problema la parametrul '-q 1' al comenzii 'nc'. In
> > > > > manual scrie ca acest parametru face ca 'nc' sa mai astepte o secunda
> > > > > dupa ce a primit EOF de la stdin, si apoi se inchide.
> > > > > Am incercat cu '-q 5' si am observat ca server-ul scrie mesajul de la
> > > > > deconectarea cleintului inainte ca 'nc' sa isi termine executia. Asta
> > > > > ma face sa trag concluzia ca nc inchide conexiunea mult prea devreme.
> > > > > Restul testelor de la static merg fara probleme.
> > > > >
> > > > > De asemenea, in momentul in care trimit raspunsul, intai raspund cu
> > > > > HTTP/1.1 200 OK si apoi incep sa trimit fisierul. De asemenea, verific
> > > > > ca raspunsul sa fie trimis in intregime, si trimit pe bucati daca nu
> > > > > poate fi trimis tot o data.
> > > > >
> > > > > Nu inteleg unde gresesc, mai ales ca restul testellor trec fara 
> > > > > probleme.
> > > > >
> > > > > Multumesc anticipat.
> > > > > ___
> > > > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> > > >
> > > >
> > > >
> > > > --
> > > > Răzvan Crainea
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___

Re: [so] [Tema5][Lin] Timeout Vmchecker

2019-05-16 Fir de Conversatie Mihai Barbulescu via so
Sigur nu ai umblat la setarile masinii virtuale? Daca nu, e
reproductibil comportamentul pe vmchecker?

Testele in vmchecker nu se ruleaza cu run_all.sh ci cu make -f
Makefile.checker (n-ar trebui sa fie o diferenta esentiala)

On Thu, 16 May 2019 at 14:03, irina Mitocaru via so
 wrote:
>
> Buna.
>
> Primesc timeout la anumite teste pe Vmchecker, insa cand rulez 
> ./run_all.sh din masina virtuala Linux,
> acele teste merg. Nu ar trebui sa fie acelasi comportament?
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Indexare google

2019-05-11 Fir de Conversatie Mihai Barbulescu via so
On Sat, May 11, 2019, 14:09 Razvan Deaconescu via so 
wrote:

> Romeo Daniel Butică  writes:
> > Buna ziua!
> >
> > In urma cu 4 ani, am trimis un mesaj pe platforma de mesaje, legat de
> tema de la sistemele de operare.
> > Totul a tot ok pana la urma, insa din ce vad imi este indexat mesajul pe
> google.
> > Atunci cand imi caut numarul de telefon pe google, imi apare acest mesaj
> scris atunci.
> >
> > Am rugamintea sa ștergeți sau găsiți o solutie, ca sa nu mai fie indexat
> acest mesaj cu numarul meu de telefon pe google.
> >
> > Astept cu interes mesajul vostru!
>
> Despre ce mesaj e vorba?
>

Salut,

Nu cred ca e nevoie sa știm ce mesaj e. Conform regulilor jocului are
opțiunea sa fie uitat de către Google:

> To exercise the right to be forgotten and request removal from a search
engine, one must complete a form through the search engine's website.
Google's removal request process requires the applicant to identify their
country of residence, personal information, a list of the URLs to be
removed along with a short description of each one, and attachment of legal
identification.

> If Google refuses a request to delink material, Europeans can appeal to
their local data protection agency.

https://www.google.com/webmasters/tools/legal-removal-request
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][General]

2019-05-06 Fir de Conversatie Mihai Barbulescu via so
Salut,

Paul, iar ai vorbit pe langa.
Nu este permisa modificarea insa am uitat sa o specificam noi in
enunt. A fost adaugata speficiarea la FAQ:

Q: Este permisă modificarea header-ului?
A: Nu.

Scuze noua ca nu am precizat clar in enunt acest lucru.

On Sun, 5 May 2019 at 12:50, Paul Olaru via so  wrote:
>
> Eu unul presupun că poți face modificări, atâta timp cât sunt compatibile 
> (testele compilate cu headerul original pot folosi fără probleme funcțiile 
> implementate de tine). În general, asta înseamnă că nu poți face absolut 
> nicio modificare la structuri definite în header (când există), modificări la 
> tipurile parametrilor sau de retur (ai avea probleme de ABI) etc.
>
> Deci dacă faci modificări, ai doar grijă să fie compatibile. Eu funcțiile 
> suplimentare le-am declarat în propriile headere și în fișierul principal de 
> implementare.
>
> On Sun, May 5, 2019, 12:46 PM Rares Cosmin via so  
> wrote:
>>
>> Buna ziua! Este permisa modificarea fisierului "so_scheduler.h" cu scopul de 
>> adauga elemente noi in el?
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] [Tema 4] Update teste

2019-05-02 Fir de Conversatie Mihai Barbulescu via so
Salutare,

Din cauza problemelor de OOM aparute, am scos memcheck-urile pentru
testele de roundrobin (testul 15) si stress (testul 19). Propunerea
noastra este sa resubmiteti temele manual cei care sunteți nemulțumiți
de punctaje pe acele teste. Dacă vreți să facem noi un resubmit dați
reply la acest mail cu "Vreau resubmit, ID LDAP: ionel.popescu2902" și
ne vom ocupa.

Actualizarea e si pe github [1], e suficient un "git pull" pentru a
avea noile teste.

[1] https://github.com/systems-cs-pub-ro/so-assignments/

-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux | Windows] Partea de preemptare

2019-05-02 Fir de Conversatie Mihai Barbulescu via so
On Wed, 1 May 2019 at 19:31, Ionuț Mihalache via so
 wrote:
>
> Și încă o întrebare pe care am uitat să o adresez: Cum să fac debug pentru că 
> dacă folosesc printf pot apărea sincronizări nedorite?

Sugestia 1 (profesionista): logging intr-o zona din RAM/memoria
procesului mapata dinainte in procesul tau numit "scheduler" in care
threadurile scriu. Apoi ai alt proces care colecteaza aceste loguri. O
scriere in RAM tot o sa te coste deci poti avea desincronizari. Cele
doua procese impart un /dev/shm.
Sugestia 2 (cea mai la indemana pt voi):
http://valgrind.org/docs/manual/hg-manual.html

GDB nu poate fi folosit prea reliable pentru ca asa cum printf strica
sincronizarile ghici ce-ar face un breakpoint :)

-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux | Windows] Partea de preemptare

2019-05-02 Fir de Conversatie Mihai Barbulescu via so
On Wed, 1 May 2019 at 19:33, Paul Olaru via so  wrote:
>
> cuda-gdb nu e prea rău, dar honestly aș face altceva: după ce s-a apelat 
> kernelul și am dat toate cudaFree-urile etc copiez vectorii prin care 
> implementez Hashtable-ul în sine și îl printez.

Cum folosesc cuda-gdb pe un PC cu AMD Ryzen 3 si VEGA Radeon GPU?
Intreb pentru un prieten.

-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux | Windows] Partea de preemptare

2019-05-02 Fir de Conversatie Mihai Barbulescu via so
Salut Ionut,

Raspund doar la acest email initial si inline, pentru ca in rest a
mers threadul pe ulei

On Wed, 1 May 2019 at 19:17, Ionuț Mihalache via so
 wrote:
>
> Salut,
>
> După ceva timp în care am tot încercat diferite variante de implementare 
> pentru a rezolva prima partea a testelor, cele până la round robin inclusiv 
> am niște întrebări punctuale:
>
> 1. În cazul so_fork() începem să scadem cuanta înainte sau după 
> pthread_create?

Din punctul meu de vedere: DUPA -> anunta-ma ce teste pica pe aceasta abordare.

> 2. Noi trebuie să modificăm ordinea thread-urilor noastre și în cadrul 
> planificatorului din kernel sau trebuie să lucrăm doar cu thread-urile pe 
> care le avem noi în coada cu priorități din cadrul planificatorului nostru la 
> un moment dat?

Tu lucrezi cu threadurile tale din planificatorul tau care e in
userspace, suntem la SO, ce ti-a venit cu kernelul?

> 3. Thread-ul care face primul so_fork(), cel din test, trebuie să apară în 
> coada noastră?

Oricine face so_fork trebuie sa se gaseasca in planificatorul
nostru/structurile noastre de date.

>  Și dacă nu trebuie să avem noi grijă cumva să nu mai fie pe procesor până 
> când nu se execută thread-urile din cadrul planificatorului nostru?

Toate threadurile trebuie sa se execute conform specificatiilor din
enunt. Durata din teste si testele sunt date astfel incat toti vor
apuca sa execute. Sincer sa fiu intrebarea asta n-am prea inteles-o si
de=aia nici nu prea ai primit raspunsuri de la asistenti.


-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux] thread initial

2019-04-29 Fir de Conversatie Mihai Barbulescu via so
Nu cred ca e nevoie neapărat de thread inițial pentru so_init. O poți face din procesul părinte Cu stimă,Mihai Bărbulescu Original Message Subject: Re: [so] [Tema4][Linux] thread initialFrom: Daniel Dinca To: b12mi...@gmail.com,Sisteme de Operare CC: Salut,Prin thread initial ma refeream la threadul care apelează so_init. Mulțumesc pentru răspuns. DanielSent from Yahoo Mail on AndroidOn Mon, Apr 29, 2019 at 21:59, Mihai Barbulescu wrote:   Salut,Scuze pentru raspunsul intarziat. Ma tem ca nu am inteles bineintrebarea: tu creezi un thread doar pentru scheduler, acesta estethreadul tau initial? Daca da, atunci acesta trebuie sa se termineultimul.On Sun, 28 Apr 2019 at 21:16, Daniel Dinca via so  wrote:>> Salut,>> Ce ar trebui sa facem cu thread-ul initial? Ar trebui sa il tratam ca pe oricare alt thread> la care trebuie sa ii facem schedueling si sa ii punem o prioritate foarte mica pentru ca toate> celelalte thread-uri create ulterior sa ruleze inainte sa se termine?>> Daniel> ___> http://ocw.cs.pub.ro/courses/so/info/lista-discutii-- Cu stimă,Mihai Bărbulescu  ___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux | Windows] Cuantă de timp și so_exec

2019-04-29 Fir de Conversatie Mihai Barbulescu via so
Din punctul meu de vedere pornesti scazutul la cuante atunci cand
termini cu creatul threadului

Legat de so_exec -> gandesti bine, zi-mi doar daca pica aiurea teste
sa clarificam punctual.

On Mon, 29 Apr 2019 at 22:02, Ionuț Mihalache via so
 wrote:
>
> Salut,
>
> Nu îmi este foarte clar când ar trebui să scadă cuanta de timp pentru un 
> thread. Am înțeles că trebuie să scadă când se apelează wait, signal, fork, 
> exec, dar ce se întâmplă când se rulează funcția dată ca parametru lui 
> so_fork(). Se consideră ca o instrucțiune și la finalul ei se scade o unitate 
> din cuantă?
> De asemenea din ce am înțeles din enunț so_exec nu trebuie să facă altceva 
> decât să scadă o unitate din cuantă după ce verifică dacă thread-ul este 
> preemptat sau nu. Este în regulă dacă gândesc așa?
>
> Mulțumesc,
> Ionuț
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux] thread initial

2019-04-29 Fir de Conversatie Mihai Barbulescu via so
Salut,

Scuze pentru raspunsul intarziat. Ma tem ca nu am inteles bine
intrebarea: tu creezi un thread doar pentru scheduler, acesta este
threadul tau initial? Daca da, atunci acesta trebuie sa se termine
ultimul.

On Sun, 28 Apr 2019 at 21:16, Daniel Dinca via so  wrote:
>
> Salut,
>
> Ce ar trebui sa facem cu thread-ul initial? Ar trebui sa il tratam ca pe 
> oricare alt thread
> la care trebuie sa ii facem schedueling si sa ii punem o prioritate foarte 
> mica pentru ca toate
> celelalte thread-uri create ulterior sa ruleze inainte sa se termine?
>
> Daniel
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-27 Fir de Conversatie Mihai Barbulescu via so
Îmi poți spune și ce procese consuma atât? Monitorizează testele (binarul) tema ta și memcheck. Cu stimă,Mihai Bărbulescu Original Message Subject: Re: [so] [Tema4][Linux] Memcheck failedFrom: Paul Olaru To: Mihai Barbulescu CC: Sisteme de Operare ,Rares Folea Revin. Făcând valgrind ./run_test 15 pe mașina virtuală de SO obțin mereu all heap blocks are freed și observ că se consumă tot RAM-ul (1.5GB) plus 200-300MB de swap (una din rulări s-a dus chiar la vreo 400MB de swap). Testul 19 urcă și el la vreo 700MB de consum dar e fine că în configurația originală avem 1GB de swap.On Sat, Apr 27, 2019, 3:20 PM Paul Olaru <olarupaulstelia...@gmail.com> wrote:O să încerc să cresc RAM-ul la 1.5GB (atâta plus swap ar trebui să fie suficient). În timpul testului pe un alt tab chiar văd cum memoria liberă scade (watch -n0.1 free -h), inclusiv swap-ul, până își ia kill, pe mașina de SO și cu checkerul.Join-urile le dau după ce se termină tot. Ar trebui să le dau mai din timp? Tema cu problema e de asemenea și pe VMchecker și pe git (paul_stelian.olaru).On Sat, Apr 27, 2019, 3:17 PM Mihai Barbulescu <b12mi...@gmail.com> wrote:Salut,

Testele "personale" si WSL-ul - am mai spus ca nu ma intereseaza.
Singurul relevant e vm-ul de SO. Nu oferim suport si nu stam sa
investigam pe alte tipuri de setup.

Daca aloci mai multe resurse VM-ului de SO - mai apare acel OOM kill?

De asemenea, fara sa ma uit pe tema ca nu am cum zilele astea: esti
sigur ca astepti corect toate threadurile sau ca ti-ai facut
sincronizarea cum trebuie? Am mai vazut filmul in care ruland de 3 ori
consecutiv acel test sa pice. Incearca si un helgrind in VM-ul de SO
pe testul cu round robin.

On Sat, 27 Apr 2019 at 00:54, Paul Olaru <olarupaulstelia...@gmail.com> wrote:
>
> Salut, testul de round robin îmi face și mie probleme. Pe VMchecker îmi pică, pe o mașină virtuală de Linux a mea primesc în mod consistent mesajul de Killed (și checkerul face fițe: îmi dă fail pe toate, dar rulând manual par să meargă toate celelalte) – out of memory în Valgrind. Pe mașina de SO îmi dau pass și același kill de la out of memory. Pe WSL, îmi dă pass și acesta dar Valgrind consumă peste 1.4GB de RAM când termină, ceea ce este peste resursele oferite atât de mașina mea custom cât și de cea de SO, ambele fiind setate la 512MB (și probabil depășește și capacitatea swap-ului?)
>
>
>
> Celelalte îmi trec și pe VMchecker.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Mihai Barbulescu via so
> Sent: Wednesday, April 24, 2019 10:10 PM
> To: Rares Folea
> Cc: Sisteme de Operare
> Subject: Re: [so] [Tema4][Linux] Memcheck failed
>
>
>
> Salut Rares,
>
>
>
> Tu ce comanda folosesti ca sa rulezi testele pe  Linux?
>
> Se foloseste comanda make -f Makefile.checker.
>
> Folosesti si ultima versiune de pe github [1] - e33f8600 ?
>
>
>
> Vedeti ca am facut un upgrade ca erau punctajele aiurea, tu esti
>
> singurul care a submis tema, ti-am facut eu resubmit la ea pe
>
> vmchecker acum ai 95 nu 90 cum afisa el aiurea.
>
>
>
> Faceti git pull si de pe: https://github.com/systems-cs-pub-ro/so-assignments
>
> versiunea noua ar trebui sa fie: 2126edd
>
>
>
> In rest am verificat testele si sunt consistente github vs. vmchecker
>
> - deci nu inteleg cum la tine sunt numerotate aiurea.
>
>
>
> [1] https://github.com/systems-cs-pub-ro/so-assignments/commit/e33f86007baf2e2a25e6827b94613c62ec298250
>
>
>
> On Wed, 24 Apr 2019 at 20:29, Mihai Barbulescu <b12mi...@gmail.com> wrote:
>
> >
>
> > Salut.
>
> >
>
> > Mulțumesc ca ai semnalat. E posibil sa fie o inconsistenta între github și vmchecker trebuie sa o verific.
>
> >
>
> > Cu stimă,
>
> > Mihai Bărbulescu
>
> >
>
> >
>
> >  Original Message 
>
> > Subject: Re: [so] [Tema4][Linux] Memcheck failed
>
> > From: Rares Folea
>
> > To: Mihai Barbulescu
>
> > CC: Sisteme de Operare
>
> >
>
> >
>
> > Salut Mihai,
>
> >
>
> > Testul 16) din setul de teste locale se refera la “Test Round Robin”, dar pe vmchecker, acest test are indentificatorul 15).
>
> > Referitor la modul de rulare, pe masina virtuala de linux rulam testul 16 astfel:
>
> >
>
> > LD_LIBRARY_PATH=. valgrind --tool=memcheck ./_test/run_test 16
>
> >
>
> > Outputul valgrind-ului este:
>
> > ==16733== Memcheck, a memory error detector
>
> > ==16733== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>
> > ==16733== Using Valgrind-3.15.0.GIT and LibVEX; rerun 

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-27 Fir de Conversatie Mihai Barbulescu via so
Salut,

IDEAL: ar fi mai din timp (vezi exemplul din enunt ca T2 de exemplu se
termina mai devreme decat ceilalti, acolo e binevenit si-un join).
Posibil asta sa complice lucrurile -> de aia enuntul nu va zice, deci
poti face si la final. Ce trebuie sa verifici e daca la final nu ai
ratat pe cineva.

On Sat, 27 Apr 2019 at 15:20, Paul Olaru  wrote:
>
> O să încerc să cresc RAM-ul la 1.5GB (atâta plus swap ar trebui să fie 
> suficient). În timpul testului pe un alt tab chiar văd cum memoria liberă 
> scade (watch -n0.1 free -h), inclusiv swap-ul, până își ia kill, pe mașina de 
> SO și cu checkerul.
>
> Join-urile le dau după ce se termină tot. Ar trebui să le dau mai din timp? 
> Tema cu problema e de asemenea și pe VMchecker și pe git (paul_stelian.olaru).
>
> On Sat, Apr 27, 2019, 3:17 PM Mihai Barbulescu  wrote:
>>
>> Salut,
>>
>> Testele "personale" si WSL-ul - am mai spus ca nu ma intereseaza.
>> Singurul relevant e vm-ul de SO. Nu oferim suport si nu stam sa
>> investigam pe alte tipuri de setup.
>>
>> Daca aloci mai multe resurse VM-ului de SO - mai apare acel OOM kill?
>>
>> De asemenea, fara sa ma uit pe tema ca nu am cum zilele astea: esti
>> sigur ca astepti corect toate threadurile sau ca ti-ai facut
>> sincronizarea cum trebuie? Am mai vazut filmul in care ruland de 3 ori
>> consecutiv acel test sa pice. Incearca si un helgrind in VM-ul de SO
>> pe testul cu round robin.
>>
>> On Sat, 27 Apr 2019 at 00:54, Paul Olaru  
>> wrote:
>> >
>> > Salut, testul de round robin îmi face și mie probleme. Pe VMchecker îmi 
>> > pică, pe o mașină virtuală de Linux a mea primesc în mod consistent 
>> > mesajul de Killed (și checkerul face fițe: îmi dă fail pe toate, dar 
>> > rulând manual par să meargă toate celelalte) – out of memory în Valgrind. 
>> > Pe mașina de SO îmi dau pass și același kill de la out of memory. Pe WSL, 
>> > îmi dă pass și acesta dar Valgrind consumă peste 1.4GB de RAM când 
>> > termină, ceea ce este peste resursele oferite atât de mașina mea custom 
>> > cât și de cea de SO, ambele fiind setate la 512MB (și probabil depășește 
>> > și capacitatea swap-ului?)
>> >
>> >
>> >
>> > Celelalte îmi trec și pe VMchecker.
>> >
>> >
>> >
>> > Sent from Mail for Windows 10
>> >
>> >
>> >
>> > From: Mihai Barbulescu via so
>> > Sent: Wednesday, April 24, 2019 10:10 PM
>> > To: Rares Folea
>> > Cc: Sisteme de Operare
>> > Subject: Re: [so] [Tema4][Linux] Memcheck failed
>> >
>> >
>> >
>> > Salut Rares,
>> >
>> >
>> >
>> > Tu ce comanda folosesti ca sa rulezi testele pe  Linux?
>> >
>> > Se foloseste comanda make -f Makefile.checker.
>> >
>> > Folosesti si ultima versiune de pe github [1] - e33f8600 ?
>> >
>> >
>> >
>> > Vedeti ca am facut un upgrade ca erau punctajele aiurea, tu esti
>> >
>> > singurul care a submis tema, ti-am facut eu resubmit la ea pe
>> >
>> > vmchecker acum ai 95 nu 90 cum afisa el aiurea.
>> >
>> >
>> >
>> > Faceti git pull si de pe: 
>> > https://github.com/systems-cs-pub-ro/so-assignments
>> >
>> > versiunea noua ar trebui sa fie: 2126edd
>> >
>> >
>> >
>> > In rest am verificat testele si sunt consistente github vs. vmchecker
>> >
>> > - deci nu inteleg cum la tine sunt numerotate aiurea.
>> >
>> >
>> >
>> > [1] 
>> > https://github.com/systems-cs-pub-ro/so-assignments/commit/e33f86007baf2e2a25e6827b94613c62ec298250
>> >
>> >
>> >
>> > On Wed, 24 Apr 2019 at 20:29, Mihai Barbulescu  wrote:
>> >
>> > >
>> >
>> > > Salut.
>> >
>> > >
>> >
>> > > Mulțumesc ca ai semnalat. E posibil sa fie o inconsistenta între github 
>> > > și vmchecker trebuie sa o verific.
>> >
>> > >
>> >
>> > > Cu stimă,
>> >
>> > > Mihai Bărbulescu
>> >
>> > >
>> >
>> > >
>> >
>> > >  Original Message 
>> >
>> > > Subject: Re: [so] [Tema4][Linux] Memcheck failed
>> >
>> > > From: Rares Folea
>> >
>> > > To: Mihai Barbulescu
>> >
>> > > CC: Sisteme de Operare
>> >
>> > >
>> >
>> > >
>> >
&g

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-27 Fir de Conversatie Mihai Barbulescu via so
Salut,

Testele "personale" si WSL-ul - am mai spus ca nu ma intereseaza.
Singurul relevant e vm-ul de SO. Nu oferim suport si nu stam sa
investigam pe alte tipuri de setup.

Daca aloci mai multe resurse VM-ului de SO - mai apare acel OOM kill?

De asemenea, fara sa ma uit pe tema ca nu am cum zilele astea: esti
sigur ca astepti corect toate threadurile sau ca ti-ai facut
sincronizarea cum trebuie? Am mai vazut filmul in care ruland de 3 ori
consecutiv acel test sa pice. Incearca si un helgrind in VM-ul de SO
pe testul cu round robin.

On Sat, 27 Apr 2019 at 00:54, Paul Olaru  wrote:
>
> Salut, testul de round robin îmi face și mie probleme. Pe VMchecker îmi pică, 
> pe o mașină virtuală de Linux a mea primesc în mod consistent mesajul de 
> Killed (și checkerul face fițe: îmi dă fail pe toate, dar rulând manual par 
> să meargă toate celelalte) – out of memory în Valgrind. Pe mașina de SO îmi 
> dau pass și același kill de la out of memory. Pe WSL, îmi dă pass și acesta 
> dar Valgrind consumă peste 1.4GB de RAM când termină, ceea ce este peste 
> resursele oferite atât de mașina mea custom cât și de cea de SO, ambele fiind 
> setate la 512MB (și probabil depășește și capacitatea swap-ului?)
>
>
>
> Celelalte îmi trec și pe VMchecker.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Mihai Barbulescu via so
> Sent: Wednesday, April 24, 2019 10:10 PM
> To: Rares Folea
> Cc: Sisteme de Operare
> Subject: Re: [so] [Tema4][Linux] Memcheck failed
>
>
>
> Salut Rares,
>
>
>
> Tu ce comanda folosesti ca sa rulezi testele pe  Linux?
>
> Se foloseste comanda make -f Makefile.checker.
>
> Folosesti si ultima versiune de pe github [1] - e33f8600 ?
>
>
>
> Vedeti ca am facut un upgrade ca erau punctajele aiurea, tu esti
>
> singurul care a submis tema, ti-am facut eu resubmit la ea pe
>
> vmchecker acum ai 95 nu 90 cum afisa el aiurea.
>
>
>
> Faceti git pull si de pe: https://github.com/systems-cs-pub-ro/so-assignments
>
> versiunea noua ar trebui sa fie: 2126edd
>
>
>
> In rest am verificat testele si sunt consistente github vs. vmchecker
>
> - deci nu inteleg cum la tine sunt numerotate aiurea.
>
>
>
> [1] 
> https://github.com/systems-cs-pub-ro/so-assignments/commit/e33f86007baf2e2a25e6827b94613c62ec298250
>
>
>
> On Wed, 24 Apr 2019 at 20:29, Mihai Barbulescu  wrote:
>
> >
>
> > Salut.
>
> >
>
> > Mulțumesc ca ai semnalat. E posibil sa fie o inconsistenta între github și 
> > vmchecker trebuie sa o verific.
>
> >
>
> > Cu stimă,
>
> > Mihai Bărbulescu
>
> >
>
> >
>
> >  Original Message 
>
> > Subject: Re: [so] [Tema4][Linux] Memcheck failed
>
> > From: Rares Folea
>
> > To: Mihai Barbulescu
>
> > CC: Sisteme de Operare
>
> >
>
> >
>
> > Salut Mihai,
>
> >
>
> > Testul 16) din setul de teste locale se refera la “Test Round Robin”, dar 
> > pe vmchecker, acest test are indentificatorul 15).
>
> > Referitor la modul de rulare, pe masina virtuala de linux rulam testul 16 
> > astfel:
>
> >
>
> > LD_LIBRARY_PATH=. valgrind --tool=memcheck ./_test/run_test 16
>
> >
>
> > Outputul valgrind-ului este:
>
> > ==16733== Memcheck, a memory error detector
>
> > ==16733== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>
> > ==16733== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright 
> > info
>
> > ==16733== Command: ./_test/run_test 16
>
> > ==16733==
>
> > Killed
>
> >
>
> > Logurile de sistem ce apar indica:
>
> > Apr 24 20:09:14 vagrant kernel: [118109.973987] Out of memory: Kill process 
> > 16733 (memcheck-amd64-) score 863 or sacrifice child
>
> > Apr 24 20:09:14 vagrant kernel: [118109.976517] Killed process 16733 
> > (memcheck-amd64-) total-vm:4716800kB, anon-rss:302812kB, file-rss:0kB, 
> > shmem-rss:0kB
>
> > Apr 24 20:09:14 vagrant kernel: [118110.013082] oom_reaper: reaped process 
> > 16733 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0k
>
> >
>
> > Acest comportament se manifesta doar pe masina virtuala care ruleaza pe 
> > calculatorul meu, doar pe testul 16. (celelalte teste nu dau erori la 
> > verificarea cu valgrind).
>
> >
>
> >
>
> >
>
> >
>
> > Dar pe vmchecker trec toate testele de memcheck. :)
>
> > Multumesc,
>
> > Rares
>
> >
>
> >
>
> >
>
> >
>
> > On 24 Apr 2019, at 14:30, Mihai Barbulescu  wrote:
>
> >
>
> > 

Re: [so] [Tema4][Linux] Test 19 vmchecker

2019-04-27 Fir de Conversatie Mihai Barbulescu via so
Salut,

Nu face multe submisii ca n-are rost.
Un timeout exista configurat pe tema insa mi-e teama sa nu fi fost
killed valgrind-ul (s-a mai plans un coleg insa ulterior i s-a
executat tema). Din pacate asta nu se vede pe log-ul de la vmchecker,
se vede insa daca o reproduci in VM-ul de SO prin dmesg sau log-urile
de la systemd (nu mai tin minte pe dinafara).

Nu imi e clar daca ai urcat pe Linux varianta in care ti-ai rezolvat
sincronizarea, daca n-ai facut-o, te rog sa o faci, apoi o sa ma joc
eu putin cu resubmit + sa rulez si eu tema ta la mine pe VM. Dar acum
nu am cum sa o fac.

O sa monitorizez situatia si daca se mai plang multi de astfel de
inconsistenta o sa iau o decizie legata de acel test

On Sat, 27 Apr 2019 at 13:15, Cristian Becerescu via so
 wrote:
>
> Salut,
>
> Am observat ca pe vmchecker testele mi se executa doar pana la testul 18.
> Am testat de multe ori pe masina virtuala de SO cu ultima varianta de
> checker si testul 19 isi incheie executia de fiecare data.
> Inainte uploadasem alte variante ale temei pe vmchecker (unde faceam
> sincronizarea thread-urilor altfel) si testul 19 se executa.
> Nu imi dau seama daca este sigur vorba despre un timeout pentru ca nu
> apare niciun mesaj de output la testul respectiv, iar pe local totul
> pare ok.
> Username acs.pub.ro: cristian.becerescu
>
> Multumesc!
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema 2] Supraincarcare Tema 2 cu Tema 2

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
După cum am spus mai sus. Am rezolvat.

On Wed, Apr 24, 2019, 23:08 Ana Ana via so  wrote:

> Imi pare rau, am uitat sa mentionez grupa si numele de pe cscurs, acestea
> sunt 333CA si ana_maria.tuca.
>
>
> Sent from Yahoo Mail for iPhone
> 
>
> On Wednesday, April 24, 2019, 10:43 PM, Ana Ana via so <
> so@cursuri.cs.pub.ro> wrote:
>
> Buna seara!
> In aceasta seara, cand am incercat sa incarc Tema 3 pe vmchecker, din
> greseala am intrat pe rubrica de pe vmchecker cu Tema 2 Linux. Folder-ul
> din care puteam sa aleg ce sa incarc era setat inca pe Tema 2 si nu am fost
> atenta, asa ca am ajuns sa incarc din nou Tema 2 Linux
> peste Tema 2 Linux initial trimisa de mine (iar acum apare ca am 20 de
> zile intarziere pentru Tema 2, desi e varianta buna). Se poate recupera
> penultima varianta incarcata pe vmchecker a Temei 2, va rog?
> Multumesc!
> Tuca Ana-Maria
> ___
> 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

Re: [so] [Tema 2] Supraincarcare Tema 2 cu Tema 2

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
rezolvat

data viitoare specifica si usernameul de LDAP

On Wed, 24 Apr 2019 at 22:45, Ana Ana via so  wrote:
>
> Buna seara!
> In aceasta seara, cand am incercat sa incarc Tema 3 pe vmchecker, din 
> greseala am intrat pe rubrica de pe vmchecker cu Tema 2 Linux. Folder-ul din 
> care puteam sa aleg ce sa incarc era setat inca pe Tema 2 si nu am fost 
> atenta, asa ca am ajuns sa incarc din nou Tema 2 Linux
> peste Tema 2 Linux initial trimisa de mine (iar acum apare ca am 20 de zile 
> intarziere pentru Tema 2, desi e varianta buna). Se poate recupera penultima 
> varianta incarcata pe vmchecker a Temei 2, va rog?
> Multumesc!
> Tuca Ana-Maria
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4] Ce se consideră instrucțiuni?

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
Salut Paul,

Eu unul n-am inteles deloc intrebarea, dar din punct de vedere al
enuntului daca un thread executa X instructiuni si timpul specificat
de parametrul "cuanta" a lui a expirat trebuie preemptat si intra alt
thread in joc.

Tot ce inseamna operatii I/O se traduc prin yield.

END - faci pthread join si eliberezi resursele ocupate de scheduler.

Dar ca idee operatiile pe care le-ai enumerat tu sunt operatii facute
de scheduler...

On Wed, 24 Apr 2019 at 19:48, Paul Olaru via so  wrote:
>
> În cerință, se spune că fiecare dintre funcții se consideră ca o instrucțiune 
> executată de un thread la un moment dat. Ce funcții se consideră ca 
> instrucțiuni dpdv al cuantei?
>
> INIT: Bănuiesc că nu, doar e configurația inițială a temei. Facem scheduling 
> și pe thread-ul de setup?
> FORK: La asta sunt în dubii dacă o consider sau nu. Presupun că da?
> EXEC: E clar că da
> WAIT: Presupun că nu pentru că întotdeauna iese thread-ul de pe procesor cu 
> instrucțiunea asta?
> SIGNAL: Presupun că da?
> END: Well, aici fac schedule încontinuu oricum până se termină toate 
> thread-urile... corect? Și apoi returnez.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
Salut Rares,

Tu ce comanda folosesti ca sa rulezi testele pe  Linux?
Se foloseste comanda make -f Makefile.checker.
Folosesti si ultima versiune de pe github [1] - e33f8600 ?

Vedeti ca am facut un upgrade ca erau punctajele aiurea, tu esti
singurul care a submis tema, ti-am facut eu resubmit la ea pe
vmchecker acum ai 95 nu 90 cum afisa el aiurea.

Faceti git pull si de pe: https://github.com/systems-cs-pub-ro/so-assignments
versiunea noua ar trebui sa fie: 2126edd

In rest am verificat testele si sunt consistente github vs. vmchecker
- deci nu inteleg cum la tine sunt numerotate aiurea.

[1] 
https://github.com/systems-cs-pub-ro/so-assignments/commit/e33f86007baf2e2a25e6827b94613c62ec298250

On Wed, 24 Apr 2019 at 20:29, Mihai Barbulescu  wrote:
>
> Salut.
>
> Mulțumesc ca ai semnalat. E posibil sa fie o inconsistenta între github și 
> vmchecker trebuie sa o verific.
>
> Cu stimă,
> Mihai Bărbulescu
>
>
>  Original Message 
> Subject: Re: [so] [Tema4][Linux] Memcheck failed
> From: Rares Folea
> To: Mihai Barbulescu
> CC: Sisteme de Operare
>
>
> Salut Mihai,
>
> Testul 16) din setul de teste locale se refera la “Test Round Robin”, dar pe 
> vmchecker, acest test are indentificatorul 15).
> Referitor la modul de rulare, pe masina virtuala de linux rulam testul 16 
> astfel:
>
> LD_LIBRARY_PATH=. valgrind --tool=memcheck ./_test/run_test 16
>
> Outputul valgrind-ului este:
> ==16733== Memcheck, a memory error detector
> ==16733== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==16733== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright 
> info
> ==16733== Command: ./_test/run_test 16
> ==16733==
> Killed
>
> Logurile de sistem ce apar indica:
> Apr 24 20:09:14 vagrant kernel: [118109.973987] Out of memory: Kill process 
> 16733 (memcheck-amd64-) score 863 or sacrifice child
> Apr 24 20:09:14 vagrant kernel: [118109.976517] Killed process 16733 
> (memcheck-amd64-) total-vm:4716800kB, anon-rss:302812kB, file-rss:0kB, 
> shmem-rss:0kB
> Apr 24 20:09:14 vagrant kernel: [118110.013082] oom_reaper: reaped process 
> 16733 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0k
>
> Acest comportament se manifesta doar pe masina virtuala care ruleaza pe 
> calculatorul meu, doar pe testul 16. (celelalte teste nu dau erori la 
> verificarea cu valgrind).
>
>
>
>
> Dar pe vmchecker trec toate testele de memcheck. :)
> Multumesc,
> Rares
>
>
>
>
> On 24 Apr 2019, at 14:30, Mihai Barbulescu  wrote:
>
> Salut Rares,
>
> Sunt mai multe chestii pe care nu le inteleg:
>
> 1. Cum adica test 16 (15 pe vm)? Ele au un identificator clar, deci nu
> inteleg ce test pica
> 2. OOM manager din Linux da kill atunci cand se fac alocari (page
> faults) excesive peste o limita setata daca imi amintesc bine de
> ulimit. Eroarea pare una de vagrant, deci e posibil sa fi pornit
> folosind vagrant masina si sa ti se fi dat kill la vagrant.
>
> Ne dai atat de putine detalii despre cum rulezi incat nu putem face
> altceva decat sa speculam mai ceva ca la bursa.
>
> On Wed, 24 Apr 2019 at 10:16, Rares Folea via so  wrote:
>
>
> Multumesc de hint.
> Intradevar, problema era ca nu asteptam in toate scenariile, dupa toate 
> threadurile.
>
> Acum vad ca trec toate testele de memorie pe vmchecker.
>
>
> Doar pe masina virtuala, cand rulez valgrind peste acel test 16 (15 pe vm), 
> logurile de sistem indica out-of-memory:
> Apr 24 10:11:14 vagrant kernel: [109075.123564] Out of memory: Kill process 
> 11250 (memcheck-amd64-) score 866 or sacrifice child
> Apr 24 10:11:14 vagrant kernel: [109075.124387] Killed process 11250 
> (memcheck-amd64-) total-vm:4736696kB, anon-rss:309400kB, file-rss:0kB, 
> shmem-rss:0kB
> Apr 24 10:11:14 vagrant kernel: [109075.153180] oom_reaper: reaped process 
> 11250 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
>
>
> On 23 Apr 2019, at 22:27, Razvan Crainea  wrote:
>
> Salut, Rareș!
>
> Cel mai probabil nu aștepți toate thread-urile, de acolo apare leak-ul.
> Legat de faptul că că procesul este omorât, poți verifica log-urile de
> sistem să te asiguri că nu este un crash?
>
> Numai bine,
> Răzvan
>
> On Tue, Apr 23, 2019 at 9:10 PM Rares Folea via so  
> wrote:
>
>
> Buna seara!
>
> Ma confrunt cu urmatoarele probleme referitoare la testele de memorie:
>
> La rularea pe masina virtuala cu valgrind a testelor 15 si 19 (14 si 18 pe 
> vmchecker), obtin 2 erori similare:
>
> ==4684== 288 bytes in 1 blocks are possibly lost in loss record 2 of 2
> ==4684==at 0x4C3204A: calloc (vg_replace_malloc.c:762)
> ==4684==by 0x40134A6: allocate_dtv (dl-tls.c:286)
> ==4684==by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
> ==4684==by 0x5049227: allocate_stack (allocatestack.c:627)
> ==4684==by 0x5049227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
> ==4684==by 0x4E3E65B: so_fork (in 
> /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)
> ==4684==by 0x10ABDE: test_sched_handler_15 (test_exec.c:282)

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
Salut. Mulțumesc ca ai semnalat. E posibil sa fie o inconsistenta între github și vmchecker trebuie sa o verific. Cu stimă,Mihai Bărbulescu Original Message Subject: Re: [so] [Tema4][Linux] Memcheck failedFrom: Rares Folea To: Mihai Barbulescu CC: Sisteme de Operare Salut Mihai,Testul 16) din setul de teste locale se refera la “Test Round Robin”, dar pe vmchecker, acest test are indentificatorul 15).Referitor la modul de rulare, pe masina virtuala de linux rulam testul 16 astfel:LD_LIBRARY_PATH=. valgrind --tool=memcheck ./_test/run_test 16Outputul valgrind-ului este:==16733== Memcheck, a memory error detector==16733== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==16733== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright info==16733== Command: ./_test/run_test 16==16733== KilledLogurile de sistem ce apar indica:Apr 24 20:09:14 vagrant kernel: [118109.973987] Out of memory: Kill process 16733 (memcheck-amd64-) score 863 or sacrifice childApr 24 20:09:14 vagrant kernel: [118109.976517] Killed process 16733 (memcheck-amd64-) total-vm:4716800kB, anon-rss:302812kB, file-rss:0kB, shmem-rss:0kBApr 24 20:09:14 vagrant kernel: [118110.013082] oom_reaper: reaped process 16733 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kAcest comportament se manifesta doar pe masina virtuala care ruleaza pe calculatorul meu, doar pe testul 16. (celelalte teste nu dau erori la verificarea cu valgrind).Dar pe vmchecker trec toate testele de memcheck. :)Multumesc,RaresOn 24 Apr 2019, at 14:30, Mihai Barbulescu  wrote:Salut Rares,Sunt mai multe chestii pe care nu le inteleg:1. Cum adica test 16 (15 pe vm)? Ele au un identificator clar, deci nuinteleg ce test pica2. OOM manager din Linux da kill atunci cand se fac alocari (pagefaults) excesive peste o limita setata daca imi amintesc bine deulimit. Eroarea pare una de vagrant, deci e posibil sa fi pornitfolosind vagrant masina si sa ti se fi dat kill la vagrant.Ne dai atat de putine detalii despre cum rulezi incat nu putem facealtceva decat sa speculam mai ceva ca la bursa.On Wed, 24 Apr 2019 at 10:16, Rares Folea via so  wrote:Multumesc de hint.Intradevar, problema era ca nu asteptam in toate scenariile, dupa toate threadurile.Acum vad ca trec toate testele de memorie pe vmchecker.Doar pe masina virtuala, cand rulez valgrind peste acel test 16 (15 pe vm), logurile de sistem indica out-of-memory:Apr 24 10:11:14 vagrant kernel: [109075.123564] Out of memory: Kill process 11250 (memcheck-amd64-) score 866 or sacrifice childApr 24 10:11:14 vagrant kernel: [109075.124387] Killed process 11250 (memcheck-amd64-) total-vm:4736696kB, anon-rss:309400kB, file-rss:0kB, shmem-rss:0kBApr 24 10:11:14 vagrant kernel: [109075.153180] oom_reaper: reaped process 11250 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kBOn 23 Apr 2019, at 22:27, Razvan Crainea  wrote:Salut, Rareș!Cel mai probabil nu aștepți toate thread-urile, de acolo apare leak-ul.Legat de faptul că că procesul este omorât, poți verifica log-urile desistem să te asiguri că nu este un crash?Numai bine,RăzvanOn Tue, Apr 23, 2019 at 9:10 PM Rares Folea via so  wrote:Buna seara!Ma confrunt cu urmatoarele probleme referitoare la testele de memorie:La rularea pe masina virtuala cu valgrind a testelor 15 si 19 (14 si 18 pe vmchecker), obtin 2 erori similare:==4684== 288 bytes in 1 blocks are possibly lost in loss record 2 of 2==4684==    at 0x4C3204A: calloc (vg_replace_malloc.c:762)==4684==    by 0x40134A6: allocate_dtv (dl-tls.c:286)==4684==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)==4684==    by 0x5049227: allocate_stack (allocatestack.c:627)==4684==    by 0x5049227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)==4684==    by 0x4E3E65B: so_fork (in /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)==4684==    by 0x10ABDE: test_sched_handler_15 (test_exec.c:282)==4684==    by 0x4E3E47E: start_thread (in /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)==4684==    by 0x50486DA: start_thread (pthread_create.c:463)==4684==    by 0x538188E: clone (clone.S:95)==4684==  possibly lost: 576 bytes in 2 blocks==4684== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)Nu reusesc sa-mi dau seama de la ce ar putea fi cele doua erori si de ce se manifesta doar la aceste doua teste.Mentionez ca astept terminarea thread-urilor cu pthread_join, care ar trebui sa efectueze eliberarea resurselor din structura pthread_t.In plus, la testul 16 (15 vmchecker), se pare ca valgrind ocupa mult prea multa memorie locala, iar ca urmare este omorat.student@vagrant:~/l3-so-assignments/4-scheduler/checker-lin$ LD_LIBRARY_PATH=. valgrind --tool=memcheck --track-origins=yes --leak-check=full _test/run_test 16==4693== Memcheck, a memory error detector==4693== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==4693== Using V

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-24 Fir de Conversatie Mihai Barbulescu via so
Salut Rares,

Sunt mai multe chestii pe care nu le inteleg:

1. Cum adica test 16 (15 pe vm)? Ele au un identificator clar, deci nu
inteleg ce test pica
2. OOM manager din Linux da kill atunci cand se fac alocari (page
faults) excesive peste o limita setata daca imi amintesc bine de
ulimit. Eroarea pare una de vagrant, deci e posibil sa fi pornit
folosind vagrant masina si sa ti se fi dat kill la vagrant.

Ne dai atat de putine detalii despre cum rulezi incat nu putem face
altceva decat sa speculam mai ceva ca la bursa.

On Wed, 24 Apr 2019 at 10:16, Rares Folea via so  wrote:
>
> Multumesc de hint.
> Intradevar, problema era ca nu asteptam in toate scenariile, dupa toate 
> threadurile.
>
> Acum vad ca trec toate testele de memorie pe vmchecker.
>
>
> Doar pe masina virtuala, cand rulez valgrind peste acel test 16 (15 pe vm), 
> logurile de sistem indica out-of-memory:
> Apr 24 10:11:14 vagrant kernel: [109075.123564] Out of memory: Kill process 
> 11250 (memcheck-amd64-) score 866 or sacrifice child
> Apr 24 10:11:14 vagrant kernel: [109075.124387] Killed process 11250 
> (memcheck-amd64-) total-vm:4736696kB, anon-rss:309400kB, file-rss:0kB, 
> shmem-rss:0kB
> Apr 24 10:11:14 vagrant kernel: [109075.153180] oom_reaper: reaped process 
> 11250 (memcheck-amd64-), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
>
>
> On 23 Apr 2019, at 22:27, Razvan Crainea  wrote:
>
> Salut, Rareș!
>
> Cel mai probabil nu aștepți toate thread-urile, de acolo apare leak-ul.
> Legat de faptul că că procesul este omorât, poți verifica log-urile de
> sistem să te asiguri că nu este un crash?
>
> Numai bine,
> Răzvan
>
> On Tue, Apr 23, 2019 at 9:10 PM Rares Folea via so  
> wrote:
>
>
> Buna seara!
>
> Ma confrunt cu urmatoarele probleme referitoare la testele de memorie:
>
> La rularea pe masina virtuala cu valgrind a testelor 15 si 19 (14 si 18 pe 
> vmchecker), obtin 2 erori similare:
>
> ==4684== 288 bytes in 1 blocks are possibly lost in loss record 2 of 2
> ==4684==at 0x4C3204A: calloc (vg_replace_malloc.c:762)
> ==4684==by 0x40134A6: allocate_dtv (dl-tls.c:286)
> ==4684==by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
> ==4684==by 0x5049227: allocate_stack (allocatestack.c:627)
> ==4684==by 0x5049227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
> ==4684==by 0x4E3E65B: so_fork (in 
> /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)
> ==4684==by 0x10ABDE: test_sched_handler_15 (test_exec.c:282)
> ==4684==by 0x4E3E47E: start_thread (in 
> /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)
> ==4684==by 0x50486DA: start_thread (pthread_create.c:463)
> ==4684==by 0x538188E: clone (clone.S:95)
>
> ==4684==  possibly lost: 576 bytes in 2 blocks
>
> ==4684== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
>
> Nu reusesc sa-mi dau seama de la ce ar putea fi cele doua erori si de ce se 
> manifesta doar la aceste doua teste.
> Mentionez ca astept terminarea thread-urilor cu pthread_join, care ar trebui 
> sa efectueze eliberarea resurselor din structura pthread_t.
> In plus, la testul 16 (15 vmchecker), se pare ca valgrind ocupa mult prea 
> multa memorie locala, iar ca urmare este omorat.
>
> student@vagrant:~/l3-so-assignments/4-scheduler/checker-lin$ 
> LD_LIBRARY_PATH=. valgrind --tool=memcheck --track-origins=yes 
> --leak-check=full _test/run_test 16
> ==4693== Memcheck, a memory error detector
> ==4693== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==4693== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright 
> info
> ==4693== Command: _test/run_test 16
> ==4693==
> Killed
>
>
> Multumesc
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
>
> --
> Răzvan Crainea
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Windows] Eroare vmchecker

2019-04-23 Fir de Conversatie Mihai Barbulescu via so
Excelent. Mă bucur Cu stimă,Mihai Bărbulescu Original Message Subject: [so][Tema3][Windows] Eroare vmcheckerFrom: Ebru Resul To: Mihai Barbulescu ,Sisteme de Operare CC: A mers acum, mulțumesc!!> Mai încearca o data. Dacă tot face figuri o sa resubmit eu ce ai pus acum Cu stimă, Mihai Bărbulescu___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema4][Linux] Memcheck failed

2019-04-23 Fir de Conversatie Mihai Barbulescu via so
Salut Rareș, Pe lângă ce a sugerat Răzvan încearcă să folosești helgrind, e ceva mai inteligent pe multithread stuff http://valgrind.org/docs/manual/hg-manual.htmlCu stimă,Mihai Bărbulescu Original Message Subject: [so] [Tema4][Linux] Memcheck failedFrom: Rares Folea via so To: Sisteme de Operare CC: Buna seara!Ma confrunt cu urmatoarele probleme referitoare la testele de memorie:La rularea pe masina virtuala cu valgrind a testelor 15 si 19 (14 si 18 pe vmchecker), obtin 2 erori similare:==4684== 288 bytes in 1 blocks are possibly lost in loss record 2 of 2==4684==    at 0x4C3204A: calloc (vg_replace_malloc.c:762)==4684==    by 0x40134A6: allocate_dtv (dl-tls.c:286)==4684==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)==4684==    by 0x5049227: allocate_stack (allocatestack.c:627)==4684==    by 0x5049227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)==4684==    by 0x4E3E65B: so_fork (in /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)==4684==    by 0x10ABDE: test_sched_handler_15 (test_exec.c:282)==4684==    by 0x4E3E47E: start_thread (in /home/student/l3-so-assignments/4-scheduler/checker-lin/libscheduler.so)==4684==    by 0x50486DA: start_thread (pthread_create.c:463)==4684==    by 0x538188E: clone (clone.S:95)==4684==      possibly lost: 576 bytes in 2 blocks==4684== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)Nu reusesc sa-mi dau seama de la ce ar putea fi cele doua erori si de ce se manifesta doar la aceste doua teste.Mentionez ca astept terminarea thread-urilor cu pthread_join, care ar trebui sa efectueze eliberarea resurselor din structura pthread_t.In plus, la testul 16 (15 vmchecker), se pare ca valgrind ocupa mult prea multa memorie locala, iar ca urmare este omorat.student@vagrant:~/l3-so-assignments/4-scheduler/checker-lin$ LD_LIBRARY_PATH=. valgrind --tool=memcheck --track-origins=yes --leak-check=full _test/run_test 16==4693== Memcheck, a memory error detector==4693== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==4693== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright info==4693== Command: _test/run_test 16==4693== Killed Multumesc___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Windows] Eroare vmchecker

2019-04-23 Fir de Conversatie Mihai Barbulescu via so
Mai încearca o data. Dacă tot face figuri o sa resubmit eu ce ai pus acumCu stimă,Mihai Bărbulescu Original Message Subject: [so] [Tema3][Windows] Eroare vmcheckerFrom: Ebru Resul via so To: so@cursuri.cs.pub.roCC: Bună,Am încărcat acum tema 3 (Windows) pe vmchecker și îmi scrie "vmexecutor exitcode 1 (error)".A picat din nou vmchecker-ul sau e problemă de la arhiva mea?Mulțumesc,Ebru Resul 

	

		Virus-free. www.avast.com
		
	

___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO]incarcare gresita

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
Salut,

Am facut revert cum ai cerut am resubmis si re-rulat. Aveai oricum
niste teste picate, aceasta e submisia care va ramane. PUNCT. Temele
deja am incpeut corectura la ele am facut md5sum pe arhive si cea de
la 23:16 versus cea de la 00:22 aveau acelasi md5sum

Tine cont de ceea ce a spus Razvan, nu doar tu, ci si ceilalti studenti.

On Fri, 19 Apr 2019 at 10:22, Mihai Barbulescu  wrote:
>
> Nu vom da cele -0.5 pentru intarziere inapoi. Ati avut 3 saptamani de
> lucru la tema. Daca ai o submisie facuta inainte de 23:55 cu punctaj
> care te satisface pot face revert la acea submisie facuta inainte de
> 23:55 sa fie anulata depunctarea.
>
> On Fri, 19 Apr 2019 at 00:03, Robert-Constantin GENGIU (87577)
>  wrote:
> >
> > Mersi mult! Si am o depunctare in plus de -5 la tema2 nemeritata ca am 
> > urcat dupa cateva minute când era coada blocata. Poti sa verifici arhivele 
> > sau datele ei.
> >
> >
> >
> > Trimis din Mail pentru Windows 10
> >
> >
> >
> > 
> > De la: Mihai Barbulescu 
> > Trimis: Friday, April 19, 2019 12:01:14 AM
> > Către: Robert-Constantin GENGIU (87577)
> > Cc: Sisteme de Operare
> > Subiect: Re: [SO]incarcare gresita
> >
> > + lista de discuții. O sa ma ocup
> >
> > On Thu, Apr 18, 2019, 23:59 Robert-Constantin GENGIU (87577) 
> >  wrote:
> >>
> >> Salut,
> >>
> >> Scuze ca te deranjez, dar am incarcat din greseala la tema 2, tema 3 si 
> >> vreau sa stiu daca se mai poate face un roll_back ceva?
> >>
> >> O seara buna!
> >>
> >>
> >>
> >> Gengiu Robert
> >>
> >> 332CB
> >>
> >>
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu



--
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Teme][Punctaj]

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
+ lista generala, e intrebare de interes general si sunt mai multi
asistenti/profi care pot sa raspunda pe lista si ai avea sansele unui
raspuns mai rapid

Salut Sebastian,

Se aplica __exact__ ce scrie pe wiki aici [1], conform textului de
acolo eu nu imi dau seama ce e neclar: "În cazul în care temele 2, 3,
4 sau 5 sunt rezolvate pe ambele platforme, fiecare temă este punctată
cu maxim 1 punct, punctajele se cumulează și se trunchiază la 1
punct." => ai 1p pe tema5 ca si cum ai fi avut pe tema3

Spune-ne ce fraza din regulament e neclara

[1] 
https://ocw.cs.pub.ro/courses/so/meta/notare#teme_de_casa_4_puncte_5_puncte_corelare_punctaj


On Sat, 20 Apr 2019 at 17:20, Sebastian Cojocariu
 wrote:
>
> Salut,
>Tema 5(cea considerata bonus) poate inlocui una din primele 4 teme?(adica 
> daca o facem complet si pe linux si pe windows obtinem 1 punct din cele 4 
> disponibile pe teme + 100 puncte pentru corelare sau doar 200 puncte pentru 
> corelare?).Mersi!



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
Da, pare sa fie o problema cu mesajele pe care le trimiteti de pe
outlook si care nu sunt format plain text, nu esti singurul care se
plange. Dar produsele Microsoft (Outlook si office 365 mail/smtp) imi
depasesc competentele.

Eu pe cele doua linkuri iti gasesc toate mesajele.

On Sat, 20 Apr 2019 at 13:27, Bogdan POPA (87497)
 wrote:
>
> Tocmai asta este problema. Nici http://cursuri.cs.pub.ro/pipermail/so/
> nici https://www.mail-archive.com/so@cursuri.cs.pub.ro/ nu afisau mail-urile
> mele. Cele 12 ore pe care le-am mentionat au fost obtinute prin compararea
> timpului la care am primit mail-ul de la so-bounces cutimpul la care am 
> trimis eu mail.
>
> De la: Mihai Barbulescu 
> Trimis: sâmbătă, 20 aprilie 2019 13:05
> Către: Bogdan POPA (87497)
> Cc: Sisteme de Operare
> Subiect: Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux
>
> Nu, timpul de asteptare este random, in functie de disponibilitatea
> asistentilor la momentul respectiv. Uneori suntem online, alteori avem
> alta treaba.
>
> Daca nu sunteti siguri ca mailurile se trimit verificati va rog linkul
> asta - http://cursuri.cs.pub.ro/pipermail/so - daca mailul va apare
> acolo atunci s-a trimis.



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
Nu, timpul de asteptare este random, in functie de disponibilitatea
asistentilor la momentul respectiv. Uneori suntem online, alteori avem
alta treaba.

Daca nu sunteti siguri ca mailurile se trimit verificati va rog linkul
asta - http://cursuri.cs.pub.ro/pipermail/so - daca mailul va apare
acolo atunci s-a trimis.

On Sat, 20 Apr 2019 at 12:58, Bogdan POPA (87497)
 wrote:
>
> De la: so  în numele Mihai Barbulescu via so 
> 
> Trimis: sâmbătă, 20 aprilie 2019 12:31
> Către: Popa Bogdan; Sisteme de Operare
> Subiect: Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux
>
> Verifica vmchecker
>
> Mulțumesc pentru ajutor, pare în regulă acum.
>
> De asemenea, îmi pare rău pentru spam-ul generat. Din câte am înțeles de la 
> colegii mei, timpul lor de așteptare a fost de ordinul minutelor.
> Din păcate mail-urile mele au fost primite după aproximativ 12 ore. Ieri mă 
> gândeam că poate au apărut niște conflicte între setările
> clientului de mail al facultății și mailing list-ul de SO (filtru spam etc), 
> de aceea am încercat (după 2 ore 30 min, respectiv 4 ore 30 min) să trimit 
> din nou.
> În viitor o să fiu mai răbdător.
>
> O zi bună.



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 Linux

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
Verifica vmchecker

On Sat, Apr 20, 2019, 12:08 Popa Bogdan via so  wrote:

> Salut. Am încărcat astăzi Tema 3 și, din păcate, am încărcat-o peste
> Tema 2, varianta de Linux (temă ce are un minunat 3 în față).
>
> Se poate face, vă rog, revert Temei 2?
>
> User vmchecker : bogdan.popa0310
>
> Vă mulțumesc anticipat!
>
> P.S. : Am incercat sa trimit acest mail si de pe contul de facultate,
> dar am vorbit cu niste colegi care sunt abonati si mi-au zis ca ei nu
> au primit mail-ul.
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3] Submisie Tema 3 peste Tema 2 - Linux

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
fixed

On Sat, 20 Apr 2019 at 09:16, Bogdan POPA (87497) via so
 wrote:
>
> Salut. Am încărcat astăzi Tema 3 și, din păcate, am încărcat-o peste Tema 2, 
> varianta de Linux (temă ce are un minunat 3 în față).
>
> Se poate face, vă rog, revert Temei 2?
>
> User vmchecker : bogdan.popa0310
>
> Vă mulțumesc anticipat!
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema 3] Submisie Tema 3 peste Tema 2 - Linux

2019-04-20 Fir de Conversatie Mihai Barbulescu via so
fixed

On Sat, 20 Apr 2019 at 07:57, Bogdan POPA (87497) via so
 wrote:
>
> Salut. Am încărcat astăzi Tema 3 și, din păcate, am încărcat-o peste Tema 2, 
> varianta de Linux (temă ce are un minunat 3 în față).
> Se poate face, vă rog, revert Temei 2?
>
> User vmchecker : bogdan.popa0310
>
> Vă mulțumesc anticipat!
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema3][Win] Incorrect number of faults TEST data + bss

2019-04-19 Fir de Conversatie Mihai Barbulescu via so
Buna Larisa,

Ce inseamna ca testezi local?
Folosesti masina virtuala de SO livrata de echipa de SO __nemodificata__?
Cum se manifesta testul pe checker? Cum se manifesta testul in masina
virtuala de SO?
Ce inseamna ca faci "modificari minore" - ce fel de modificari faci si nu
pot fi testate in masina virtuala de SO?

Testele se fac doar in masina virtuala de SO, alte experimente precum
Visual Studio sunt neinteresante.

On Fri, 19 Apr 2019 at 14:49, Larisa Matei via so 
wrote:

> Atat am folosit, nu asta este problema
>
> On Fri, 19 Apr 2019 at 14:43, Liza Babu  wrote:
>
>> Salut.
>>
>> Este precizat și explicat în enunț [1] de ce trebuie să folosiți 65536
>> pentru dimensiunea paginii în cadrul implementării temei pe Windows.
>>
>> [1] https://ocw.cs.pub.ro/courses/so/teme/tema-3
>>
>> Spor,
>> Liza
>>
>> On Fri, Apr 19, 2019 at 2:41 PM Paul Olaru via so 
>> wrote:
>>
>>> Am observat diferențe între checker și Visual Studio pe anumite teste pe
>>> Windows (cred că inclusiv ăsta) când am folosit un PageSize de 4096?
>>> Încearcă să folosești 65536, are un comportament mult mai consistent. Mie
>>> îmi trece pe vmchecker cu 65536.
>>>
>>> On Fri, Apr 19, 2019, 2:39 PM Larisa Matei via so 
>>> wrote:
>>>
 Buna,

 Si eu primesc la fel. Nu inteleg de ce imi trece testul pe local si pe
 vmchecker pica. Si trebuie sa stau de fiecare data sa incarc tema cu mici
 modificari, pt ca altfel nu am cum sa verific.

 On Wed, 17 Apr 2019 at 20:50, Adrian Șendroiu via so <
 so@cursuri.cs.pub.ro> wrote:

> Pare să fie un acces invalid la memorie.
>
>
> On Wed, 17 Apr 2019 at 20:26, Cristin Sirbu via so <
> so@cursuri.cs.pub.ro> wrote:
> >
> > Salut,
> >
> > Primesc acest output pe vmchecker, dar pe local (masina virtuala de
> windows din lab) merge.
> >
> > Nu inteleg de unde apare problema.
> >
> > +SUCCESS
> > Incorrect exit code: got 139, expected 0
> > Incorrect number of faults: got 6, expected  5
> > ___
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii

 --

 Larisa Matei


 Reprezentant *Fundraising LSAC* București

 Tel: +40 765 833 077

 E-mail: larisamatei...@gmail.com



 ___
 http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>>
>>> ___
>>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>> --
>
> Larisa Matei
>
>
> Reprezentant *Fundraising LSAC* București
>
> Tel: +40 765 833 077
>
> E-mail: larisamatei...@gmail.com
>
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO]incarcare gresita

2019-04-19 Fir de Conversatie Mihai Barbulescu via so
Nu vom da cele -0.5 pentru intarziere inapoi. Ati avut 3 saptamani de
lucru la tema. Daca ai o submisie facuta inainte de 23:55 cu punctaj
care te satisface pot face revert la acea submisie facuta inainte de
23:55 sa fie anulata depunctarea.

On Fri, 19 Apr 2019 at 00:03, Robert-Constantin GENGIU (87577)
 wrote:
>
> Mersi mult! Si am o depunctare in plus de -5 la tema2 nemeritata ca am urcat 
> dupa cateva minute când era coada blocata. Poti sa verifici arhivele sau 
> datele ei.
>
>
>
> Trimis din Mail pentru Windows 10
>
>
>
> 
> De la: Mihai Barbulescu 
> Trimis: Friday, April 19, 2019 12:01:14 AM
> Către: Robert-Constantin GENGIU (87577)
> Cc: Sisteme de Operare
> Subiect: Re: [SO]incarcare gresita
>
> + lista de discuții. O sa ma ocup
>
> On Thu, Apr 18, 2019, 23:59 Robert-Constantin GENGIU (87577) 
>  wrote:
>>
>> Salut,
>>
>> Scuze ca te deranjez, dar am incarcat din greseala la tema 2, tema 3 si 
>> vreau sa stiu daca se mai poate face un roll_back ceva?
>>
>> O seara buna!
>>
>>
>>
>> Gengiu Robert
>>
>> 332CB
>>
>>



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO]incarcare gresita

2019-04-18 Fir de Conversatie Mihai Barbulescu via so
+ lista de discuții. O sa ma ocup

On Thu, Apr 18, 2019, 23:59 Robert-Constantin GENGIU (87577) <
robert.gen...@stud.acs.upb.ro> wrote:

> Salut,
>
> Scuze ca te deranjez, dar am incarcat din greseala la tema 2, tema 3 si
> vreau sa stiu daca se mai poate face un roll_back ceva?
>
> O seara buna!
>
>
>
> Gengiu Robert
>
> 332CB
>
>
>
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][General]

2019-04-17 Fir de Conversatie Mihai Barbulescu via so
Salut, Da. Este ok Cu stimă,Mihai Bărbulescu Original Message Subject: [so] [Tema3][General]From: Adrian-George GĂVAN via so To: so@cursuri.cs.pub.roCC: 



Salut!
 
Este ok daca am folosit “assert” pentru verificarea valorilor de return a apelurilor de sistem in loc de macroul DIE?
 
Multumesc anticipat!
Adrian Gavan



___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] Publicare tema 4 - Planificare de threaduri

2019-04-17 Fir de Conversatie Mihai Barbulescu via so
Salutare,

Am publicat tema de casă numărul 4 - Thread Scheduler. Enunțul
temei este pe disponibil pe wiki [1]. Vă rog să citiți cu atenție
indicațiile prezente în enunțul temei.

Deadline-un soft pentru temă este 8 Mai 2019, ora 23:55, iar cel
hard - 15 Mai 2019, ora 23:55.

Nu uitați să testați implementarea voastră în mașinile virtuale [2]
înainte de a uploada pe vmchecker [3]. Testele sunt publice și sunt
disponibile pe GitHub [4].

Pentru orice alte probleme sau întrebări vă rugăm să ne contactați pe
lista de discuții.

[1] https://ocw.cs.pub.ro/courses/so/teme/tema-4
[2] http://ocw.cs.pub.ro/courses/so/info/mv
[3] https://vmchecker.cs.pub.ro/
[4] https://github.com/systems-cs-pub-ro/so-assignments

Spor la implementare!

-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect

2019-04-16 Fir de Conversatie Mihai Barbulescu via so
Salut Ionut,

Nu-i lucru stupid si nu e timpul pierdut pentru noi. Ceea ce Razvan
Crainea a spus si ceea ce insistam aici sunt doua aspecte foarte
importante:

1. Cand formulati o problema formulati-o clar, concis si dati cat mai
multe informatii relevante despre ea (chiar daca unele detalii vi se
par neimportante ziceti-le)
2. Echipa de SO se uita pe codul vostru atunci cand sunt lucruri
complet netriviale. Cum zicea Razvan ne uitam doar in situatii
exceptionale, de cele mai multe ori ne prindem din "vorbe"/descrierea
problemei si vrem asa sa se intample.

On Tue, 16 Apr 2019 at 17:54, Ionuț Mihalache  wrote:
>
> Gata, am rezolvat. Sunt prea obosit. La SetFilePointer puneam FILE_CURRENT in 
> loc de FILE_BEGIN. Multumesc de ajutor si scuze ca v-am pierdut timpul pe un 
> lucru stupid.
>
> În mar., 16 apr. 2019 la 17:42, Mihai Barbulescu  a scris:
>>
>> Salut Ionut,
>>
>> Da un ochi pe optiunile lui [1] s-ar putea ca -dump_at_unaddressable
>> si poate -pause_at_unaddressable si poate reusesti sa afli si unde in
>> cod s-a oprit programul tau si poate asa afli accesul invalid. Show
>> reachable e util doar pentru leak-uri, poti sa lasi pornita si
>> optiunea asta.
>>
>> Mai ai optiunile -light si -brief poate gasesti ceva mai repede cu astea.
>>
>> [1] https://drmemory.org/docs/page_options.html
>>
>> On Tue, 16 Apr 2019 at 17:34, Ionuț Mihalache  wrote:
>> >
>> > Salut modul cum folosesc Dr Memory este acesta: "drmemory.exe 
>> > -show_reachable .\so_exec.exe so_test_prog.exe". Eroarea pe care o primesc 
>> > este urmatoarea:
>> >
>> > Dr. Memory version 1.11.0 build 2 built on Aug 29 2016 02:42:07
>> > Dr. Memory results for pid 3856: "so_exec.exe"
>> > Application cmdline: ".\so_exec.exe so_test_prog.exe"
>> > Recorded 115 suppression(s) from default C:\Program Files\Dr. 
>> > Memory\bin\suppress-default.txt
>> >
>> > WARNING: application is missing line number information.
>> >
>> > Error #1: UNADDRESSABLE ACCESS: reading 0x103c-0x1040 4 byte(s)
>> > # 0 so_loader.dll!so_execute +0x679(0x54511c29 
>> > )
>> > # 1 so_loader.dll!so_execute +0x17d(0x5451172e 
>> > )
>> > # 2 so_exec.exe!?+0x0  (0x20001050 
>> > )
>> > # 3 so_exec.exe!?+0x0  (0x2000153a 
>> > )
>> > # 4 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
>> > )
>> > Note: @0:00:00.265 in thread 2028
>> > Note: instruction: mov0x3c(%ecx) -> %edx
>> >
>> > Error #2: UNADDRESSABLE ACCESS: reading 0x1003-0x10030004 4 byte(s)
>> > # 0 so_loader.dll!so_execute +0x6e2(0x54511c92 
>> > )
>> > # 1 so_loader.dll!so_execute +0x692(0x54511c43 
>> > )
>> > # 2 so_loader.dll!so_execute +0x17d(0x5451172e 
>> > )
>> > # 3 so_exec.exe!?+0x0  (0x20001050 
>> > )
>> > # 4 so_exec.exe!?+0x0  (0x2000153a 
>> > )
>> > # 5 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
>> > )
>> > Note: @0:00:00.343 in thread 2028
>> > Note: instruction: cmp(%ecx) $0x
>> >
>> > Error #3: UNADDRESSABLE ACCESS: executing 0x10010005-0x10010006 1 byte(s)
>> > # 0(0x10010005)
>> > # 1 so_loader.dll!so_execute +0x69d(0x54511c4e 
>> > )
>> > # 2 so_loader.dll!so_execute +0x17d(0x5451172e 
>> > )
>> > # 3 so_exec.exe!?+0x0  (0x20001050 
>> > )
>> > # 4 so_exec.exe!?+0x0  (0x2000153a 
>> > )
>> > # 5 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
>> > )
>> > Note: @0:00:00.374 in thread 2028
>> >
>> > Mai sunt erori dar sunt leak-uri cel mai probabil cauzate de faptul ca 
>> > programul primeste segmentaion fault, cele de mai sus sunt cele care sunt 
>> > cel mai de interes. Clar fac un acces invalid la memorie insa nu imi este 
>> > inca clar unde se intampla, dar mai investighez.
>> >
>> > În mar., 16 apr. 2019 la 10:30, Mihai Barbulescu  a 
>> > scris:
>> >>
>> >> Paul,
>> >>
>> >> Dacă ai fi citit cu atenție măcar subiectul problema lui Ionuț este pe 
>> >> Windows. Nu are cum să folosească utilitarele de Linux acolo (valgrind 
>> >> sau gdb)
>> >>
>> >> Ionuț spune-mi dacă nu te descurci să folosești Dr Memory pe testul cu 
>> >> probleme arata-ne cum folosești în cazul în care acesta nu te ajuta sa 
>> >> afli informații utile
>> >>
>> >> Cu stimă,
>> >> Mihai Bărbulescu
>> >>
>> >>
>> >>  Original Message 
>> >> Subject: Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, 
>> >> VirtualProtect
>> >> From: Paul Olaru via so
>> >> To: Ionuț Mihalache
>> >> CC: Sisteme de Operare
>> >>
>> >>
>> >> Adresa 1 sună suspect (NULL pointer dereference). Memory allocation 
>> >> failure? Încearcă să reduci utilizarea de memorie dinamică pe cât 
>> >> posibil. Vezi cu Valgrind/GDB care pointer încerci să îl folosești deși e 
>> >> nul.
>> >>
>> >> On Tue, Apr 16, 2019, 9:37 AM Ionuț Mihalache  
>> >> wrote:
>> >>>
>> >>> Problema care apare este faptul că loader-ul primește segfault. Am 
>> >>> print

Re: [so] Incorrect number of faults (test 7, inputs/inv_perm)

2019-04-16 Fir de Conversatie Mihai Barbulescu via so
Salut Paul,

"Pentru executabilele Linux pe 32 de biți... Folosiți o mașină
virtuală. Simple as that." --> Iti zic eu una mai simpla. Folositi
__DOAR__ masinile virtuale de SO [1] , simple as that, si cand
definiti o problema definiti-o clar (de unde sa stim noi ca tu rulezi
pe abominatia aia de WSL din Windows 10 care nu e nici macar un Linux
real).
Am fi putut fi mai eficienti de la inceput daca foloseai asta.

"Cine folosește Linuxul din Windows 10" - Nici nu trebuie sa ne punem
problema asta. Indicatia mea ca asistent SO pentru studenti este
clara: nu folositi WSL din Windows 10 decat daca aveti nevoie de
comenzi Linux in Windows, nu il folositi pentru a dezvolta cod C
userspace cu POSIX __NICIODATA__ si in __NICI UN CONTEXT__. Nu va
bazati nici macar pe POSIX-ul din MAC OS.

[1] https://ocw.cs.pub.ro/courses/so/info/mv

On Tue, 16 Apr 2019 at 18:22, Paul-Stelian Olaru via so
 wrote:
>
> Revin. Problema nici măcar nu era din codul meu. Când rulez sub o mașină 
> virtuală pe bune de Linux, am 90/95 (nu am checkpatch). Pe ce rulez eu de 
> obicei, Linuxul din Windows 10, eu folosesc qemu-i386-static pentru a rula 
> executabilele Linux pe 32 de biți. Acest qemu-i386-static emulează toate 
> apelurile de sistem, dar se pare că mincore nu este implementat (returnează 
> -ENOSYS). Eu am folosit mincore pentru a verifica dacă o pagină a fost deja 
> mapată sau nu; dacă mincore returnează succes sau o eroare diferită de ENOMEM 
> înseamnă că ori pagina e mapată (a returna succes), ori s-a întâmplat o 
> eroare (errno != ENOMEM). Eu am declanșat astfel crash direct când mincore 
> mi-a returnat ENOSYS.
>
>
>
> Cine folosește Linuxul din Windows 10 să fie atent la chestia asta. Pentru 
> executabilele Linux pe 32 de biți... Folosiți o mașină virtuală. Simple as 
> that.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Paul-Stelian Olaru
> Sent: Tuesday, April 16, 2019 6:02 PM
> To: Adrian Șendroiu; Sisteme de Operare
> Subject: RE: [so] Incorrect number of faults (test 7, inputs/inv_perm)
>
>
>
> rt_sigaction(SIGSEGV, SIG_DFL...)
> rt_sigaction(SIGSEGV, 0xf7f758ed, ...)
> openat(„./_test/inputs/inv_perm”)
> read (header)... și close
> openat iar (tura asta al meu)
> --Primul SIGSEGV la 0x804801c
> -> mincore (-1 ENOMEM – am continuat și am mapat – cu el verific dacă nu 
> cumva e deja ceva la adresa aia)
> -> mprotect (READ, WRITE) – hack pentru secțiunile mai mici decât pagina – 
> pun eu zerouri
> -> mprotect(READ, EXECUTE) – permisiunile originale din secțiune
> rt_sigreturn (mă rog)
> --SIGSEGV la 0x80480c0
>
> -> Aparent lipsește al doilea apel la mincore, aproape de crash-ul dorit?
> -> rt_sigaction(SIGSEGV, SIG_DFL) (metoda mea de a crasha programul cu exact 
> faultul respectiv)
> -> Final SIGSEGV that actually crashes
>
> https://pastebin.com/CcbJ4WXZ (strace, complet). Există vreun mod de a cauza 
> direct fault din prima (gen nu mai mapez dacă încerc să scriu pe o zonă care 
> nu am voie, deși face parte din unul din segmente?)
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Adrian Șendroiu
> Sent: Tuesday, April 16, 2019 5:35 PM
> To: Paul-Stelian Olaru; Sisteme de Operare
> Subject: Re: [so] Incorrect number of faults (test 7, inputs/inv_perm)
>
>
>
> Ce zice strace ./_test/run_test ./_test/inputs/inv_perm?
>
>
>
> On Tue, 16 Apr 2019 at 17:07, Paul-Stelian Olaru via so
>
>  wrote:
>
> >
>
> > Pentru a rezolva faulturi verific dacă a fost deja mapată pagina de 
> > memorie. Dacă nu, o mapez. Dacă da, consider eșec la mapare și declanșez 
> > handlerul salvat la so_init_loader. Perfect, asta îmi dă aproape toate 
> > testele chiar, dar pe testul 7 (inputs/inv_perm) mi se spune că am 2 
> > faulturi în loc de unul singur.
>
> >
>
> >
>
> >
>
> > Este abordarea corectă? De asemenea, există ceva (chiar în acel ucontext pe 
> > care noi îl primim ca void*) care ne va oferi tipul de acces care a generat 
> > faultul?
>
> >
>
> >
>
> >
>
> > Sent from Mail for Windows 10
>
> >
>
> >
>
> >
>
> > ___
>
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect

2019-04-16 Fir de Conversatie Mihai Barbulescu via so
Salut Ionut,

Da un ochi pe optiunile lui [1] s-ar putea ca -dump_at_unaddressable
si poate -pause_at_unaddressable si poate reusesti sa afli si unde in
cod s-a oprit programul tau si poate asa afli accesul invalid. Show
reachable e util doar pentru leak-uri, poti sa lasi pornita si
optiunea asta.

Mai ai optiunile -light si -brief poate gasesti ceva mai repede cu astea.

[1] https://drmemory.org/docs/page_options.html

On Tue, 16 Apr 2019 at 17:34, Ionuț Mihalache  wrote:
>
> Salut modul cum folosesc Dr Memory este acesta: "drmemory.exe -show_reachable 
> .\so_exec.exe so_test_prog.exe". Eroarea pe care o primesc este urmatoarea:
>
> Dr. Memory version 1.11.0 build 2 built on Aug 29 2016 02:42:07
> Dr. Memory results for pid 3856: "so_exec.exe"
> Application cmdline: ".\so_exec.exe so_test_prog.exe"
> Recorded 115 suppression(s) from default C:\Program Files\Dr. 
> Memory\bin\suppress-default.txt
>
> WARNING: application is missing line number information.
>
> Error #1: UNADDRESSABLE ACCESS: reading 0x103c-0x1040 4 byte(s)
> # 0 so_loader.dll!so_execute +0x679(0x54511c29 
> )
> # 1 so_loader.dll!so_execute +0x17d(0x5451172e 
> )
> # 2 so_exec.exe!?+0x0  (0x20001050 
> )
> # 3 so_exec.exe!?+0x0  (0x2000153a 
> )
> # 4 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
> )
> Note: @0:00:00.265 in thread 2028
> Note: instruction: mov0x3c(%ecx) -> %edx
>
> Error #2: UNADDRESSABLE ACCESS: reading 0x1003-0x10030004 4 byte(s)
> # 0 so_loader.dll!so_execute +0x6e2(0x54511c92 
> )
> # 1 so_loader.dll!so_execute +0x692(0x54511c43 
> )
> # 2 so_loader.dll!so_execute +0x17d(0x5451172e 
> )
> # 3 so_exec.exe!?+0x0  (0x20001050 
> )
> # 4 so_exec.exe!?+0x0  (0x2000153a 
> )
> # 5 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
> )
> Note: @0:00:00.343 in thread 2028
> Note: instruction: cmp(%ecx) $0x
>
> Error #3: UNADDRESSABLE ACCESS: executing 0x10010005-0x10010006 1 byte(s)
> # 0(0x10010005)
> # 1 so_loader.dll!so_execute +0x69d(0x54511c4e 
> )
> # 2 so_loader.dll!so_execute +0x17d(0x5451172e 
> )
> # 3 so_exec.exe!?+0x0  (0x20001050 
> )
> # 4 so_exec.exe!?+0x0  (0x2000153a 
> )
> # 5 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x75801174 
> )
> Note: @0:00:00.374 in thread 2028
>
> Mai sunt erori dar sunt leak-uri cel mai probabil cauzate de faptul ca 
> programul primeste segmentaion fault, cele de mai sus sunt cele care sunt cel 
> mai de interes. Clar fac un acces invalid la memorie insa nu imi este inca 
> clar unde se intampla, dar mai investighez.
>
> În mar., 16 apr. 2019 la 10:30, Mihai Barbulescu  a scris:
>>
>> Paul,
>>
>> Dacă ai fi citit cu atenție măcar subiectul problema lui Ionuț este pe 
>> Windows. Nu are cum să folosească utilitarele de Linux acolo (valgrind sau 
>> gdb)
>>
>> Ionuț spune-mi dacă nu te descurci să folosești Dr Memory pe testul cu 
>> probleme arata-ne cum folosești în cazul în care acesta nu te ajuta sa afli 
>> informații utile
>>
>> Cu stimă,
>> Mihai Bărbulescu
>>
>>
>>  Original Message 
>> Subject: Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect
>> From: Paul Olaru via so
>> To: Ionuț Mihalache
>> CC: Sisteme de Operare
>>
>>
>> Adresa 1 sună suspect (NULL pointer dereference). Memory allocation failure? 
>> Încearcă să reduci utilizarea de memorie dinamică pe cât posibil. Vezi cu 
>> Valgrind/GDB care pointer încerci să îl folosești deși e nul.
>>
>> On Tue, Apr 16, 2019, 9:37 AM Ionuț Mihalache  wrote:
>>>
>>> Problema care apare este faptul că loader-ul primește segfault. Am printat 
>>> adresa la care are loc page fault și de la un moment dat apare adresa 1 și 
>>> nu ar trebui. VirtualAlloc și VirtualProtect nu eșuează însă nu pot să-mi 
>>> dau seama exact de unde ar mai putea fi problema.  Din printare am văzut că 
>>> anumite pagini se mapează însă nu-mi dau seama care ar putea fi cauza 
>>> pentru care primesc segfault pentru că nu fac altceva decât să aplic logica 
>>> de pe linux cu alt page size și mod de a mapa. Este posibil să iau adresa 
>>> greșit dar la început merge. Am presupus că este de la mapare pentru că tot 
>>> primesc page fault. Rulez programul de test, cel cu hello world. Am postat 
>>> doar ca să mă asigur că abordarea mea de a mapa este bună ca să nu depanez 
>>> ce nu trebuie.
>>>
>>> mar., 16 apr. 2019, 09:14 Razvan Crainea  a scris:

 Salutare!

 Am rugămintea ca atunci când raportați o problemă, să descrieți exact
 comportamentul programului, și ce debugging ați făcut. Dacă vreți să
 vă putem ajuta, trebuie să avem toate datele problemei.
 Nu ne mai cereți să ne uităm pe sursele voastre, asta ar trebui să
 facem doar în cazuri excepționale, când debugging-ul făcut de voi nu
 este de ajuns să identificăm

Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect

2019-04-16 Fir de Conversatie Mihai Barbulescu via so
Paul, Dacă ai fi citit cu atenție măcar subiectul problema lui Ionuț este pe Windows. Nu are cum să folosească utilitarele de Linux acolo (valgrind sau gdb) Ionuț spune-mi dacă nu te descurci să folosești Dr Memory pe testul cu probleme arata-ne cum folosești în cazul în care acesta nu te ajuta sa afli informații utile Cu stimă,Mihai Bărbulescu Original Message Subject: Re: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtectFrom: Paul Olaru via so To: Ionuț Mihalache CC: Sisteme de Operare Adresa 1 sună suspect (NULL pointer dereference). Memory allocation failure? Încearcă să reduci utilizarea de memorie dinamică pe cât posibil. Vezi cu Valgrind/GDB care pointer încerci să îl folosești deși e nul.On Tue, Apr 16, 2019, 9:37 AM Ionuț Mihalache  wrote:Problema care apare este faptul că loader-ul primește segfault. Am printat adresa la care are loc page fault și de la un moment dat apare adresa 1 și nu ar trebui. VirtualAlloc și VirtualProtect nu eșuează însă nu pot să-mi dau seama exact de unde ar mai putea fi problema.  Din printare am văzut că anumite pagini se mapează însă nu-mi dau seama care ar putea fi cauza pentru care primesc segfault pentru că nu fac altceva decât să aplic logica de pe linux cu alt page size și mod de a mapa. Este posibil să iau adresa greșit dar la început merge. Am presupus că este de la mapare pentru că tot primesc page fault. Rulez programul de test, cel cu hello world. Am postat doar ca să mă asigur că abordarea mea de a mapa este bună ca să nu depanez ce nu trebuie. mar., 16 apr. 2019, 09:14 Razvan Crainea  a scris:Salutare!

Am rugămintea ca atunci când raportați o problemă, să descrieți exact
comportamentul programului, și ce debugging ați făcut. Dacă vreți să
vă putem ajuta, trebuie să avem toate datele problemei.
Nu ne mai cereți să ne uităm pe sursele voastre, asta ar trebui să
facem doar în cazuri excepționale, când debugging-ul făcut de voi nu
este de ajuns să identificăm problema. Dacă va fi nevoie de asta, vom
cere noi acces la surse.
Prin urmare, Ionuț, spune-ne de ce crezi că este de la mapare? În ce
moment al execuției? Ce fel de acces nu merge?

Numai bine!
Răzvan

On Tue, Apr 16, 2019 at 12:04 AM Paul-Stelian Olaru via so
 wrote:
>
> Pentru handlerul default pe Windows trebuie să returnezi ceva cu CONTINUE_SEARCHING din handlerul apelat de sistem. Honestly chestia asta e mai ușoară pe Windows decât pe Linux.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Ionuț Mihalache via so
> Sent: Tuesday, April 16, 2019 12:01 AM
> To: Sisteme de Operare
> Subject: [so] [Tema3][Windows] - Permisiuni VirtualAlloc, VirtualProtect
>
>
>
> Salut,
>
>
>
> Se poate uita cineva din echipa va rog daca permisiunile din parametri pentru VirtualAlloc si VirtualProtect sunt in regula? Si nu stiu exact cum sa fac cu handler-ul default insa nu asta este problema acum ci faptul ca primesc segmentation fault in loader si cred ca este de la mapare.
>
>
>
> Multumesc.
>
>
>
> https://gitlab.cs.pub.ro/ionut.mihalache1506/l3-so-assignments/blob/master/3-loader/skel-win/loader.c
>
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Răzvan Crainea


___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
On Mon, 15 Apr 2019 at 17:53, Mihai Barbulescu  wrote:
>
> Salut Paul,
>
> Acestea nu sunt definitii oficiale
>
> On Mon, 15 Apr 2019 at 12:47, Paul Olaru  wrote:
> >
> > Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa 
> > heap-ul după ce am dat so_exec_start și astfel bufferele din 
> > printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt 
> > flushuite corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu 
> > voi merge pe presupunerea asta și mă voi rezuma la a folosi doar apeluri de 
> > sistem pentru implementare.
>
> Nu te mai gandi la nimic. Daca nu e documentat in:
> - manpage-ul libc-ului
> - issue ridicat de developer/tester
> Atunci acea problema __nu exista__

Un amendament aici: daca problema totusi exista si esti convins de ea
-> se ridica bug si se specifica cum se reproduce.


>
> Daca nu stii sigur si ai nevoie de validarea unui
> comportament/presupunere sunt doua solutii in viata reala (dar si la
> temele SO) pe care le aplici:
> - se face un program cat mai mic posibil de test si se valideaza sau
> nu o presupunere
> - se verifica documentatia daca specifica sau nu acel comportament
> Asa cum faceai si la matematica metoda reducerii la absurd -
> presupuneai ceva apoi gaseai contra-exemplu care sa invalideze
> presupunerea. Cealalta solutie era inductia: porneai de la un caz
> particular pe care il validai apoi generalizai prin presupunere prin
> inductie si o validai si p-aia.
>
> Daca ai neclaritati asupra functionarii functiei so_start_exec din
> scheletul temei 3 deschide un thread nou si pune intrebari punctuale,
> cu fraze cat mai scurte si clare, iar cei care au facut scheletul vor
> lamuri.
>
> >
> > Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa 
> > so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map 
> > pentru a implementa ceva echivalent lui.
> >
>
> Ceea ce spui tu aici se numesc restrictii si trebuie sa tii cont de
> ele in orice situatie. Nu mai folositi cuvinte complicate pentru
> concepte simple. Iar presupunerea la SO este: daca nu s-a dat o
> restrictie in enuntul unei teme => ai voie cu orice (asa cum i-am
> clarificat lui Alice).
>
> Spor la lucru.
>
> > On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu  wrote:
> >>
> >> Salut,
> >>
> >> Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia:
> >> - functie libc care se comporta ciudat? -> defineste conceptul
> >> "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta ->
> >> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o
> >> functie __standard__ care se comporta ciudat. Daca exista asa ceva a
> >> fost marcata ca deprecated si inlocuita!
> >> - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi?
> >> Da-mi exemplu de functie care face asta
> >>
> >> In standarde precum libc nu se pun functii "periculoase" sau "cheaty"
> >> sau whatever le numiti voi. Se pun functii care au trecut de un amplu
> >> proces de review si validare. Singurul lucru de care trebuie tinut
> >> cont e daca functiile sunt sau nu thread safe atunci cand programati
> >> multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu
> >> severitate mare la libc...
> >>
> >> Va rog sa va luati un moment de a revizui textul scris ca sa putem
> >> vorbi pe aceeasi frecventa si sa fim sincronizati.
> >>
> >> On Mon, 15 Apr 2019 at 12:27, Paul Olaru  
> >> wrote:
> >> >
> >> > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok 
> >> > și putem folosi ce ne oferă acesta fără restricții, și tot ce e de 
> >> > evitat e doar folosirea funcțiilor din libc care ori s-ar comporta 
> >> > ciudat ori ar implementa într-un mod cheaty funcționalitatea dorită? 
> >> > (Notă, la tema asta nu cred că e nimic în a doua categorie dar ar putea 
> >> > fi câteva în prima)
> >> >
> >> > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so 
> >> >  wrote:
> >> >>
> >> >> Buna Alice,
> >> >>
> >> >> Si eu sunt confuz din doua motive:
> >> >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le
> >> >> primesti in siginfo_t in si_code [1],[2]
> >> >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si
> >> >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie
> &g

Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
Salut Paul,

Acestea nu sunt definitii oficiale

On Mon, 15 Apr 2019 at 12:47, Paul Olaru  wrote:
>
> Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa 
> heap-ul după ce am dat so_exec_start și astfel bufferele din 
> printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt flushuite 
> corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu voi merge pe 
> presupunerea asta și mă voi rezuma la a folosi doar apeluri de sistem pentru 
> implementare.

Nu te mai gandi la nimic. Daca nu e documentat in:
- manpage-ul libc-ului
- issue ridicat de developer/tester
Atunci acea problema __nu exista__

Daca nu stii sigur si ai nevoie de validarea unui
comportament/presupunere sunt doua solutii in viata reala (dar si la
temele SO) pe care le aplici:
- se face un program cat mai mic posibil de test si se valideaza sau
nu o presupunere
- se verifica documentatia daca specifica sau nu acel comportament
Asa cum faceai si la matematica metoda reducerii la absurd -
presupuneai ceva apoi gaseai contra-exemplu care sa invalideze
presupunerea. Cealalta solutie era inductia: porneai de la un caz
particular pe care il validai apoi generalizai prin presupunere prin
inductie si o validai si p-aia.

Daca ai neclaritati asupra functionarii functiei so_start_exec din
scheletul temei 3 deschide un thread nou si pune intrebari punctuale,
cu fraze cat mai scurte si clare, iar cei care au facut scheletul vor
lamuri.

>
> Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa 
> so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map pentru 
> a implementa ceva echivalent lui.
>

Ceea ce spui tu aici se numesc restrictii si trebuie sa tii cont de
ele in orice situatie. Nu mai folositi cuvinte complicate pentru
concepte simple. Iar presupunerea la SO este: daca nu s-a dat o
restrictie in enuntul unei teme => ai voie cu orice (asa cum i-am
clarificat lui Alice).

Spor la lucru.

> On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu  wrote:
>>
>> Salut,
>>
>> Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia:
>> - functie libc care se comporta ciudat? -> defineste conceptul
>> "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta ->
>> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o
>> functie __standard__ care se comporta ciudat. Daca exista asa ceva a
>> fost marcata ca deprecated si inlocuita!
>> - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi?
>> Da-mi exemplu de functie care face asta
>>
>> In standarde precum libc nu se pun functii "periculoase" sau "cheaty"
>> sau whatever le numiti voi. Se pun functii care au trecut de un amplu
>> proces de review si validare. Singurul lucru de care trebuie tinut
>> cont e daca functiile sunt sau nu thread safe atunci cand programati
>> multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu
>> severitate mare la libc...
>>
>> Va rog sa va luati un moment de a revizui textul scris ca sa putem
>> vorbi pe aceeasi frecventa si sa fim sincronizati.
>>
>> On Mon, 15 Apr 2019 at 12:27, Paul Olaru  
>> wrote:
>> >
>> > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok și 
>> > putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e 
>> > doar folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar 
>> > implementa într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta 
>> > nu cred că e nimic în a doua categorie dar ar putea fi câteva în prima)
>> >
>> > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so 
>> >  wrote:
>> >>
>> >> Buna Alice,
>> >>
>> >> Si eu sunt confuz din doua motive:
>> >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le
>> >> primesti in siginfo_t in si_code [1],[2]
>> >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si
>> >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie
>> >> mentionata pe undeva?
>> >>
>> >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp
>> >> [2] 
>> >> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221
>> >>
>> >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so
>> >>  wrote:
>> >> >
>> >> > Bună,
>> >> >
>> >> > La ce te referi mai exact? Alea nu sunt semnale.
>> >> >
>> >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so  
>> >>

Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
On Mon, 15 Apr 2019 at 12:53, Alice Suiu  wrote:
>
> Buna Mihai,
>
> Da imi cer scuze pentru formulare. Într-adevăr  ma refeream la situația in 
> care ne putem folosi de orice informatie pe care ne-o oferă structura 
> siginfo_t pentru a vedea dacă o pagina este mapata sau nu.

E OK, am vrut sa ma lamuresc

>
> Nu am vazut nicio restricție in acest sens, însă am zis sa intreb ca sa fiu 
> sigura ca implementarea mea este corecta.

Daca nu sunt restrictii explicite puse in enunt va rog sa tineti minte
ca inseamna ca AVETI VOIE sa faceti acel lucru. Default is: you're
allowed unless otherwise advised.

>
> Mulțumesc pentru răspuns.

Cu placere

> Alice
>
> > On Apr 2019, at 12:24, Mihai Barbulescu  wrote:
> >
> > Buna Alice,
> >
> > Si eu sunt confuz din doua motive:
> > 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le
> > primesti in siginfo_t in si_code [1],[2]
> > 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si
> > continutul ei daca te ajuta in rezolvare, e aceasta restrictie
> > mentionata pe undeva?
> >
> > [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp
> > [2] 
> > https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221
> >
> > On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so
> >  wrote:
> >>
> >> Bună,
> >>
> >> La ce te referi mai exact? Alea nu sunt semnale.
> >>
> >>> On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so  
> >>> wrote:
> >>>
> >>> Buna ziua,
> >>>
> >>> Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de 
> >>> semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este 
> >>> mapata sau nemapata?
> >>>
> >>> Mulțumesc,
> >>> Alice Suiu
> >>> ___
> >>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> >> ___
> >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> >
> >
> >
> > --
> > Cu stimă,
> > Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Linux] fisier executabil

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
Da, de-aia si avem depunctare daca nu folosesti static la globala
interna unui modul. Problema cu multe accese la o globala si
complicarea procesului din cauza asta este o non-problema. Doar un
amator ar scrie cod cu side effects si accese aiurea la o globala.

Mai exista si variabilele extern si nu vad nici o problema in a le
folosi indiferent de dimensiunea codebase-ului __daca ele au sens__ in
contextul dat.

Legat de goto statements am uitat sa vi-l recomand pe Knuth:
http://cowboyprogramming.com/files/p261-knuth.pdf

On Mon, 15 Apr 2019 at 12:43, Paul Olaru  wrote:
>
> Globalele sunt o problemă în proiectele mari pentru că este mai dificil să 
> vezi ce cod le folosește. Și pentru majoritatea situațiilor la care mă 
> gândesc (INCLUSIV cea din tema asta) mă gândesc că o variabilă globală 
> limitată (sau statică per clasă) este suficient -- elimină problema efectelor 
> secundare fără a îngreuna utilizarea codului în sine. Mai ales că suntem 
> single threaded și nu e nevoie nici măcar de sincronizare, în situația de 
> față variabilele globale (cu static) sunt chiar ok. Recomand 'static' acolo 
> pentru ca alte module să nu modifice imprevizibil variabila.
>
> Un global global fără nicio restricție e ok în proiecte până în 1000-2000 de 
> linii după părerea mea (sau proiecte mai mari dacă e mult boilerplate; ideea 
> e ca întregul cod să încapă în mintea unei singure persoane) dar în acelea 
> care sunt mai mari, sau vor deveni pe viitor mai mari, pot deveni o problemă 
> dacă le folosești fără un motiv bun. Zic că complică procesul de debug pentru 
> că există posibilitatea să existe multe accese la aceeași variabilă globală. 
> Soluția cu 'static' rezolvă chestia asta în cele mai multe situații -- 
> rareori e o restricție reală.
>
> On Mon, Apr 15, 2019, 12:36 PM Mihai Barbulescu via so  
> wrote:
>>
>> Salutare tuturor,
>>
>> In completarea maestrului RD eu unul chiar incurajez in situatii
>> extreme/in situatii in care nu se pot evita atat folosirea goto cat si
>> folosirea variabilelor globale.
>>
>> Exemple de folosire a variabilelor globale pe langa cel de care tocmai
>> v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa
>> aveti un state machine asupra caruia umbla mai multe threaduri (sau
>> nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul
>> "sincronizat").
>>
>> Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea
>> resurselor [1]. Acest approach e foarte important in lucrul cu
>> dispozitive embedded pentru ca puteti lasa intregi resurse hardware
>> marcate ca "ocupate" aiurea
>>
>> Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai
>> mai multe globale decât este necesar (complică mult procesul de
>> debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul
>> stie sa arate si variabilele globale, de-aia fiecare proces are acea
>> zona de memorie pt globale (.data si .bss) si poti debuga continutul
>> lor prin breakpoint si inspectand acele zone de memorie ca sa fii
>> sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o
>> zona de memorie"? Raspunsul meu e NU, asta vine doar din
>> lene/necunoastere.
>> Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte
>> probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai
>> multa grija, lucru care oricum ar trebui sa va intre in reflex.
>>
>> Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita
>> si declarati o globala pt structura lista inlantuita ca sa scrieti
>> functii cu cat mai putini parametrii sunteti noobs, de-aia va
>> interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis
>> RD, o recomandare/guideline care admite exceptii.
>>
>> Sper c-am reusit sa demontez fake news-ul conform caruia globalele
>> sunt diavolul pe pamantSunt o unealta asa cum e si tesla si
>> trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea.
>>
>> [1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare
>>
>>
>>
>> On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so
>>  wrote:
>> >
>> > "Alexandru-Ionuţ MÎNDRU (87849)" via so  writes:
>> > > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care
>> > > dintre cele 2. Era regula pentru teme să nu se folosească variabile
>> > > globale, se scădea puncte pe treaba asta, fără a se explica de ce e
>> > > greșit sau de ce să nu le folosim.
>> >
>> > Well, there's your problem.
>> >
>> > >

Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
Salut,

Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia:
- functie libc care se comporta ciudat? -> defineste conceptul
"comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta ->
da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o
functie __standard__ care se comporta ciudat. Daca exista asa ceva a
fost marcata ca deprecated si inlocuita!
- implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi?
Da-mi exemplu de functie care face asta

In standarde precum libc nu se pun functii "periculoase" sau "cheaty"
sau whatever le numiti voi. Se pun functii care au trecut de un amplu
proces de review si validare. Singurul lucru de care trebuie tinut
cont e daca functiile sunt sau nu thread safe atunci cand programati
multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu
severitate mare la libc...

Va rog sa va luati un moment de a revizui textul scris ca sa putem
vorbi pe aceeasi frecventa si sa fim sincronizati.

On Mon, 15 Apr 2019 at 12:27, Paul Olaru  wrote:
>
> Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok și 
> putem folosi ce ne oferă acesta fără restricții, și tot ce e de evitat e doar 
> folosirea funcțiilor din libc care ori s-ar comporta ciudat ori ar implementa 
> într-un mod cheaty funcționalitatea dorită? (Notă, la tema asta nu cred că e 
> nimic în a doua categorie dar ar putea fi câteva în prima)
>
> On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so  
> wrote:
>>
>> Buna Alice,
>>
>> Si eu sunt confuz din doua motive:
>> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le
>> primesti in siginfo_t in si_code [1],[2]
>> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si
>> continutul ei daca te ajuta in rezolvare, e aceasta restrictie
>> mentionata pe undeva?
>>
>> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp
>> [2] 
>> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221
>>
>> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so
>>  wrote:
>> >
>> > Bună,
>> >
>> > La ce te referi mai exact? Alea nu sunt semnale.
>> >
>> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so  
>> > wrote:
>> > >
>> > > Buna ziua,
>> > >
>> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de 
>> > > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina 
>> > > este mapata sau nemapata?
>> > >
>> > > Mulțumesc,
>> > > Alice Suiu
>> > > ___
>> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>> > ___
>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>>
>> --
>> Cu stimă,
>> Mihai Bărbulescu
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Linux] fisier executabil

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
Salutare tuturor,

In completarea maestrului RD eu unul chiar incurajez in situatii
extreme/in situatii in care nu se pot evita atat folosirea goto cat si
folosirea variabilelor globale.

Exemple de folosire a variabilelor globale pe langa cel de care tocmai
v-ati lovit (si este OK si __IN REGULA__ sa folositi globala) ar fi sa
aveti un state machine asupra caruia umbla mai multe threaduri (sau
nu) - de ex pt a stii starea curenta (daca ai threaduri faci accesul
"sincronizat").

Un exemplu de folosire goto aveti chiar pe wiki pentru eliberarea
resurselor [1]. Acest approach e foarte important in lucrul cu
dispozitive embedded pentru ca puteti lasa intregi resurse hardware
marcate ca "ocupate" aiurea

Paul Olaru: as vrea si o justificare pentru afirmatia "E bine să nu ai
mai multe globale decât este necesar (complică mult procesul de
debug)." - ce inseamna ca procesul de debug e complicat? Debuggerul
stie sa arate si variabilele globale, de-aia fiecare proces are acea
zona de memorie pt globale (.data si .bss) si poti debuga continutul
lor prin breakpoint si inspectand acele zone de memorie ca sa fii
sigur. E complicat procesul de debug ca trebuie sa te uiti in "inca o
zona de memorie"? Raspunsul meu e NU, asta vine doar din
lene/necunoastere.
Stiu paper-ul la care te gandesti - ca sa nu ai side effects sau alte
probleme de care zice acolo inseamna doar sa scrii codul cu ceva mai
multa grija, lucru care oricum ar trebui sa va intre in reflex.

Ah, da, la SD daca aveti de implementat lucrul pe o lista inlantuita
si declarati o globala pt structura lista inlantuita ca sa scrieti
functii cu cat mai putini parametrii sunteti noobs, de-aia va
interzice la SD sa faceti asemenea abominatii. Dar este, asa cum a zis
RD, o recomandare/guideline care admite exceptii.

Sper c-am reusit sa demontez fake news-ul conform caruia globalele
sunt diavolul pe pamantSunt o unealta asa cum e si tesla si
trebuie sa ai grija sa nu iti dai cu ea in ... stiti voi continuarea.

[1] https://ocw.cs.pub.ro/courses/so/laboratoare/resurse/die#alta_abordare



On Sun, 14 Apr 2019 at 22:59, Razvan Deaconescu via so
 wrote:
>
> "Alexandru-Ionuţ MÎNDRU (87849)" via so  writes:
> > Eu cel puțin știu de la PC/SD din anul 1, nu mai știu exact care
> > dintre cele 2. Era regula pentru teme să nu se folosească variabile
> > globale, se scădea puncte pe treaba asta, fără a se explica de ce e
> > greșit sau de ce să nu le folosim.
>
> Well, there's your problem.
>
> > Chiar și acum la tema 1 la PC spre exemplu, există această regulă.
>
> O să discutăm cu cei de acolo.
>
> > Cei drept acum nu am verificat strict pentru SO dacă există această
> > regulă, dar am rămas cu acest lucru și presupun că și alții.
>
> Există reguli și există recomandări. Regulile sunt foarte puține (citat
> aproximativ Jack Sparrow). În dezvoltarea aplicațiilor sunt foarte
> puține "golden rules". Luați recomandările, țineți-vă de ele, dar
> admiteți când e o prostie să te ții de ele cu dinții doar pentru că "așa
> e bine".
>
> Exemple de recomandări, nu reguli, au excepții
>
> * Nu folosiți variabile globale.
>
> * Nu folosiți goto.
>
> * Puneți funcțiile deasupra main-ului.
>
> * Folosiți thread-uri, operații asincrone, expresii regulate, semnale.
>
> * Faceți codul portabil.
>
> Exemple de reguli sau lucruri care sunt mereu bune (nu știu să aibă
> excepții în afara unor concursuri de genul "Obfuscated C contest").
>
> * Să fie codul consecvent. Prost dar consecvent prost decât bine în n
>   feluri.
>
> * Variabile și funcții denumite cu cap, nu tmp_var, do_stuff, my_var.
>
> * Defensive programming: "Always code as if the guy who ends up
>   maintaining your code will be a violent psychopath who knows where you
>   live".
>
> * Trecut codul prin verificatoare statice și dinamice.
>
> * Făcut recenzie la cod.
>
> Răzvan
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



--
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [SO][Tema3][Linux] Folosire semnale pentru SIGSEGV

2019-04-15 Fir de Conversatie Mihai Barbulescu via so
Buna Alice,

Si eu sunt confuz din doua motive:
1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le
primesti in siginfo_t in si_code [1],[2]
2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si
continutul ei daca te ajuta in rezolvare, e aceasta restrictie
mentionata pe undeva?

[1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp
[2] 
https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221

On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so
 wrote:
>
> Bună,
>
> La ce te referi mai exact? Alea nu sunt semnale.
>
> On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so  wrote:
> >
> > Buna ziua,
> >
> > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim de 
> > semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o pagina este 
> > mapata sau nemapata?
> >
> > Mulțumesc,
> > Alice Suiu
> > ___
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema3][Linux] fisier executabil

2019-04-14 Fir de Conversatie Mihai Barbulescu via so
Fratilor chiar sunt curios de 2 lucruri:

1. Unde ati vazut depunctare pt variabile globale? (trebuie fixat daca
e scapata pe undeva)
2. Cine v-a zis ca variabilele globale sunt asa de naspa?

On Sun, 14 Apr 2019 at 13:33, Paul Olaru via so  wrote:
>
> Cred că asta e o utilizare legitimă de variabile globale. Plus că fără 
> globale nu poate comunica un handler de semnal cu restul codului. (static e 
> tot un global dar cu scope limitat)
>
> On Sun, Apr 14, 2019, 1:32 PM Ionuț Mihalache  wrote:
>>
>> Și nu vor fi depunctări pentru variabile globale?
>>
>> În dum., 14 apr. 2019 la 13:31, Adrian Șendroiu  a 
>> scris:
>>>
>>> Salut,
>>>
>>> Da, cel mai simplu este să ții un fd global.
>>>
>>> On Sun, 14 Apr 2019 at 13:11, Paul Olaru via so  
>>> wrote:
>>> >
>>> > +1, sunt și eu curios. Scheletul pare să dea close la fd după ce a 
>>> > procesat structurile din header.
>>> >
>>> > On Sun, Apr 14, 2019, 1:10 PM Ionuț Mihalache via so 
>>> >  wrote:
>>> >>
>>> >> Salut,
>>> >>
>>> >> In enunt ne spune ca in momentul cand mapam o noua pagina sa copiem 
>>> >> datele din fisier corespunzatoare in memoria nou mapata. Intrebarea mea 
>>> >> este cum accesez acel fisier, adica trebuie sa-l deschid eu si sa am un 
>>> >> descriptor global care sa fie vizibil in toate functiile sau sa modific 
>>> >> semnatura functiilor sau este deja ceva in schelet care sa ne ajute si 
>>> >> nu vad eu?
>>> >> ___
>>> >> 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



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Răsp.: Re: Răsp.: [Tema2][Linux] Import gresit si 0 pe vmchecker

2019-04-11 Fir de Conversatie Mihai Barbulescu via so
+ Lista de discutii te rog foloseste buton de reply all ca sa vada
toti asistentii emsajul

On Thu, 11 Apr 2019 at 15:03, Eusebiu-Ionut Chiriac
 wrote:
>
> La mine pe mașină rulează deoarece structura fișierelor este cea prezentată. 
> Am vorbit cu Razvan Deaconescu și a zis ca dacă am submis toate fișierele 
> necesare, o sa se găsească o metoda de a muta biblioteca necesara în 
> directorul din care am importat-o.
>
> Mulțumesc pentru răspuns!
>
> Pe Joi, apr. 11, 2019 la 14:56, Mihai Barbulescu
>  a scris:
> Vom discuta intern la nivelul echipei de teme si vom reveni cu o
> decizie. Eu vad acum prima data emailul
>
> Intrebarea mea este: de ce nu ai facut testarea pe masinile virtuale
> de SO ca sa poti sesiza in timp util problema?
>
> On Thu, 11 Apr 2019 at 13:34, Eusebiu-Ionut Chiriac via so
>  wrote:
> >
> > Bună ziua,
> >
> > Retrimit acest email întrucât nu am primit un răspuns
> >
> > Am realizat acum ca dupa incarcarea temei pentru platforma Linux, aceasta 
> > nu compileaza din cauza importului  "../utils/so_stdio.h".
> > Eu in acest moment ma aflu la un hackathon in Oradea si nu am acces la 
> > laptopul pe care mi-am facut tema. Nu o pot subminte cu importul corect 
> > pana luni. Se poate rezolva ceva in aceasta directie? Mentionez ca am facut 
> > tema atunci cand coada de pe vmchecker era interminabila si nu am putut 
> > sesiza problema in timp util.
> > Multumesc anticipat, Eusebiu Chiriac, 332CC.
> > account-ul de pe cs.curs este ionut.chiriac1001.
>
> >
> > ___
> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
>
>
> --
> Cu stimă,
> Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Răsp.: [Tema2][Linux] Import gresit si 0 pe vmchecker

2019-04-11 Fir de Conversatie Mihai Barbulescu via so
Vom discuta intern la nivelul echipei de teme si vom reveni cu o
decizie. Eu vad acum prima data emailul

Intrebarea mea este: de ce nu ai facut testarea pe masinile virtuale
de SO ca sa poti sesiza in timp util problema?

On Thu, 11 Apr 2019 at 13:34, Eusebiu-Ionut Chiriac via so
 wrote:
>
> Bună ziua,
>
> Retrimit acest email întrucât nu am primit un răspuns
>
> Am realizat acum ca dupa incarcarea temei pentru platforma Linux, aceasta nu 
> compileaza din cauza importului  "../utils/so_stdio.h".
> Eu in acest moment ma aflu la un hackathon in Oradea si nu am acces la 
> laptopul pe care mi-am facut tema. Nu o pot subminte cu importul corect pana 
> luni. Se poate rezolva ceva in aceasta directie? Mentionez ca am facut tema 
> atunci cand coada de pe vmchecker era interminabila si nu am putut sesiza 
> problema in timp util.
> Multumesc anticipat, Eusebiu Chiriac, 332CC.
> account-ul de pe cs.curs este ionut.chiriac1001.
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Lin] Coada plina de VMChecker apoi s-a golit dintr-o data

2019-04-06 Fir de Conversatie Mihai Barbulescu via so
Salut Daniel,

Va rog sa va verificati submisiile pe vmchecker ar fi trebuit sa se
faca revert la cele trimise dupa 00:00 iar cele care nu au fost
testate din motive de vmchecker exit error 1 au fost retrimise la
testare.

Daca sunt probleme in continuare va rog sa imi spuneti.

On Sat, 6 Apr 2019 at 11:44, Daniel Dinca via so  wrote:
>
> Salut,
>
>
> Se va mai face ceva in legatura cu situatiile descrise mai sus?
>
>
> Multumesc,
> Daniel
>
> On Thursday, April 4, 2019, 5:10:44 PM GMT+3, Scinteie Sebastian via so 
>  wrote:
>
>
> Salut,
>
> Și eu as dori sa se facă revert pentru submisia de Linux, am încărcat arhiva 
> undeva pe la 23:24.
> User-ul de vmchecker este: sebastian.scinteie
>
> Mulțumesc,
> Sebastian
>
> ___
> 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



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Linux]

2019-04-04 Fir de Conversatie Mihai Barbulescu via so
Salut,

Cateva aspecte:

1. Teme 2 submise peste tema 1 gresit -> se vor repara, tema 1 oricum
a fost deja corectata nu va fi afectat punctajul
2. Ati avut 3 saptamani de lucru la tema si in pragul deadline-ului
ati umplut coada si ati stresat la maxim o infrastructura care
recunoastem ca e depasita in anumite situatii. Este un efort in
paralel de a imbunatati infrastructura dar e o munca voluntara. Cu
toate problemele: multi din echipa de teme am fost online si am
incercat sa restauram de cate ori observam picaciuni.
3. Multi ati folosit __DOAR__ vmchecker pentru testare, deloc masinile
virtuale.

Din cauza punctelor 2 si 3 plus a faptului ca daca iti dam tie punctaj
apoi vin si cei care au trimis la 00:30 ca vor si ei si tot asa ...

Plus, citeste ce-a scris si Razvan.


On Thu, 4 Apr 2019 at 15:38, Bogdan 10 via so  wrote:
>
> Buna ziua,
> Având în vedere problemele pe care le-a avut vmcheckerul cu testarea cu o zi 
> înainte si timpul mic de incarcare dupa deadline ma asteptam la ceva mai 
> multa înțelegere.
> Va rog sa stergeti si încărcarea greșită a temei de pe platforma de windows a 
> primei teme sa nu afecteze punctajul de acolo.
> Multumesc frumos.
>
> joi, 4. 2019, 14:43 Razvan Crainea  a scris:
>>
>> Salut, Bogdan!
>>
>> Depunctarea se aplică automat, nu vom schimba acest comportament.
>> Au fost într-adevăr niște probleme cu vmchecker-ul pe partea de testare pe 
>> Windows. Dar upload-ul a fost disponibil tot timpul, nu văd cum ar fi putut 
>> influența asta realizarea temei.
>>
>> Numai bine!
>> Răzvan
>>
>> On Thu, Apr 4, 2019 at 10:24 AM Bogdan 10 via so  
>> wrote:
>>>
>>> Buna ziua,
>>> Am incarcat din greseala tema 2 linux peste tema 1 windows. Mentionez ca am 
>>> incercat-o si unde trebuie.
>>> In cazul trimiterii temei la 00:05 -00:10 este vreo posibilitate sa nu se 
>>> acorde depunctare având în vedere problemele întâmpinate pe vmchecker ?
>>> Multumesc frumos !
>>> Drumesi Bogdan-iulian 336 CA
>>> User vmchecker :bogdan.drumesi
>>>
>>> joi, 4 apr. 2019, 07:21 Alexandru Fazakas via so  a 
>>> scris:

 Salut,

 Am subsmis aseara tema cu toate testele mergand bine pe *local*, insa
 pe vmchecker aflu ca testul de popen read esueaza cu mem check failed.

 Cum as putea investiga problema?

 Mentionez ca am folosit masina virtuala adecvata. :)

 (https://gitlab.cs.pub.ro/alexandru.fazakas/l3-so-assignments)

 Zi faina,
 Alex
 ___
 http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>>
>>> ___
>>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>>
>> --
>> Răzvan Crainea
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Windows] vmchecker error (vmexecutor exitcode 1 (error))

2019-04-04 Fir de Conversatie Mihai Barbulescu via so
Ne vom ocupa [1] + [2], aveti putintica rabdare stimabililor

[1] http://cursuri.cs.pub.ro/pipermail/so/2019-April/019150.html
[2] http://cursuri.cs.pub.ro/pipermail/so/2019-April/019169.html

On Thu, 4 Apr 2019 at 11:20, Alice Suiu via so  wrote:
>
> Buna ziua,
>
> Sunt Alice Suiu de la 336CB. Am trimis la timp tema aseara, insa pe windows a 
> aparut aceasta eroare: vmchecker error (vmexecutor exitcode 1 (error)). Este 
> posibil sa se faca resubmit la tema cu ultima versiunea incarcata va rog?
>
> De asemenea, am observat ca mai sunt persoane in acceasi situatie ca mine si 
> inca nu li s-a rezolvat problema.
>
> username vmchecker: alice_florenta.suiu
>
> Multumesc mult!
> Alice
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Lin] Coada plina de VMChecker apoi s-a golit dintr-o data

2019-04-04 Fir de Conversatie Mihai Barbulescu via so
Salut Daniel,

Putem face "revert" la o submisie inainte de ora 23:55 daca asa ceva
exista si nu se vor aplica depunctari. Trebuie sa imi spui estimativ
cam pe la ce ora a fost acea submisie si daca esti multumit de
punctajul pe care acea submisie o primea, iar noi iti vom face
"revert" la ea fara sa ai depunctarile de intarziere.

On Thu, 4 Apr 2019 at 09:58, Daniel Dinca via so  wrote:
>
> Salut Razvan,
>
> Cand au fost golite aseara temele din coada de pe vmchecker eu am reincarcat 
> tema nestiind ca ele vor fi
> ulterior reuploadate de catre echipa. Astfel arhivele mele au fost incarcate 
> la 00:10, 00:15. Este posibil sa
> nu primesc depunctare pentru acest lucru sau daca se poate verifica ca 
> aceleasi arhive au fost incarcate
> si inainte de ora 12?
>
> Multumesc,
> Daniel
> On Thursday, April 4, 2019, 7:02:57 AM GMT+3, Razvan Deaconescu via so 
>  wrote:
>
>
> Raluca-Mihaela Gîjgă via so  writes:
> > Buna seara,
> >
> > Am incarcat si eu arhiva temei cu o ora inainte de deadline, insa, coada
> > era foarte incarcata.
> >
> > La ora deadline-ului au disparut toate temele din coada iar tema mea si a
> > multor alti colegi a ramas cu rezultatul "Not Tested".
> >
> > Ar trebui sa reuploadez tema (asta insemnand sa iau depunctare pentru
> > intarziere de o zi) sau efectiv sa astept rezolvarea problemei ?
> >
> > In momentul de fata coada apare goala, dar temele noastre inca apar cu
> > "not-tested".
>
> În general, dacă ați submis tema, indiferent de mesajul întâmpinat
> (bine/rău), nu resubmiteți. Noi putem resubmite aceeași temă păstrând
> timpul din vremea submisiei, fără penalizări pentru noi.
>
> Răzvan
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Vmchecker]

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Salut Tiberiu,

Nu ma intereseaza ce mijloace folosesti ca sa scrii emailul.
Indiferent ce folosesti se urmeaza indicatiile de aici [1], [2]. Punct
si nenegociabil.
Ce  inseamna e picat? Ce nu iti merge? Explica-ne si noua sa stim cum
naiba sa depanam sau la ce alt thread pe care nu l-ati citit sa va
trimitem.

Colocvialitatea o facem cand bem o bere, aici se discuta chestii serioase.

[1] https://ocw.cs.pub.ro/courses/so/info/lista-discutii#mailing_list_guidelines
[2] https://ocw.cs.pub.ro/courses/so/teme/tema-2#suport_intrebari_si_clarificari

On Wed, 3 Apr 2019 at 23:24, Lepadatu Tiberiu Andrei via so
 wrote:
>
> Salut!
>
> A picat? Sau e de la mine?
>
> Stima,
> Tiberiu Lepadatu
>
> Ps: Scuzati caracterul colocvial al acestui email intrucat el este
> scris folosind mijloace mobile.
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Vmchecker] Eroare vmchecker

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Repet ce a zis colegul si tovarasul Razvan Crainea: "testați pe
mașinile virtuale puse la dispoziție și
submiteți când terminați de rezolvat tema".
Ne vom ocupa noi sa se re-ruleze testele pe Windows si sa va primiti punctele.

Mai insist cu ceva ce-am zis pe alt thread: NU UMBLATI la configuratia
masinii (nu alocati mai mult RAM/vCPUs etc.)

On Wed, 3 Apr 2019 at 23:04, Bianca Tazlauanu via so
 wrote:
>
> Salut,
>
> Si eu am aceeasi problema. Am testat arhiva pe masina virtuala de Windows si 
> toate testele treceau, dar pe vmchecker imi apare doar mesajul de "error".
>
> Mutumesc,
> Bianca Tazlauanu
>
> On Wed, Apr 3, 2019 at 11:00 PM Darius Balanica via so  
> wrote:
>>
>> Salut,
>>
>> Am incarcat tema pe ambele platforme, pe linux totul este in regula, 
>> insa pe windows singurul feedback pe care il primesc pe vmchacker este 
>> "error", fara niciun alt mesaj. Mentionez ca am testat local arhiva pe 
>> masina virtuala de windows si totul este in regula si am resubmis arhiva pe 
>> windows de 2 ori, fara niciun alt rezultat. Am mai vazut acest comportament 
>> si la alti colegi.
>>
>> Multumes,
>> Darius Balanica (darius.balanica pe vmchecker)
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Eroare VM]

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
E vreo cale hardcodata prin codul tau?

On Wed, 3 Apr 2019 at 21:12, gaby sandu via so  wrote:
>
> Salut pe Vm imi pica toate testele din cauza "valgrind: 
> _test/bin/test_fopen_args: No such file or directory"(un exemplu) dar pe 
> local(masina virtuala de SO) imi trec, nu am aceasta problema.
>
> Sandu Gabriel 331CC
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Linux] Memcheck failed pe testul 32

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Salut Alexandru,

Multumim si noi ca ne-ai spus care a fost problema! Eu abia acum am
apucat sa citesc threadul.

On Wed, 3 Apr 2019 at 19:39, Alexandru Fazakas via so
 wrote:
>
> Salut,
>
> Am rezolvat. Foloseam un buffer intermediar undeva si era alocat cu un octet
> mai putin decat era nevoie. :)
>
> Mersi de ajutor!
>
> Alex
>
> On Wed, Apr 3, 2019 at 7:27 PM Paul-Stelian Olaru 
>  wrote:
>>
>> That looks like an off-by-one error to me. În so_fread, apelezi memmove și 
>> nu ai grijă când muți spre dreapta [nu îmi dau seama de ce ai face asta dar 
>> mă rog], dar depășești bufferul.
>>
>>
>>
>> (0 bytes after a block of __ allocated).
>>
>>
>>
>> Memoria e alocată în main. Adică tu scrii mai multe date decât îți spun ei 
>> acolo în parametri.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Alexandru Fazakas
>> Sent: Wednesday, April 3, 2019 7:24 PM
>> To: Paul Olaru
>> Cc: Sisteme de Operare
>> Subject: Re: [so] [Tema2][Linux] Memcheck failed pe testul 32
>>
>>
>>
>> Salut,
>>
>> Rezultatul din log pare sa fie in regula, mai putin un faulty write [1]
>>
>> [1] https://pastebin.com/g7SBJGJy
>>
>> Mersi,
>>
>> Alex
>>
>>
>>
>> On Wed, Apr 3, 2019 at 7:20 PM Paul Olaru  
>> wrote:
>>
>> Ai dat Valgrind pe Bash. Well, asta nu e productiv.
>>
>>
>>
>> Doar dă-i cu run_test 32 și vezi ce îți pune în _log.
>>
>>
>>
>> On Wed, Apr 3, 2019, 19:16 Alexandru Fazakas via so  
>> wrote:
>>
>> Salut,
>>
>> Stie cineva care ar fi sursa leak-urilor de memorie de genul acesta [1]? Au 
>> loc pe testul 32.
>>
>> Mentionez ca totul este pe gitlab la (LDAP: alexandru.fazakas).
>>
>>
>> [1] https://pastebin.com/dwzF1Yut
>>
>> Mersi,
>>
>> Alex
>>
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Linux][Vmchecker problem]

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Mai e urmatoarea problema pe care am vazut ca o fac studentii: avand
calculatoare mai puternice aloca mai multe resurse masinilor virtuale
(e.g.: more RAM, more CPU) sau mai umbla pe la ulimit, fara sa ne
zica.

Lasati masinile virtuale exact asa cum va sunt livrate.


On Wed, 3 Apr 2019 at 17:55, Ana Secuiu via so  wrote:
>
> Buna!
>
> Tot la ultimele doua teste am si eu o problema pe vmchecker, "memcheck 
> failed", dar pe masina virtuala totul merge bine. Care ar putea fi problema 
> si cum pot sa o investighez?
>
> Multumesc,
> Ana Secuiu
>
> On Wednesday, April 3, 2019, 4:50:06 PM GMT+3, Ruxandra Avram via so 
>  wrote:
>
>
> Salut,
>
> Am submis tema pe vmchecker și am observat 2 erori ciudate la ultimele 2 
> teste : mesg: ttyname failed: Inappropriate ioctl for device. Această eroare 
> nu este semnalată, însă, pe mașina virtuală.
> Care ar putea fi cauza?
>
> Username-ul pe cs.curs este maria.avram și codul sursă este încărcat și pe 
> gitlab.
>
> Mulțumesc!
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Linux][Vmchecker problem]

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Te rog foloseste butonul de reply all data viitoare.
Bun, vom verifica daca in procesul de "restore" a luat-o pe plaiuri
masina virtuala urcata pe vmchecker.
Dupa cum spuneam: testele par sa iti treaca asa ca nu consider ceva grav acum.

On Wed, 3 Apr 2019 at 17:06, Ruxandra Avram  wrote:
>
> Am observat că eroarea pare să aibă legătură cu mașina virtuală. Și da, 
> folosesc mașina virtuală specificată de tine.
>
> On Wed, 3 Apr 2019, 16:59 Mihai Barbulescu,  wrote:
>>
>> Buna,
>>
>> Vad ca iti trec testele. Si de asemenea ti-as recomanda sa studiezi
>> putin ce inseamna eroarea caci din ce am studiat eu nu pare sa aiba
>> legatura cu ce fac testele.
>>
>> Sigur folosesti masina virtuala de https://ocw.cs.pub.ro/courses/so/info/mv ?
>>
>> O sa investigam si noi intre timp.
>>
>> On Wed, 3 Apr 2019 at 16:49, Ruxandra Avram via so  
>> wrote:
>> >
>> > Salut,
>> >
>> > Am submis tema pe vmchecker și am observat 2 erori ciudate la ultimele 2 
>> > teste : mesg: ttyname failed: Inappropriate ioctl for device. Această 
>> > eroare nu este semnalată, însă, pe mașina virtuală.
>> > Care ar putea fi cauza?
>> >
>> > Username-ul pe cs.curs este maria.avram și codul sursă este încărcat și pe 
>> > gitlab.
>> >
>> > Mulțumesc!
>> > ___
>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>>
>> --
>> Cu stimă,
>> Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Linux][Vmchecker problem]

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Buna,

Vad ca iti trec testele. Si de asemenea ti-as recomanda sa studiezi
putin ce inseamna eroarea caci din ce am studiat eu nu pare sa aiba
legatura cu ce fac testele.

Sigur folosesti masina virtuala de https://ocw.cs.pub.ro/courses/so/info/mv ?

O sa investigam si noi intre timp.

On Wed, 3 Apr 2019 at 16:49, Ruxandra Avram via so  wrote:
>
> Salut,
>
> Am submis tema pe vmchecker și am observat 2 erori ciudate la ultimele 2 
> teste : mesg: ttyname failed: Inappropriate ioctl for device. Această eroare 
> nu este semnalată, însă, pe mașina virtuală.
> Care ar putea fi cauza?
>
> Username-ul pe cs.curs este maria.avram și codul sursă este încărcat și pe 
> gitlab.
>
> Mulțumesc!
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Vmchecker indisponibil

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Pai daca exprimati problemele ca naiba normal ca nu imi pot da seama
ce se intampla: deci vmchecker este disponibil insa cand submiti o
tema 2 pe windows primesti eroarea: vmexecutor exitcode 1 (error)

O sa verific ce se intampla.


On Wed, 3 Apr 2019 at 11:27, Ionuț Mihalache  wrote:
>
> Și nu merge, iarăși eroare.
>
> În mie., 3 apr. 2019 la 11:26, Ionuț Mihalache  a scris:
>>
>> Am trimis iar și acum este pare că o să testeze
>>
>> În mie., 3 apr. 2019 la 11:25, Ionuț Mihalache  a 
>> scris:
>>>
>>> Mie la windows nu îmi testează
>>>
>>> În mie., 3 apr. 2019 la 11:23, Mihai Barbulescu  a 
>>> scris:

 Salut,

 Eu m-am putut loga si am putut si sa submit o tema si sa imi fie testata.

 On Wed, 3 Apr 2019 at 11:13, Ionuț Mihalache via so
  wrote:
 >
 > Salut,
 >
 > Se pare că vmchecker iar nu mai funcționează. Motivul este pentru că se 
 > lucrează la el sau iar este down?
 > ___
 > http://ocw.cs.pub.ro/courses/so/info/lista-discutii



 --
 Cu stimă,
 Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Vmchecker indisponibil

2019-04-03 Fir de Conversatie Mihai Barbulescu via so
Salut,

Eu m-am putut loga si am putut si sa submit o tema si sa imi fie testata.

On Wed, 3 Apr 2019 at 11:13, Ionuț Mihalache via so
 wrote:
>
> Salut,
>
> Se pare că vmchecker iar nu mai funcționează. Motivul este pentru că se 
> lucrează la el sau iar este down?
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2] [Prelungire deadline]

2019-04-02 Fir de Conversatie Mihai Barbulescu via so
Așa cum am mai spus și pe alt thread vedem mâine în ziua deadline ce se
întâmplă. Lucram peste cap ca să facem sa meargă începând cu seara asta

Insist asupra faptului ca trebuie sa testați folosind mașinile virtuale
căci sunt identice cu ce e pe vmchecker

Știm de un singur test care ar putea cauza probleme. Dacă aceste probleme
cu acel test se reproduc și la alți studenți și problema e la noi îl vom
scoate și veți primi automat punctaj pe el.

Nu mai cereți va rog prelungirea deadline. Vom fi rezonabili și știm de
probleme.

On Tue, Apr 2, 2019, 18:57 Paul Olaru via so  wrote:

> Mașinile virtuale au inițial aceeași configurație ca ce e pe VMchecker,
> doar să nu fi schimbat tu ceva la ele.
>
> Dacă mâine rămâne picat VMcheckerul, am văzut deja un mail care anunță că
> s-ar face prelungiri în această condiție.
>
> On Tue, Apr 2, 2019, 18:54 Soare Loredana via so 
> wrote:
>
>>
>> Buna ziua,
>> Din cauza faptului ca vmchecker ul este picat de vreo 2 zile, mulți
>> dintre noi nu si au putut submite/verifica temele. Întrucât, uneori, exista
>> diferențe între punctajul obținut pe mașina virtuală si punctajul obținut
>> pe vmchecker, v am ruga, dacă se poate, sa ne prelungiți deadline ul cu
>> câteva zile, deoarece nu ne putem verifica corespunzător, riscând sa
>> pierdem punctaj pe anumite teste.
>> Mulțumesc!
>> Trimis de pe iPhone‑ul meu
>> ___
>> 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

Re: [so] [SO][Tema2][Modificare deadline]

2019-04-02 Fir de Conversatie Mihai Barbulescu via so
Buna,

Vom lua o decizie legata de prelungire __DOAR__ daca si in ziua/seara
deadline-ului si anume 3.04.2019 are vmchecker probleme si nu merge.
Deocamdata se lucreaza la restaurarea lui.

Pana una alta va puteti testa tema folosind masinile virtuale de SO
[1] - n-aveti nevoie de vmchecker - sunt identice cu ce este pe
vmchecker.

[1] https://ocw.cs.pub.ro/courses/so/info/mv

On Tue, 2 Apr 2019 at 16:01, Adelina-Georgiana DAVID (67095) via so
 wrote:
>
> Salut,
>
>
>
> Avand in vedere ca Vmchecker-ul inca nu merge, se va prelungi deadline-ul 
> soft?
>
>
>
> Multumesc.
>
>
>
> O zi buna,
>
> David Adelina
>
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] Backend vmchecker indisponibil

2019-04-01 Fir de Conversatie Mihai Barbulescu via so
Salutare,

Va reamintesc ca puteti testa local, pe statiile voastre, temele la SO
folosind masinile virtuale identice cu cele de pe vmchecker, de aici:
https://ocw.cs.pub.ro/courses/so/info/mv


On Mon, 1 Apr 2019 at 23:53, Razvan Deaconescu via so
 wrote:
>
> Salutare.
>
> Sistemul back end pe care rulează mașinile virtuale ale vmchecker este
> indisponibil începând de aseară. Lucrăm să reparăm problemele. Puteți
> submite temele, interfața web[1] e disponibilă, dar nu vor fi testate.
>
> Atunci când vom rezolva, vom trimite temele pentru corectare, nu va fi
> nevoie să le resubmiteți.
>
> [1] https://vmchecker.cs.pub.ro/ui/
>
> Răzvan
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Windows] vmchecker says popen read too many syscalls

2019-04-01 Fir de Conversatie Mihai Barbulescu via so
Nu doar VM, trimite-ne __TOT__ outputul: de pe masinile virtuale de SO
si de pe vmchecker.

On Mon, 1 Apr 2019 at 11:01, George Diaconu  wrote:
>
> Da, folosesc masinile virtuale de la SO.
> Am sa trimit rezultatele de pe VM cand ajung acasa.
>
>
> On Mon, Apr 1, 2019, 10:51 Mihai Barbulescu  wrote:
>>
>> Tu cand rulezi testele le rulezi folosind masinile virtuale de SO [1]
>> ? Parerea mea e sa rulezi folosind masinile virtuale de SO si sa ne
>> trimiti si noua cum arata rezultatele IN MASINILE VRITUALE DE SO
>> versus vmchecker
>>
>> [1] https://ocw.cs.pub.ro/courses/so/info/mv
>>
>> On Sun, 31 Mar 2019 at 20:44, George Diaconu via so
>>  wrote:
>> >
>> > Salut,
>> >
>> > Vin cu o problema veche de cand lumea, local trec toate testele fara
>> > probleme, pe vmchecker, testul popen read da fail cu mesajul
>> > "src/test_popen_read.c:96: Incorrect number of reads: got 220,
>> > expected 5".
>> > O singura data a trecut testul acesta pe vmchecker, si atunci nu am
>> > modificat nimic intre upload-uri. Acum am mai facut cateva modificari,
>> > local merge, dar pe vmchecker nu vrea...
>> > Nici nu stiu cum sa fac debugging in clipa asta...
>> > ___
>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>>
>>
>>
>> --
>> Cu stimă,
>> Mihai Bărbulescu



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2] VMChecker slow

2019-04-01 Fir de Conversatie Mihai Barbulescu via so
Salut,

O sa verificam intern. Va rog sa ne raportati daca problema persista.

Intre timp va rugam INSISTENT sa nu folositi vmchecker ca "tester" al
vostru, rulati checkerul (aveti sursele si indicatii pe github [1]) pe
masinile virtuale de SO [2] care au setup IDENTIC cu ce este pe
vmchecker. Daca submiteti in continuu teme pe vmchecker normal ca se
va bloca coada si va sta ocupat sa testeze cate o bucatica pe care
fiecare o submite de 10 ori la testare.

Daca nu stiti sau nu va descurcati sa rulati checkerul pe masinile
virtuale folosind [1] puteti pune intrebari pe lista ca va vom
raspunde.

INSIST: nu submiteti de enspe mii de ori fiecare modificare sa va fie
testata pe vmchecker!!

[1] https://github.com/systems-cs-pub-ro/so-assignments/tree/master/2-stdio
[2] https://ocw.cs.pub.ro/courses/so/info/mv

On Mon, 1 Apr 2019 at 10:05, Paul Olaru via so  wrote:
>
> S-a întâmplat ceva bizar că nici nu se poate conecta VMchecker în sine să 
> VADĂ coada temelor în așteptare... Suspectez că a da un restart la acea 
> mașină nu ar fi o idee rea
>
> On Mon, Apr 1, 2019, 10:01 Gmail via so  wrote:
>>
>> Se poate verifica mașina pe care rulează temele ? Am impresia că ceva s-a 
>> blocat în loop si consumă foarte multe resurse.
>> Testele ori iau enorm de mult ori nu trec din cauză că durează prea mult.
>>
>> Get BlueMail for Android
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] [Tema2][Windows] vmchecker says popen read too many syscalls

2019-04-01 Fir de Conversatie Mihai Barbulescu via so
Tu cand rulezi testele le rulezi folosind masinile virtuale de SO [1]
? Parerea mea e sa rulezi folosind masinile virtuale de SO si sa ne
trimiti si noua cum arata rezultatele IN MASINILE VRITUALE DE SO
versus vmchecker

[1] https://ocw.cs.pub.ro/courses/so/info/mv

On Sun, 31 Mar 2019 at 20:44, George Diaconu via so
 wrote:
>
> Salut,
>
> Vin cu o problema veche de cand lumea, local trec toate testele fara
> probleme, pe vmchecker, testul popen read da fail cu mesajul
> "src/test_popen_read.c:96: Incorrect number of reads: got 220,
> expected 5".
> O singura data a trecut testul acesta pe vmchecker, si atunci nu am
> modificat nimic intre upload-uri. Acum am mai facut cateva modificari,
> local merge, dar pe vmchecker nu vrea...
> Nici nu stiu cum sa fac debugging in clipa asta...
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

  1   2   3   4   >