>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 <t...@compton.nu>
To: Mahmood Naderan <nt_mahm...@yahoo.com>
Cc: "valgrind-users@lists.sourceforge.net"
<valgrind-users@lists.sourceforge.net>
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 (t...@compton.nu)
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
