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 ([email protected])
http://compton.nu/

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to