gcc 4.3.2 compiler included with kubuntu fails on simple structure

[Robert Ramey]

I have simple test case of a program which manifests a problem I have in a much larger program.

The problem is something to do with structure member access when one of he members is 64 bits long. I've (tried to) include three files which easily reproduce the problem: main.c testrio.c and testrio.h

I got kubuntu from a CD in "The official Ubuntu Book". I don't know which version it is. I subsequently installed the the gcc compiler via the GUI. Things seemed to work well. In fact I tested it on several simple programs. When I started to build my main project - I had problems which I have distilled to this simple test. You can only imagine the amount of time it takes to isolate this. gcc -v produces
ramey@Robert-Desktop:~/psort/nix/linux/testrio$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++
,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexec
dir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --wi
th-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=g
nu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=
i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)

The attachment system here only lets me include one file. I've concatonated the three files here instead:

/******** testrio.h **********/
#ifndef __TESTRIO__
#define __TESTRIO__

#define _FILE_OFFSET_BITS 64
#include <sys/types.h> /* off_t */

typedef struct {
 off_t fs;
 unsigned int i1;
 unsigned int i2;
} TESTRIO;

extern int
rio_init(TESTRIO *rio);

#endif /* __TESTRIO__ */

/********* testrio.c ***********/
#include "testrio.h"

extern int
rio_init(TESTRIO *rio){
    rio->fs = (off_t)(-1);
    rio->i1 = 1;
    rio->i2 = 2;
    return 0;
}

/********* main.c ************/
#include <stdio.h> /* printf */
#include "testrio.h"

int
main(
 int argc,
 char *argv[]
){
 TESTRIO rio;
    rio_init(&rio);

    printf("i1=%u, i2=%u\n", rio.i1, rio.i2);
 return 0;
}

I use the following command line to build this test:

gcc -ggdb -o testrio main.c testrio.c

I run the test with:

ramey@Robert-Desktop:~/psort/nix/linux/testrio$ ./testrio
i1=4294967295, i2=1
Bus error

As you can see, the output is not what one would expect from looking at testrio.c

Please suggest to me what I should do.

Thank you.

Robert Ramey

PS. I've compiled the same programs on my cygwin gcc 4.32 compiler with no surprises or problems. It is for this reason I suspect the gcc version distributed with ubuntu.
RR

[Robert Ramey (ramey)]

In looking for a solution to this problem, I discovered that gcc-4.2 is also installed on my system.

ramey@Robert-Desktop:~/psort/nix/linux/testrio$ gcc-4.2 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-
++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --wit
out-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir
/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstd
xx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=
elease --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-3ubuntu4)

I get the same results here.

[Robert Ramey (ramey)]

Is there any chance of anyone confirming this soon?

Robert Ramey

[Thomas Suckow (thomas-suckow)]

$ cat /proc/version
Linux version 2.6.32-24-generic (buildd@crested) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

$ ./testrio
i1=1, i2=2

[Robert Ramey (ramey)]

First of all, thanks for looking into this.

The difference in our environments is:

gcc 4.3.2 32 bit x86 vs gcc 4.4.3 64 bit x86

So it could be either the 32 vs 64 bits or 4.3.2 vs 4.4.3

The following structure has a different layout between 32 64 bit systems. I suspect that is when the problem shows up.

typedef struct {
 off_t fs;
 unsigned int i1;
 unsigned int i2;
} TESTRIO;

I ran another test that included all the code in one module.

**** test file

#include <stdio.h> /* printf */

#define _FILE_OFFSET_BITS 64
#include <sys/types.h> /* off_t */

typedef struct {
 off_t fs;
 unsigned int i1;
 unsigned int i2;
} TESTRIO;

int
rio_init(TESTRIO *rio){
    rio->fs = (off_t)(-1);
    rio->i1 = 1;
    rio->i2 = 2;
    return 0;
}
int
main(
 int argc,
 char *argv[]
){
 TESTRIO rio;
    rio_init(&rio);
    printf("i1=%u, i2=%u\n", rio.i1, rio.i2);
 return 0;
}

**** end test code

This in fact passed. So the problem is s subtle one and might be related to linkage or whatever.

Robert Ramey

[Robert Ramey (ramey)]

ping -

has anyone verified this?

Robert Ramey

[Robert Ramey (ramey)]

This can be closed.

I found that using

#define _FILE_OFFSET_BITS 64
#include <sys/types.h> /* off_t */

doesn't work as sys/types.h is imported by other standard headers
so _FILE_OFFSET_BITS has to be defined BEFORE all standard
headers rather than just before one's usage of sys/types.h.

Defining _FILE_OFFSET_BITS globally "fixes" the problem.

Robert Ramey