[so] [Tema2][Linux] valgrind - File descriptor deschisi

[Costin Lupu]

În testele tale, valgrind îți raportează de fiecare dată că file
descriptorii standard rămân deschiși. Când faci redirectare-restaurare
valgrind știe să-ți spună și unde s-a inițializat ultima oară file
descriptorul stdout. În rest îți zice că i-ai moștenit din părinte, mai
multe informații nu-ți poate da.

Deci e o raportare firească. Ba mai mult, indică un comportament corect,
că stdout-ul a fost redirectat-restaurat.

Costin

On 03/27/2018 07:54 PM, Alex Albu wrote:
> Salut.
> 
> Mersi pentru raspunsul rapid!
> 
> Exact asta ma nelamureste - faptul ca valgrind practic imi raporteaza un
> fd standard si o face ca urmarea a apelului dup2. Nu imi e clar daca se
> intampla pentru ca e un comportament normal al valgrind sau pentru ca
> intr-adevar nu inchid un fd. Si spun asta pentru ca in celelalte teste
> unde nu fac procesul asta de redirectare-restaurare std fd nu apar
> deschise decat fd-uri mostenite de la parinte.
> 
> 
> *Alex Albu*
> +40 747 288 154*
> *
> 
> 
> 2018-03-27 19:47 GMT+03:00 Costin Lupu <costin.lup at gmail.com
> <mailto:costin.lup at gmail.com>>:
> 
>     Salutare, Alex,
> 
>     Din ce văd eu e vorba despre file descriptorul 1. Tema nu cere să
>     închideți file descriptorii STD{IN,OUT,ERR}. Unde e problema?
> 
> 
>     Costin
> 
>     On 03/27/2018 07:09 PM, Alex Albu via so wrote:
>     > Salut.
>     >
>     > Intampin urmatoarea problema la rularea testelor cu valgrind - la
>     > restaurarea stdout in urma unei redirectari este raportat ca ramanand
>     > deschis un fd care arata fie catre /dev/null fie ...testxx.in <http://testxx.in>
>     > <http://testxx.in>
>     >
>     > In urma verificarilor, in special la testul 5 care este cel mai simplu
>     > si nu implica procese aditionale, pare ca nu se inchide fd-ul
>     > corespunzator copie de back-up a stdout desi close-ul e scris si nu pare
>     > sa dea eroare. Testand in afara checkerului este raportat ca inca
>     > deschis terminalul.
>     >
>     > Codul cu pricina se afla in cmd.c, linia 161 pe userul de gitlab tmp_stud19.
>     >
>     > As aprecia orice sugestie :)
>     >
>     > Multumesc,
>     >
>     > Alex Albu
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>     <http://ocw.cs.pub.ro/courses/so/info/lista-discutii>
>     >
> 
>