Ubuntu

gcc chokes under Karmic's smbfs

Reported by rogmorri on 2009-10-19
84
This bug affects 15 people
Affects Status Importance Assigned to Milestone
gcc-defaults (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by vangloria

Bug Description

I'm guessing that this is a gcc problem (both gcc-4.3 and gcc-4.4) that's exposed by the latest samba/cifs code in Karmic, but maybe this is a samba problem, or maybe something else.

I can't seem to run gcc in a samba-mounted directory under Karmic (up to date as of 2009-10-18), but this was okay in 9.04 Ubuntu....

rsm@hina:/c/Temp/y$ mount | grep cifs
//1USL13385/C on /c type cifs (rw,mand)
rsm@hina:/c/Temp/y$ cat grape.c
int main() { return 0; }
rsm@hina:/c/Temp/y$ gcc grape.c
cc1: error: grape.c: Value too large for defined data type
rsm@hina:/c/Temp/y$

The problem seems to happen in cc1. I tried this with strace in
  - Karmic, local mount
  - Karmic, cifs mount
  - 9.04, cifs mount
and the only obvious difference I notice is the huge inode number in the Karmic/cifs combination...

# on local mount...
19665 open("grape.c", O_RDONLY|O_NOCTTY) = 3
19665 fstat64(3, {st_dev=makedev(8, 1), st_ino=15333, st_mode=S_IFREG|0755, st_nlink=1, st_uid=3872, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=25, st_atime=2009/10/18-22:53:16, st_mtime=2009/10/18-19:00:51, st_ctime=2009/10/18-22:53:04}) = 0
19665 read(3, "int main() { return 0; }\n", 25) = 25
19665 close(3) = 0

# on cifs mount...
19656 open("grape.c", O_RDONLY|O_NOCTTY) = 3
19656 fstat64(3, {st_dev=makedev(0, 23), st_ino=145241087983005616, st_mode=S_IFREG|0755, st_nlink=1, st_uid=3872, st_gid=1000, st_blksize=16384, st_blocks=1, st_size=25, st_atime=2009/10/18-19:13:16, st_mtime=2009/10/18-19:00:51, st_ctime=2009/10/18-22:31:53}) = 0
19656 close(3) = 0

# on cifs mount under ubuntu 9.04 ...
27026 open("grape.c", O_RDONLY|O_NOCTTY) = 3
27026 fstat64(3, {st_dev=makedev(0, 25), st_ino=167150, st_mode=S_IFREG|S_ISGID|0767, st_nlink=1, st_uid=0, st_gid=0, st_blksize=16384, st_blocks=1, st_size=25, st_atime=2009/10/18-23:02:00, st_mtime=2009/10/18-23:02:00, st_ctime=2009/10/18-23:02:00}) = 0
27026 read(3, "int main() { return 0; }\n"..., 25) = 25
27026 close(3)

workaround, from <http://stackoverflow.com/questions/2438890/cc1plus-error-include-value-too-large-for-defined-data-type-when-compiling-wit/2496749#2496749>:

When mounting the share add ,nounix,noserverino to the options, ie:

mount -t cifs -o user=me,pass=secret,nounix,noserverino //server/share /mount

rogmorri (frontporsche) wrote :
rogmorri (frontporsche) wrote :

My smbfs dependencies....

SourcePackage: samba
Package: smbfs 2:3.4.0-3ubuntu5
PackageArchitecture: i386
ProblemType: Bug
ProcEnviron:
  SHELL=/bin/bash
  LANG=en_US.UTF-8
Uname: Linux 2.6.31-14-generic i686
Dependencies:
  coreutils 7.4-2ubuntu1
  debconf 1.5.27ubuntu2
  debconf-i18n 1.5.27ubuntu2
  dpkg 1.15.4ubuntu2
  findutils 4.4.2-1
  gcc-4.4-base 4.4.1-4ubuntu8
  libacl1 2.2.47-2
  libattr1 1:2.4.43-3
  libc-bin 2.10.1-0ubuntu15
  libc6 2.10.1-0ubuntu15
  libcap2 1:2.16-5ubuntu1
  libcomerr2 1.41.9-1ubuntu2
  libdb4.7 4.7.25-7ubuntu2
  libgcc1 1:4.4.1-4ubuntu8
  libgcrypt11 1.4.4-2ubuntu2
  libgnutls26 2.8.3-2
  libgpg-error0 1.6-1ubuntu1
  libgssapi-krb5-2 1.7dfsg~beta3-1
  libk5crypto3 1.7dfsg~beta3-1
  libkeyutils1 1.2-10
  libkrb5-3 1.7dfsg~beta3-1
  libkrb5support0 1.7dfsg~beta3-1
  libldap-2.4-2 2.4.18-0ubuntu1
  liblocale-gettext-perl 1.05-4build1
  libncurses5 5.7+20090803-2ubuntu2
  libsasl2-2 2.1.23.dfsg1-1ubuntu3
  libsasl2-modules 2.1.23.dfsg1-1ubuntu3
  libselinux1 2.0.85-2ubuntu1
  libssl0.9.8 0.9.8g-16ubuntu3
  libstdc++6 4.4.1-4ubuntu8
  libtalloc1 1.4.0~git20090718-1
  libtasn1-3 2.2-1
  libtext-charwidth-perl 0.04-5build1
  libtext-iconv-perl 1.7-1build1
  libtext-wrapi18n-perl 0.06-7
  libwbclient0 2:3.4.0-3ubuntu5
  lsb-base 4.0-0ubuntu5
  lzma 4.43-14ubuntu1
  ncurses-bin 5.7+20090803-2ubuntu2
  netbase 4.35ubuntu2
  perl-base 5.10.0-24ubuntu4
  samba-common 2:3.4.0-3ubuntu5
  sed 4.2.1-1
  tzdata 2009n-2
  ucf 3.0018ubuntu1
  zlib1g 1:1.2.3.3.dfsg-13ubuntu3
Architecture: i386
Date: Sun Oct 18 23:36:39 2009
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
DistroRelease: Ubuntu 9.10

rogmorri (frontporsche) wrote :

I used USB Startup Disk Creator to make a boot thumbdrive from yesterday's (2009-10-20) daily build. I booted to that thumbdrive, and installed only: vim, build-essential, smbfs

I still observed the problem. :(

BTW, the remote file system was being served by Windows XP Profesional, version 2002, SP3

rogmorri (frontporsche) wrote :

Probably unrelated, but the system under test was an Aspire Acer One 110-1722.

summary: - gcc chokes on huge st_ino values.
+ gcc chokes under Karmic's smbfs
thinker0 (thinker0) wrote :

same problem

Same problem. Also affects avr-gcc using the same test code as the OP.

In my case the server is Ubuntu 8.04.3, Samba 3.0.28a-1ubuntu4.8

Scott Wills (scott-wills) wrote :

same problem, file server is D-Link DNS-321

vangloria (juanfhj) wrote :

Same problem, karmic koala, didn't have with smbfs under 9.04.

vangloria (juanfhj) wrote :

The problem happens both with smbfs and cifs in Karmic Koala.

rogmorri (frontporsche) wrote :

I added a bit of instrumentation to libcpp/files.c (where the error happens) and observed that the size of st_ino in struct stat is 4. This indicates that the cpp1 program wasn't built with -D_FILE_OFFSET_BITS=64.

I may well not have built cpp1 the same way it's built in Karmic, but in my case I again got the "Value too large..." error, and in my case the cause was definitely the huge inode number.

So, I suggest the problem is one of
  - A problem in gcc
  - A problem in the way gcc is built for Ubuntu
  - Maybe samba isn't supposed to be making these huge inode numbers.

This looks similar to bug #459548.

I would argue that the problem is rogmorri's option number 2.
Ubuntu is just not building gcc with -D_FILE_OFFSET_BITS=64

Have you tried recompiling gcc with -D_FILE_OFFSET_BITS=64?

rogmorri (frontporsche) wrote :

@joel, Unfortunately I'm not familiar with how gcc builds, but my impression from a very brief look through the code is that it automatically determines a _FILE_OFFSET_BITS value at configure time.

rogmorri (frontporsche) wrote :

I just installed some recent Samba updates, but it seems they aren't related to this issue. The problem still happens...

rsm@hina:/c/Temp/y$ gcc ./grape.c
cc1: error: ./grape.c: Value too large for defined data type

ana (ananroskat) wrote :

I purged karmics samba 3.4.0 and installed samba 3.2.2 I used in Jaunty (which worked just fine). I also tried older gcc. Same problem still occurs in both cases. I'm still a rookie with linux, but I think I got it right.

Pierre (snakepierre) wrote :

same problem

rogmorri (frontporsche) on 2009-12-01
tags: added: gcc samba
darteaga (darteaga) wrote :

Same problem here. Many programs don't work over a cifs share (e.g., latex, octave, gedit). Makes cifs shares useless for other purposes than archiving.

I believe I saw the same problem trying to load a capture file into Wireshark from a CIFS share as well.

vmappel (vmappel) wrote :

Add noserverino option to share declaration. It should be there by default but explicit specification fixed the problem.

Scott Wills (scott-wills) wrote :

I changed my fstab entry to add "noserverino" (I already had "nounix") and I can now run gcc on networked file server.
I also saw this advice in the following thread; a kernel bug is mentioned.

http://ubuntuforums.org/showthread.php?t=1312192

rogmorri (frontporsche) wrote :

Hooray, I can switch to Karmic now. :)

IMHO, I still think gcc should be built with large-file support.

rodrifra (rodrifra) wrote :

That solved the problem here too.

Changed in gcc-defaults (Ubuntu):
status: New → Confirmed
Martin Pool (mbp) on 2011-07-29
description: updated
Jose E Diaz (bori1517) wrote :

This kept happening to me so what i did was i wrote a script that moved the source code to the tmp directory and compiled it to the shared directory so it could be access in the network. I do hope gcc adds large file support =(.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers