delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/07/08/22:50:38

Message-ID: <3B491E33.D4BF2444@alpha.delta.edu>
Date: Sun, 08 Jul 2001 23:00:03 -0400
From: "David Witbrodt" <dawitbro AT alpha DOT delta DOT edu>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: DJGPP mailing list <djgpp AT delorie DOT com>
Subject: Re: statfs() mystery deepens -- DJGPP workers exonerated, though!
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010708112931 DOT 24414Q-100000 AT is>
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> > The discrepancy is here -- the statfs() "TEST" program reports 1 002
> > 886 available blocks, while the call of statfs() in my program only
> > yields 983040 available blocks.  (Immediately exiting gdb and running
> > the "TEST" program still yields 1 002 886 available blocks.)
> 
> What happens if you type this inside GDB:
> 
>   (gdb) shell statfstest
> 
> What does statfstest report then?

  See below.  At work today, my program and statfstest gave the same
bytes free on an older Win95 machine, which made me blink a few
times.  Maybe it's _not_ my fault after all!


> > I should point out that I am compiling statfs() as a C++ function
> 
> That is almost definitely a bad idea (although I don't think it
> explains the discrepancy).  DJGPP library sources were not written to
> be compiled as C++ code, so all kinds of irrelevant side effects might
> materialize.
> 
> Why don't you compile statfs as C code?

  In my naivete I thought that compiling one source file with GCC and
the rest with GXX would cause some sort of problem.  When I ran things
at work today, where the output was the same, it was with statfs.c
compiled by GCC and my sources compiled with GXX.  I thought I might
have solved the problem...

  Unfortunately, now that I am at home using the Win98 machine,
matters are still confusing.  After adjusting my makefile to compile
statfs.c with GCC instead of GXX, and compiling everything with
stabs+, I ran GDB on my program.  Here is the most relevant screenful
of information:

(gdb) p main::argv[1]
$5 = 0x983e8 "c:"
(gdb) n
306             statfs(fspec, &fs);
(gdb)
307             bt = (unsigned long long) fs.f_bsize * fs.f_blocks;
(gdb)
308             bf = (unsigned long long) fs.f_bsize * fs.f_bfree;
(gdb)
313             const unsigned ipu = ftotalbytes * 100 / bt;
(gdb) shell statfstest c:
Results for `c:':

Total blocks: 2044282
Available blocks: 1002804
Block size: 4096
(gdb) p fs
$6 = {f_type = 0, f_bsize = 4096, f_blocks = 2044282, f_bfree =
983040,
  f_bavail = 983040, f_files = 2044282, f_ffree = 983040, f_fsid = {2,
0},
  f_magic = 72020}

  [Some line numbers changed a little from my previous message because
of some comment lines I changed in this source file.]  Somehow the
statfs TEST program still reports a different number of available
blocks (f_bfree) than the call of statfs() in my program, even though
the TEST program is called while mine is resident in memory with GDB.
  Incidentally, I checked out the size of my swap file before, during
(using shell), and after the GDB session.  It's size is a constant 320
Mb (as per my manual settings described in my last post).  My program
doesn't access the file system except to read the file information; it
certainly doesn't create any files, nor is it large enough that
Windows should have to start swapping things anyway.

  On a whim, I added a system() call to my main() right before the
program exits just to see if GDB's presence somehow makes a
difference:

        ...
        system ("statfstest c:");
        return EXIT_SUCCESS;
}

  This is the output of my program (truncated on the right, and minus
the nice colors, of course):


 1 c:\djgpp\programs\files\prog07\*.*
     8328 cmdline.cpp           203 cmdline.h           12050 cmd
     5513 finfo.cpp             461 finfo.h             10285 fin
    11575 lstpg3.cpp         271130 lstpg3.exe           1103 lst
    24193 lstpg3.o              345 makefile             8945 sta
    17149 statfs.o           112883 statfstest.>
 Files          Dirs          Bytes Used          Bytes Free     
    14             0              484163           4026531840     
Results for `c:':

Total blocks: 2044282
Available blocks: 1002793
Block size: 4096


  This last part is the output of the system() call to statfstest. 
The result of 1002793 * 4096 is 4 107 440 128 bytes, a discrepancy of
80 908 288 bytes again.

  Following the advice of MartinS in a previous post, I created a
dummy function called get_f_bfree() that I call at several points in
main().  I save the output of the function in a long int called
"freeblocks" that is local to main().  In GDB, every call of
get_f_bfree() returns 1 002 802; then main() calls a function called
printtotals() which does its own call to statfs().  This is where
matters become absurd:

(gdb) p fs
$5 = {f_type = 0, f_bsize = 4096, f_blocks = 2044282, f_bfree =
983040,
  f_bavail = 983040, f_files = 2044282, f_ffree = 983040, f_fsid = {2,
0},
  f_magic = 72020}
(gdb) p main::freeblocks
$6 = 1002802
(gdb) shell statfstest
Results for `.':

Total blocks: 2044282
Available blocks: 1002802
Block size: 4096

  The call to statfs() in printtotals() returns 983040 blocks free,
while the earlier calls to statfs() back in main() had returned
1002802 blocks free, as does statfstest.exe!

  I am simply dumbfounded.
  As I indicated in my original post, it is not critical that I have
perfect results, but now my curiosity is aroused.  I have to know...
WHY!!!!


Thanks for the assistance,
Dave W.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019