Thread: Problem with reading/writing in "classic" unix

I have some c code that works fine on a unix server (which I have come to understand is based on "System V" unix), but it blows up on my local macbook (which I have come to understand is "classic" unix).

The purpose of the code is to take a ascii file and form it into a series of structures, then rewrite it to a separate file in binary.

Code:

int main( void )
{
    char filename[10];
    FILE *from, *to;
    char buff[100];
    Class buf;

    printf("\nEnter the name of your file: ");
    scanf("%s", filename);

    from = fopen(filename, "r");
    if (!from)
        printf("Error opening file\n");
    else
    {
        sprintf(filename, "%s.bn", filename);
        printf("\nCreated File\n");
        to = fopen(filename, "wb");
        if (!to)
            printf("Error opening to file\n");
        else
        {
            while(fgets(buff, sizeof(buff), from) != NULL)
            {
                if (sscanf(buff, "*format of Class struct*****, etc, etc, etc)) == 21)
                {
                    fwrite (&buf, 1, sizeof(buf), to);
                }
            }
            fclose (to);
        }
        fclose (from);
    }
    return 0;
}

When I run the program, I get a Bus error.

When I run the debugger, it says the problem is in the fgets function.

Code:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000038
0x9008b0e9 in fgets ()

C99 and POSIX.1-2001 specify that the results are undefined if a call
to sprintf(), snprintf(), vsprintf(), or vsnprintf() would cause to
copying to take place between objects that overlap (e.g., if the target
string array and one of the supplied input arguments refer to the same
buffer). See NOTES.

Code:

                    fwrite (&buf, 1, sizeof(buf), to); // drop the &

I'm not quite clear what you're trying to do. Question 2.11
Have you tried to use debugger???

Mac is based on BSD, which I don't see how that makes it any more "classic" than System V.

Anyway, if you're going to use the debugger, then save everybody a lot of pain by compiling your program with the -g flag, so that you get 75000% more information about what's going on, and you can see what the values of the variables are when your program dies, etc.

Anyway, if you're going to use the debugger, then save everybody a lot of pain by compiling your program with the -g flag, so that you get 75000% more information about what's going on, and you can see what the values of the variables are when your program dies, etc.

I'm not too familiar with the debugger. I was using gdb. When I attempted to compile the program using the -g flag, it had the same results (which I pasted before). I'm probably just unfamiliar with the commands to use in gdb.

GDB stands for GNU DeBugger, so using gdb is using the debugger, with gdb being the specific debugging tool and debugger being the general term for such a tool. tabstop was saying that using the -g flag when you compile will put file name, line number and symbol names in the file so when it crashes, you can find out exactly what line number and function you were in, and in what file. As a matter of fact, you can see the whole sequence of function calls leading to your crash with the "backtrace" command. It will also allow you to examine the name of some variables at the time it crashed, by doing something like "print foo".

Once you've compiled with -g, you can type "bt" in the debugger to see the call stack, with line numbers, of where you were in the program and what was what. For instance, if I do a silly little fgets into a NULL pointer, I get something like:

Code:

Program received signal SIGSEGV, Segmentation fault.
_IO_getline_info (fp=0x804b008, buf=0x0, n=98, delim=10, extract_delim=1, 
    eof=0x0) at iogetline.c:91
91	iogetline.c: No such file or directory.
	in iogetline.c
(gdb) bt
#0  _IO_getline_info (fp=0x804b008, buf=0x0, n=98, delim=10, extract_delim=1, 
    eof=0x0) at iogetline.c:91
#1  0x0018cf91 in _IO_getline (fp=0x804b008, buf=0x0, n=99, delim=10, 
    extract_delim=1) at iogetline.c:42
#2  0x0018bf9a in _IO_fgets (buf=0x0, n=100, fp=0x804b008) at iofgets.c:58
#3  0x0804847b in main () at segfault.c:8

and you can see at the bottom that we're at line 8 in my program, and that I called fgets with 0, 100, and <some weird file pointer> as the parameters (the next line up) which in turn called other things internally. You can also type "up" to go back through the list and print out variables.

Also: 0x38 is '8' so it would seem you passed a character where an address was expected.

Code:

(gdb) bt
#0  0x9008b0e9 in fgets ()
#1  0x00001f3b in main () at ClassRPG.c:77

Only two lines it shows...

How do I do the backtrace?

With the "backtrace" command I mentioned, or "bt" for short, as tabstop showed. You just did it.

Since your sample code only has 35 lines, clearly we can't help you locate the problem on line 77, but you certainly know where to start looking now. Post up that line with any relevant variable declarations. If you call fgets(buf, sizeof(buf), fp), let's see the definition of buf and fp.

Sorry if this is too simple, but are you sure that "from" and "to" are actually different files?

Before knocking yourself out with the debugger, have you checked the result of your sprintf statement, e.g.:

Code:

sprintf(filename, "%s.bn", filename);
printf("\nCreated File %s\n", filename);

Line 77 is this:

Code:

             while(fgets(buff, sizeof(buff), from) != NULL)

The file I am using is called "Classes". It is a series of numbers and letters like this:

Code:

1  5  5  1  5  8  5  8  5  9  5  15 10 0  0  7  1  0  7  8  Squire
2  7  10 2  6  12 8  9  8  10 8  20 16 0  0  7  1  0  9  10 Warrior

After running my program, it is supposed to convert this text file to a series of structures of type "Class". When I run it on the unix server, it works appropriately and creates a file called "Classes.bn" that can then be used by a different program of mine. When I run it on the macbook, it does create the "Classes.bn" file, but blows up with the error as I show above. The Classes.bn file is empty.

R.Stiltskin's has a point, the problem is with your sprintf. filename is too short for "Classes.bn" since you have 10 plus the null. Thus, your sprintf is overflowing one byte into your from FILE pointer, trampling on it and causing your problem. Aside from that, the standard says (section 7.19.6.6, paragraph 2), that behavior is undefined when copying takes place between objects that overlap, as in your case where you copy from and to the same buffer. Create a second buffer for to_filename, and make sure it's big enough for your whole filename plus a null.

Thanks! By having a second buffer with to_filename and having it be long enough for the whole filename plus a null, it works!

I'm not sure why it worked the other way on the unix server, but I'm going to update the code so it works on both.