Problem with fopen

[Guy Garty]

Hi,
I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include <stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
[....]

if ((OutFile[j]=fopen(FileName,"w"))==NULL)
{
OutFile[j]=stdout;
}

[...]
return OutFile[j];
}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).
What is going on here?
guy

 

[Ian Collins]

Hi,
I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include<stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
[....]

if ((OutFile[j]=fopen(FileName,"w"))==NULL)
{
OutFile[j]=stdout;
}

[...]
return OutFile[j];
}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).

What is going on here?

It looks like a typical 32/64 bit build or link muddle.

What is in the global array?

Are you compiling and linking everything with the same compiler options?

 

[Paul N]

Hi,
 I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include <stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
        [....]

        if ((OutFile[j]=fopen(FileName,"w"))==NULL)
        {
         OutFile[j]=stdout;
        }

        [...]
        return OutFile[j];

}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).
What is going on here?
guy

What you've shown us looks right, so the problem is probably in a bit
that you haven't shown us. For instance, what are j and FileName?

Please cut the real code down to a small, self-contained bit that
nevertheless fails to work properly, and post that. If doing so hasn't
already found you your problem.

 

[Keith Thompson]

Hi,
I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include<stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
[....]

if ((OutFile[j]=fopen(FileName,"w"))==NULL)
{
OutFile[j]=stdout;
}

[...]
return OutFile[j];
}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).

What is going on here?

It looks like a typical 32/64 bit build or link muddle.

Agreed. Note that 0xffffffffb00da680 appears to consist of the
low-order 32 bits of 0x2aaab00da680, with the high-order 32-bits
set to all 1s.

But how exactly do you know that fopen is returning 0x2aaab00da680 and
your function is returning 0xffffffffb00da680? Are you seeing these
values in a debugger? Are you printing them with printf? If the
latter, what format are you using?

You can print (an implementation-specific representation of) a FILE*
value with:

printf("stdout = %p\n", (void*)stdout);

But if you're trying to use some integer format such as "0x%08x" to
print a pointer value, you're likely to get garbage.

 

[David Resnick]

Hi,
 I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include <stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
        [....]

        if ((OutFile[j]=fopen(FileName,"w"))==NULL)
        {
         OutFile[j]=stdout;
        }

        [...]
        return OutFile[j];

}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).
What is going on here?
guy

As others said, may be 32 bit vs 64 bit muddle. I assume the value of
"j" is reasonable (as in <= 9?). Can you come up with a minimal
functional program that reproduces the problem?

Could also be a different issue. As you are on linux, valgrind might
be helpful...

-David

 

[Guy Garty]

I am compiling and linking everything with the same flags:
-g -Wall -std=c99 and I've just added -m64 but it doesn't seem to make
a difference

I see the values using the debugger (i.e. p OutFile[j] in gdb) but
printf("%p" (void *) OutFile[j]) gives the same results.

In a compact code that just opens files, I never get to huge pointers
even if I open hundreds of files.
In my "big" code problems start around j=3 or 4.
I assume that the problem is that in the full code, I also allocate
almost 100 MB of image buffers.
guy

 

[Seebs]

In a compact code that just opens files, I never get to huge pointers
even if I open hundreds of files.

I have no idea what you mean by "huge pointers".

In my "big" code problems start around j=3 or 4.
I assume that the problem is that in the full code, I also allocate
almost 100 MB of image buffers.

Unlikely. 100MB is peanuts.

My guess is that, more likely, in the full code something is getting
overwritten.

-s

 

[Alan Curry]

Agreed. Note that 0xffffffffb00da680 appears to consist of the
low-order 32 bits of 0x2aaab00da680, with the high-order 32-bits
set to all 1s.

My guess is that it's being called without a prototype, and the compiler is
assuming a 32-bit int return value, and converting to a 64-bit pointer by
sign-extending it. It would definitely produce a warning about conversion
from integer to pointer without a cast, so this hypothesis also assumes that
the original programmer was an "ignore the warnings, I got an executable,
let's run it!" type.

 

[Eric Sosman]

My guess is that it's being called without a prototype, and the compiler is
assuming a 32-bit int return value, and converting to a 64-bit pointer by
sign-extending it. It would definitely produce a warning about conversion
from integer to pointer without a cast, so this hypothesis also assumes that
the original programmer was an "ignore the warnings, I got an executable,
let's run it!" type.

"Without a prototype" seems unlikely, since the code as shown
includes <stdio.h>. Even if we're tempted to dismiss the inclusion
as a figment of somebody's imagination, we've got to admit that a
declaration of FILE came from *somewhere* -- and <stdio.h> is surely
the most likely source.

Seems to me that Paul N is on the most productive trail here.
Let's see the rest of the code!

 

[Alan Curry]

"Without a prototype" seems unlikely, since the code as shown
includes <stdio.h>. Even if we're tempted to dismiss the inclusion
as a figment of somebody's imagination, we've got to admit that a
declaration of FILE came from *somewhere* -- and <stdio.h> is surely
the most likely source.

<stdio.h> is supposed to provide the prototype for OpenLog?

We didn't see the call to OpenLog, so we don't know if it was in the same
source file. My guess assumed that it wasn't, so a prototype was needed, and
forgotten.

You don't have to agree that it's the best guess, and you can easily conclude
that I'm only wasting my time by guessing the answer to an incomplete
question, but you could at least give me credit for making a guess that's
compatible with the limited evidence.

 

[Eric Sosman]

<stdio.h> is supposed to provide the prototype for OpenLog?

Sorry; I'd read your "it's" as referring to fopen(). It's
now clear that it's isn't that it's but another it's of its own,
isn't it?

 

[David Resnick]

I have no idea what you mean by "huge pointers".

He presumably means ones with "largish" values, as in much > 2^32,
that are generally don't look like valid pointers on his system.

I'd still suggest valgrind, btw. Often can point you straight at the
problem.
If you reduce the issue to a small test program and it goes away,
means the
issue is most likely elsewhere, not in this code.

-David

 

[Mark Bluemel]

Hi,
I have a problem with a function returning a FILE * value
(I am using gcc on Red hat enterprise 5, 64bit)
My function is supposed to open a file and return a pointer to it:

#include<stdio.h>
FILE *OutFile[10];

FILE *OpenLog(int x, int y, int h, int w, char *LogString)
{
[....]

if ((OutFile[j]=fopen(FileName,"w"))==NULL)
{
OutFile[j]=stdout;
}

[...]
return OutFile[j];
}

The first few times, it works ok, returning values like 0x37849c0.
After the third or fourth call, fopen starts returning values like
0x2aaab00da680. These values are not NULL and the file appears to be
created properly, however the value returned by my function is now
0xffffffffb00da680 and all hell breaks loose (Segmentation Fault when
accessing the file).
What is going on here?
guy

I think Alan Curry has the right idea here.

Where is your OpenLog() function called from? What prototype for
OpenLog() is in place in that code?

 

[Guy Garty]

Thank you all for your help.
Allan Curry was right, one of the modules from which I called OpenLog
was missing the appropriate #include.
I added it and everything seems to work now. The pointers are still

2^32 but using them no longer gives a segmentation fault.

Just for the record, I am NOT an "ignore the warnings, I got an
executable, let's run it!" type. I am usually very careful on which
warnings I ignore and which ones I don't and an "implicit declaration
of..." is one I usually don't, especially if it's for one of my
routines. Not sure how I let that one slip.
guy