|
From: Mahmood N. <nt_...@ya...> - 2011-08-23 17:16:46
|
>Give the invalid file descriptor (ie you're trying to close a descriptor
>that doesn't represent an open file) and the attempt to access
inaccessible
>memory inside fclose I'm guessing you passed it a dodgy
pointer.
You are right. Using verbose mode, it shows a failure in open file.
==4513== Warning: invalid file descriptor 1029 in syscall open()
==4513== at 0x413B7A3: __open_nocancel (syscall-template.S:82)
==4513== by 0x40E3F77: _IO_file_fopen@@GLIBC_2.1 (fileops.c:336)
==4513== by 0x40D8323: __fopen_internal (iofopen.c:93)
==4513== by 0x40D838B: fopen@@GLIBC_2.1 (iofopen.c:107)
==4513== by 0x804D903: fetch_thread (fetch.c:253)
==4513== by 0x804E4F8: fetch_core (fetch.c:394)
==4513== by 0x804E7D7: p_fetch (fetch.c:451)
==4513== by 0x8056B9C: p_stages (processor.c:664)
==4513== by 0x805083E: main (m2s.c:223)
==4513== Invalid read of size 1
==4513== at 0x40D7897: fclose@@GLIBC_2.1 (iofclose.c:52)
==4513== by 0x804DAFC: fetch_thread (fetch.c:275)
==4513== by 0x804E4F8: fetch_core (fetch.c:394)
==4513== by 0x804E7D7: p_fetch (fetch.c:451)
==4513== by 0x8056B9C: p_stages (processor.c:664)
==4513== by 0x805083E: main (m2s.c:223)
==4513== Address 0x46 is not stack'd, malloc'd or (recently) free'd
>Which means that your fopen probably failed, and returned null, but you
>didn't check the result to see if it had worked.
Some where in the code, I placed CLOSE_LOG after a break!
OPEN_LOG; (*)
...
CLOSE_LOG; // error happened here
...
OPEN_LOG
if (something) {
...
break;
...
}
CLOSE_LOG;
So what happened really was two OPEN_LOG and one CLOSE_LOG
Thanks a lot Tom. I fixed it :)
// Naderan *Mahmood;
----- Original Message -----
From: Tom Hughes <to...@co...>
To: Mahmood Naderan <nt_...@ya...>
Cc: "val...@li..." <val...@li...>
Sent: Tuesday, August 23, 2011 8:07 PM
Subject: Re: invalid file descriptor in syscall close()
On 23/08/11 16:10, Mahmood Naderan wrote:
> Hi
> Using valgrind to detect the problem, I see many messages like this:
>
> ==4513== Warning: invalid file descriptor 4546 in syscall close()
> ==4513== Warning: invalid file descriptor 4567 in syscall close()
> ==4513== Warning: invalid file descriptor 4567 in syscall close()
> ==4513== Warning: invalid file descriptor 1029 in syscall open()
> ...
> ==4513== Invalid read of size 1
> ==4513== at 0x40D7897: fclose@@GLIBC_2.1 (iofclose.c:52)
> ==4513== by 0x804DAFC: fetch_thread (fetch.c:275)
> ==4513== by 0x804E4F8: fetch_core (fetch.c:394)
> ==4513== by 0x804E7D7: p_fetch (fetch.c:451)
> ==4513== by 0x8056B9C: p_stages (processor.c:664)
> ==4513== by 0x805083E: main (m2s.c:223)
> ==4513== Address 0x46 is not stack'd, malloc'd or (recently) free'd
> ==4513==
> ==4513==
> ==4513== Process terminating with default action of signal 11 (SIGSEGV)
> ==4513== Access not within mapped region at address 0x46
> ==4513== at 0x40D7897: fclose@@GLIBC_2.1 (iofclose.c:52)
> ==4513== by 0x804DAFC: fetch_thread (fetch.c:275)
> ==4513== by 0x804E4F8: fetch_core (fetch.c:394)
> ==4513== by 0x804E7D7: p_fetch (fetch.c:451)
> ==4513== by 0x8056B9C: p_stages (processor.c:664)
> ==4513== by 0x805083E: main (m2s.c:223)
> ==4513== If you believe this happened as a result of a stack
> ==4513== overflow in your program's main thread (unlikely but
> ==4513== possible), you can try to increase the size of the
> ==4513== main thread stack using the --main-stacksize= flag.
> ==4513== The main thread stack size used in this run was 8388608.
>
> I have defined two macros like this:
> FILE *f;
> #define OPEN_LOG f = fopen("log.txt", "a+")
> #define CLOSE_LOG fclose(f)
>
> The line where segmentation fault occurred (fetch.c:275) is:
>
> CLOSE_LOG
Give the invalid file descriptor (ie you're trying to close a descriptor that doesn't represent an open file) and the attempt to access inaccessible memory inside fclose I'm guessing you passed it a dodgy pointer.
In fact given the address (0x46) that it tried to access it was most likely a null pointer.
Which means that your fopen probably failed, and returned null, but you didn't check the result to see if it had worked.
Tom
-- Tom Hughes (to...@co...)
http://compton.nu/
|