Message-ID: <3B491E33.D4BF2444@alpha.delta.edu> Date: Sun, 08 Jul 2001 23:00:03 -0400 From: "David Witbrodt" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: DJGPP mailing list Subject: Re: statfs() mystery deepens -- DJGPP workers exonerated, though! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.