|
From: Tom H. <to...@co...> - 2011-08-23 15:37:51
|
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/
|