gcc chokes under Karmic's smbfs

Bug #455122 reported by rogmorri
84
This bug affects 15 people
Affects Status Importance Assigned to Milestone
gcc-defaults (Ubuntu)
Won't Fix
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

Revision history for this message
rogmorri (frontporsche) wrote :
Revision history for this message
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

Revision history for this message
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

Revision history for this message
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
Revision history for this message
thinker0 (thinker0) wrote :

same problem

Revision history for this message
mikestir (i-launchpad-mikestirling-co-uk) wrote :

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

Revision history for this message
mikestir (i-launchpad-mikestirling-co-uk) wrote :

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

Revision history for this message
Scott Wills (scott-wills) wrote :

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

Revision history for this message
vangloria (juanfhj) wrote :

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

Revision history for this message
vangloria (juanfhj) wrote :

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

Revision history for this message
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.

Revision history for this message
Joel (t-launchpad-tannesen-com) wrote :

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?

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
Pierre (snakepierre) wrote :

same problem

rogmorri (frontporsche)
tags: added: gcc samba
Revision history for this message
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.

Revision history for this message
mikestir (i-launchpad-mikestirling-co-uk) wrote :

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

Revision history for this message
vmappel (vmappel) wrote :

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

Revision history for this message
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

Revision history for this message
rogmorri (frontporsche) wrote :

Hooray, I can switch to Karmic now. :)

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

Revision history for this message
rodrifra (rodrifra) wrote :

That solved the problem here too.

Revision history for this message
darteaga (darteaga) wrote :
Changed in gcc-defaults (Ubuntu):
status: New → Confirmed
Martin Pool (mbp)
description: updated
Revision history for this message
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 =(.

Revision history for this message
Matthias Klose (doko) wrote :

closing this as wont fix. karmic is EOL. Feel free to reopen if that's till seen with 20.04 LTS.

Changed in gcc-defaults (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.