Hi all!
Building the linux kernel, as well as doing a"make allyesconfig"
on a fresh checkout of linux HEAD results in the same Bus Error in
fixdep (details below). This is a i5 box running 32bit Ubuntu Lucid
with plenty of (free) RAM. Haven't found any hints to what might be
wrong on scanning over the web archives.
Regards
Christoph
-----
% make allyesconfig
HOSTCC scripts/basic/fixdep
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
fixdep: mmap: Cannot allocate memory
Bus error
make[1]: *** [scripts/basic/fixdep] Error 135
make: *** [scripts_basic] Error 2
On Thu, Jul 29, 2010 at 6:52 PM, Christoph Egger <[email protected]> wrote:
> Hi all!
>
> Building the linux kernel, as well as doing a"make allyesconfig"
> on a fresh checkout of linux HEAD results in the same Bus Error in
> fixdep (details below). This is a i5 box running 32bit Ubuntu Lucid
> with plenty of (free) RAM. Haven't found any hints to what might be
> wrong on scanning over the web archives.
>
> Regards
>
> Christoph
>
> -----
> % make allyesconfig
> HOSTCC scripts/basic/fixdep
> fixdep: mmap: Cannot allocate memory
So what does 'ls -lh scripts/basic/.fixdep.d' say?
Seems this file is too big...
On Thu, Jul 29, 2010 at 07:26:00PM +0800, Am?rico Wang wrote:
> On Thu, Jul 29, 2010 at 6:52 PM, Christoph Egger <[email protected]> wrote:
> > Hi all!
> >
> > ? ?Building the linux kernel, as well as doing a"make allyesconfig"
> > on a fresh checkout of linux HEAD results in the same Bus Error in
> > fixdep (details below). This is a i5 box running 32bit Ubuntu Lucid
> > with plenty of (free) RAM. Haven't found any hints to what might be
> > wrong on scanning over the web archives.
> >
> > Regards
> >
> > ? ?Christoph
> >
> > -----
> > ?% make allyesconfig
> > ?HOSTCC ?scripts/basic/fixdep
> > fixdep: mmap: Cannot allocate memory
>
> So what does 'ls -lh scripts/basic/.fixdep.d' say?
> Seems this file is too big...
% ls -lh scripts/basic/.fixdep.d
-rw-r--r-- 1 siccegge immdstud 2.4K 2010-07-29 12:51 scripts/basic/.fixdep.d
Doesn't really look that big to me
On Thu, Jul 29, 2010 at 07:26:00PM +0800, Am?rico Wang wrote:
> On Thu, Jul 29, 2010 at 6:52 PM, Christoph Egger <[email protected]> wrote:
> > Hi all!
> >
> > ? ?Building the linux kernel, as well as doing a"make allyesconfig"
> > on a fresh checkout of linux HEAD results in the same Bus Error in
> > fixdep (details below). This is a i5 box running 32bit Ubuntu Lucid
> > with plenty of (free) RAM. Haven't found any hints to what might be
> > wrong on scanning over the web archives.
> >
> > Regards
> >
> > ? ?Christoph
> >
> > -----
> > ?% make allyesconfig
> > ?HOSTCC ?scripts/basic/fixdep
> > fixdep: mmap: Cannot allocate memory
>
> So what does 'ls -lh scripts/basic/.fixdep.d' say?
> Seems this file is too big...
Also I don't get the mmap stuff if I call fixdep directly (the way I
think it is called staring at the build system) -- it still dies with
an bus error:
=======
% scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep "gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c"
cmd_scripts/basic/fixdep := gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c
deps_scripts/basic/fixdep := \
scripts/basic/fixdep.c \
$(wildcard include/config/his/driver.h) \
$(wildcard include/config/my/option.h) \
$(wildcard include/config/.h) \
$(wildcard include/config/foo.h) \
$(wildcard include/config/boom.h) \
zsh: bus error scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep
=======
gdb isn't of any use for that unfortunately
valgrund:
=======
==11601== Process terminating with default action of signal 7 (SIGBUS)
==11601== Non-existent physical address at address 0x64F2B000
==11601== at 0x8048BF0: parse_dep_file (in /var/tmp/siccegge/letssee/scripts/basic/fixdep)
=======
On Thu, Jul 29, 2010 at 02:10:02PM +0200, Christoph Egger wrote:
>On Thu, Jul 29, 2010 at 07:26:00PM +0800, Américo Wang wrote:
>> On Thu, Jul 29, 2010 at 6:52 PM, Christoph Egger <[email protected]> wrote:
>> > Hi all!
>> >
>> > Building the linux kernel, as well as doing a"make allyesconfig"
>> > on a fresh checkout of linux HEAD results in the same Bus Error in
>> > fixdep (details below). This is a i5 box running 32bit Ubuntu Lucid
>> > with plenty of (free) RAM. Haven't found any hints to what might be
>> > wrong on scanning over the web archives.
>> >
>> > Regards
>> >
>> > Christoph
>> >
>> > -----
>> > % make allyesconfig
>> > HOSTCC scripts/basic/fixdep
>> > fixdep: mmap: Cannot allocate memory
>>
>> So what does 'ls -lh scripts/basic/.fixdep.d' say?
>> Seems this file is too big...
>
>Also I don't get the mmap stuff if I call fixdep directly (the way I
>think it is called staring at the build system) -- it still dies with
>an bus error:
>
>=======
>% scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep "gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c"
>cmd_scripts/basic/fixdep := gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c
>
>deps_scripts/basic/fixdep := \
> scripts/basic/fixdep.c \
> $(wildcard include/config/his/driver.h) \
> $(wildcard include/config/my/option.h) \
> $(wildcard include/config/.h) \
> $(wildcard include/config/foo.h) \
> $(wildcard include/config/boom.h) \
>zsh: bus error scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep
>=======
>
>gdb isn't of any use for that unfortunately
>
>valgrund:
>=======
>==11601== Process terminating with default action of signal 7 (SIGBUS)
>==11601== Non-existent physical address at address 0x64F2B000
>==11601== at 0x8048BF0: parse_dep_file (in /var/tmp/siccegge/letssee/scripts/basic/fixdep)
>=======
This is useful. :) Looks like parse_dep_file() accesses out of
the mmap'ed memory range...
Please attach your scripts/basic/.fixdep.d. Thanks much!
On Fri, 30 Jul 2010 16:43:53 +0800, Américo Wang <[email protected]> wrote:
> This is useful. :) Looks like parse_dep_file() accesses out of
> the mmap'ed memory range...
>
Did anything ever happen with this? I seem to be experiencing similar
issues while cross-compiling for ARM on x86-64. All tested kernels
(v2.6.35 to master) fail with,
$ make
HOSTCC scripts/basic/fixdep
In file included from /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdlib.h:903,
from scripts/basic/fixdep.c:112:
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdlib.h:65: warning: no previous prototype for ‘ptsname_r’
/bin/sh: line 1: 20831 Bus error scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep 'gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c ' > scripts/basic/.fixdep.tmp
make[2]: *** [scripts/basic/fixdep] Error 135
make[1]: *** [scripts_basic] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
This seems to be the result of the same mmap misstep,
$ scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep 'gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c ' >| scripts/basic/.fixdep.tmp
fixdep: mmap: Cannot allocate memory
Which valgrind reports as,
==20634== Process terminating with default action of signal 7 (SIGBUS)
==20634== Non-existent physical address at address 0x51B2000
==20634== at 0x400F30: parse_dep_file (in /home/bgamari/linux/scripts/basic/fixdep)
==20634== by 0x401285: main (in /home/bgamari/linux/scripts/basic/fixdep)
==20634==
Any ideas?
- Ben
On Sat, 06 Nov 2010 11:07:48 -0400, Ben Gamari <[email protected]> wrote:
> On Fri, 30 Jul 2010 16:43:53 +0800, Américo Wang <[email protected]> wrote:
> > This is useful. :) Looks like parse_dep_file() accesses out of
> > the mmap'ed memory range...
> >
> Did anything ever happen with this? I seem to be experiencing similar
> issues while cross-compiling for ARM on x86-64. All tested kernels
> (v2.6.35 to master) fail with,
Here is .fixdep.d:
fixdep.o: scripts/basic/fixdep.c \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/types.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/features.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/cdefs.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/wordsize.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/gnu/stubs.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/types.h \
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/stddef.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/typesizes.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/time.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/endian.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/endian.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/byteswap.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/select.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/select.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/sigset.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/time.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/sysmacros.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/pthreadtypes.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/stat.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stat.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/mman.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/mman.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/unistd.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/posix_opt.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/confname.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/getopt.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/unistd.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/fcntl.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/fcntl.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/fcntl2.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/string.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/xlocale.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/string.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/string2.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdlib.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/string3.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/alloca.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdlib.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdio.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/libio.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/_G_config.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/wchar.h \
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/stdarg.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdio_lim.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/sys_errlist.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdio.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdio2.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/limits.h \
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed/limits.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/posix1_lim.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/local_lim.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/linux/limits.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/posix2_lim.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/ctype.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/arpa/inet.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/netinet/in.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdint.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/wchar.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/socket.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/uio.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/uio.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/socket.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/sockaddr.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/asm/socket.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/asm/sockios.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/socket2.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/in.h
On Sat, Nov 06, 2010 at 11:49:10AM -0400, Ben Gamari wrote:
> On Sat, 06 Nov 2010 11:07:48 -0400, Ben Gamari <[email protected]> wrote:
> > On Fri, 30 Jul 2010 16:43:53 +0800, Am?rico Wang <[email protected]> wrote:
> > > This is useful. :) Looks like parse_dep_file() accesses out of
> > > the mmap'ed memory range...
> > >
> > Did anything ever happen with this? I seem to be experiencing similar
> > issues while cross-compiling for ARM on x86-64. All tested kernels
> > (v2.6.35 to master) fail with,
Too k a quick look.
Does the following patch fix it?
if m == p then we will stay in the while look looking for a space.
I did not audit all of the code - there may be other issues..
Sam
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index ea26b23..f472ada 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -318,7 +318,7 @@ static void parse_dep_file(void *map, size_t len)
while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
m++;
p = m;
- while (p < end && *p != ' ') p++;
+ while (p <= end && *p != ' ') p++;
if (p == end) {
do p--; while (!isalnum(*p));
p++;
On Sat, 6 Nov 2010 17:24:26 +0100, Sam Ravnborg <[email protected]> wrote:
> Took a quick look.
> Does the following patch fix it?
>
> if m == p then we will stay in the while look looking for a space.
> I did not audit all of the code - there may be other issues..
>
Looks like something very strange is happening here. Debugging patch attached.
On Sat, 6 Nov 2010 17:24:26 +0100, Sam Ravnborg <[email protected]> wrote:
> Took a quick look.
> Does the following patch fix it?
>
> if m == p then we will stay in the while look looking for a space.
> I did not audit all of the code - there may be other issues..
>
P.S. Sorry for the noise
Looks like something very odd is happening here. Seems like stat is
giving us the wrong size. As seen below, ls reports the file size to be
5247 whereas st.stat indicates a size substantially larger than
that. Output from make with attached patch applied:
$ ls -l scripts/basic/.fixdep.d
-rw-r--r-- 1 bgamari bgamari 5247 2010-11-07 11:35 scripts/basic/.fixdep.d
$ make V=1
In file included from /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdlib.h:903,
from scripts/basic/fixdep.c:112:
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdlib.h:65: warning: no previous prototype for ‘ptsname_r’
file=scripts/basic/.fixdep.d
st.size=2ad5f6cecb36
map=0x2ad5f6fe4000, len=2ad5f6cecb36
m=0x2ad5f6fe4000, end=0x55abedcd0b36
eh?=2ad5f6fe4000
map=0x2ad5f6fe4000, len=2ad5f6cecb36, end=0x55abedcd0b36
m=0x2ad5f6fe4009
A: p=0x2ad5f6fe400a, end=0x55abedcd0b36, str=scripts/basic/fixdep.c \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/types.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/features.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/sys/cdefs.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/wordsize.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/gnu/stubs.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/types.h \
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/stddef.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/typesizes.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/time.h \
[SNIP]
B: p=0x2ad5f6fe53e1, end=0x55abedcd0b36
C: p=0x2ad5f6fe53e1, s=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/asm/sockios.h
m=0x2ad5f6fe53e2
m=0x2ad5f6fe53e3
m=0x2ad5f6fe53e4
A: p=0x2ad5f6fe53e5, end=0x55abedcd0b36, str=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/socket2.h \
/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/in.h
B: p=0x2ad5f6fe5432, end=0x55abedcd0b36
C: p=0x2ad5f6fe5432, s=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/socket2.h
m=0x2ad5f6fe5433
m=0x2ad5f6fe5434
m=0x2ad5f6fe5435
A: p=0x2ad5f6fe5436, end=0x55abedcd0b36, str=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/in.h
/bin/sh: line 1: 8456 Bus error scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep 'gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c ' > scripts/basic/.fixdep.tmp
make[2]: *** [scripts/basic/fixdep] Error 135
make[1]: *** [scripts_basic] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
---
scripts/basic/fixdep.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index ea26b23..f1b58d6 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -303,6 +303,9 @@ static void parse_dep_file(void *map, size_t len)
char *p;
char s[PATH_MAX];
+ fprintf(stderr, "map=%p, len=%zx\n", map, len);
+ fprintf(stderr, "m=%p, end=%p\n", m, end);
+ fprintf(stderr, "eh?=%zx\n", (size_t)end - (size_t)len);
p = strchr(m, ':');
if (!p) {
fprintf(stderr, "fixdep: parse error\n");
@@ -314,16 +317,23 @@ static void parse_dep_file(void *map, size_t len)
clear_config();
+ fprintf(stderr, "map=%p, len=%zx, end=%p\n", map, len, end);
while (m < end) {
- while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
+ while (m <= end && (*m == ' ' || *m == '\\' || *m == '\n')) {
+ fprintf(stderr, "m=%p\n", m);
m++;
+ }
p = m;
- while (p < end && *p != ' ') p++;
+ fprintf(stderr, "A: p=%p, end=%p, str=%s\n", p, end, p);
+ while (p <= end && *p != ' ') p++;
+ fprintf(stderr, "B: p=%p, end=%p\n", p, end);
if (p == end) {
do p--; while (!isalnum(*p));
+ fprintf(stderr, "c%c ", *p);
p++;
}
memcpy(s, m, p-m); s[p-m] = 0;
+ fprintf(stderr, "C: p=%p, s=%s\n", p, s);
if (strrcmp(s, "include/generated/autoconf.h") &&
strrcmp(s, "arch/um/include/uml-config.h") &&
strrcmp(s, ".ver")) {
@@ -342,6 +352,7 @@ static void print_deps(void)
int fd;
void *map;
+ fprintf(stderr, "file=%s\n", depfile);
fd = open(depfile, O_RDONLY);
if (fd < 0) {
fprintf(stderr, "fixdep: ");
@@ -354,6 +365,7 @@ static void print_deps(void)
close(fd);
return;
}
+ fprintf(stderr, "st.size=%zx\n", st.st_size);
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
if ((long) map == -1) {
perror("fixdep: mmap");
--
1.7.0.4
On Sun, Nov 07, 2010 at 11:44:13AM -0500, Ben Gamari wrote:
> On Sat, 6 Nov 2010 17:24:26 +0100, Sam Ravnborg <[email protected]> wrote:
> > Took a quick look.
> > Does the following patch fix it?
> >
> > if m == p then we will stay in the while look looking for a space.
> > I did not audit all of the code - there may be other issues..
> >
> P.S. Sorry for the noise
>
> Looks like something very odd is happening here. Seems like stat is
> giving us the wrong size. As seen below, ls reports the file size to be
> 5247 whereas st.stat indicates a size substantially larger than
> that. Output from make with attached patch applied:
>
> $ ls -l scripts/basic/.fixdep.d
> -rw-r--r-- 1 bgamari bgamari 5247 2010-11-07 11:35 scripts/basic/.fixdep.d
> $ make V=1
> In file included from /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/stdlib.h:903,
> from scripts/basic/fixdep.c:112:
> /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/bits/stdlib.h:65: warning: no previous prototype for ‘ptsname_r’
> file=scripts/basic/.fixdep.d
> st.size=2ad5f6cecb36
Interesting and valueable information!
Looks like fstat() failed for some odd reason
Could you try to check the return value of fstat().
If it retruns less than 0 then print out errno (preferable using perror()).
Sam
On Sun, 7 Nov 2010 18:07:00 +0100, Sam Ravnborg <[email protected]> wrote:
> Interesting and valueable information!
>
> Looks like fstat() failed for some odd reason
> Could you try to check the return value of fstat().
>
fixdep: fstat failed: Invalid argument
Interesting indeed. According to my manpage fstat doesn't even return
EINVAL.
- Ben
Hi Ben.
[Context to new readers: Ben experience that fixdep (part of kbuild)
exists with an error during kernel compilations.
This is now tracked down to fstat() returning EINVAL.
Due to missing error checks in fixdep.c this has been a long journey
to reach this far. ]
I looked briefly at the fstat implmnetation in the kernel and
this did not give me any hints.
I therefore changed to subject to attrack attention of more readers.
Can you supply us with a bit more information about your system:
- filesystem (as fstat seems to reach filesystem specific code)
- glibc version
- box (architecture + 32 or 64 bit kernel)
- do you see other things misbehave or is this only a kernel build thing
If you have provided this info in the past I have missed it.
Sam
[Kept the below for new readers]
On Sun, Nov 07, 2010 at 01:09:30PM -0500, Ben Gamari wrote:
> On Sun, 7 Nov 2010 18:07:00 +0100, Sam Ravnborg <[email protected]> wrote:
> > Interesting and valueable information!
> >
> > Looks like fstat() failed for some odd reason
> > Could you try to check the return value of fstat().
> >
> fixdep: fstat failed: Invalid argument
>
> Interesting indeed. According to my manpage fstat doesn't even return
> EINVAL.
>
> - Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Sun, 7 Nov 2010 23:30:56 +0100, Sam Ravnborg <[email protected]> wrote:
> I looked briefly at the fstat implmnetation in the kernel and
> this did not give me any hints.
> I therefore changed to subject to attrack attention of more readers.
>
Thanks!
> Can you supply us with a bit more information about your system:
> - filesystem (as fstat seems to reach filesystem specific code)
> - glibc version
> - box (architecture + 32 or 64 bit kernel)
> - do you see other things misbehave or is this only a kernel build thing
>
> If you have provided this info in the past I have missed it.
>
The kernel tree resides on an ext4 partition. The machine has two Xeon
E5520 processors and runs 64-bit Ubuntu 10.04 which uses eglibc 2.11.1.
Note that the kernel is being cross-compiled for ARM under an
OpenEmbedded toolchain (have tried both gcc 4.4.4 and 4.5). This is the
only strange behavior that I know of.
Cheers,
- Ben
On Sun, Nov 07, 2010 at 06:07:08PM -0500, Ben Gamari wrote:
>On Sun, 7 Nov 2010 23:30:56 +0100, Sam Ravnborg <[email protected]> wrote:
>> I looked briefly at the fstat implmnetation in the kernel and
>> this did not give me any hints.
>> I therefore changed to subject to attrack attention of more readers.
>>
>Thanks!
>
>> Can you supply us with a bit more information about your system:
>> - filesystem (as fstat seems to reach filesystem specific code)
>> - glibc version
>> - box (architecture + 32 or 64 bit kernel)
>> - do you see other things misbehave or is this only a kernel build thing
>>
>> If you have provided this info in the past I have missed it.
>>
>The kernel tree resides on an ext4 partition. The machine has two Xeon
>E5520 processors and runs 64-bit Ubuntu 10.04 which uses eglibc 2.11.1.
>Note that the kernel is being cross-compiled for ARM under an
>OpenEmbedded toolchain (have tried both gcc 4.4.4 and 4.5). This is the
>only strange behavior that I know of.
>
But fixdep should be compiled by the host compiler...
So, does this error also occur when you do non-cross compiling on the
same partition?
Thanks for your testing!
On Mon, 8 Nov 2010 18:20:02 +0800, Américo Wang <[email protected]> wrote:
> But fixdep should be compiled by the host compiler...
>
Very good point.
> So, does this error also occur when you do non-cross compiling on the
> same partition?
>
Hmm, it seems to be fine when not cross-compiling. Interesting.
> Thanks for your testing!
No worries!
- Ben
On Mon, Nov 08, 2010 at 07:38:13AM -0500, Ben Gamari wrote:
> On Mon, 8 Nov 2010 18:20:02 +0800, Am?rico Wang <[email protected]> wrote:
> > But fixdep should be compiled by the host compiler...
> >
> Very good point.
>
> > So, does this error also occur when you do non-cross compiling on the
> > same partition?
> >
> Hmm, it seems to be fine when not cross-compiling. Interesting.
>
> > Thanks for your testing!
>
> No worries!
Hi Ben - interesting information.
Do you see that this bug trigger for the same file always?
You could try to print out the filename if fstat fails.
If this happens while accessing the same file then try to
check if this file has any special permissions / security settings.
[I looked a bit on the kernel side of fstat() and it looked
like a security check could result in EINVAL].
Again if it is always the same file try if you can read it
using less/vi.
>From your previous posting it looks like you have some special setting
that impact your choice of HOST gcc.
Do you define HOSTCC somewhere?
Sam
On Mon, 8 Nov 2010 19:22:09 +0100, Sam Ravnborg <[email protected]> wrote:
> Hi Ben - interesting information.
>
> Do you see that this bug trigger for the same file always?
> You could try to print out the filename if fstat fails.
>
fstat appears to be failing for every file (the file= line is printed
right before the fstat; there seems to be a corresponding error for
every file= so I'm inferring that it must always fail):
$ make
HOSTCC scripts/basic/fixdep
file=scripts/basic/.fixdep.d
fixdep: fstat failed: Invalid argument
HOSTCC scripts/basic/docproc
file=scripts/basic/.docproc.d
fixdep: fstat failed: Invalid argument
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
file=scripts/kconfig/.conf.o.d
fixdep: fstat failed: Invalid argument
file=scripts/kconfig/.kxgettext.o.d
fixdep: fstat failed: Invalid argument
HOSTCC scripts/kconfig/zconf.tab.o
file=scripts/kconfig/.zconf.tab.o.d
fixdep: fstat failed: Invalid argument
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
***
*** Configuration file ".config" not found!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
> If this happens while accessing the same file then try to
> check if this file has any special permissions / security settings.
> [I looked a bit on the kernel side of fstat() and it looked
> like a security check could result in EINVAL].
>
> Again if it is always the same file try if you can read it
> using less/vi.
>
It actually seems as if the problem might be that none of these files
actually exist:
$ find scripts -iname .*.d
$
How are .d files supposed to be generated?
> From your previous posting it looks like you have some special setting
> that impact your choice of HOST gcc.
> Do you define HOSTCC somewhere?
>
I don't think I do define HOSTCC anywhere. My cross compilation
environment is as follows,
source /usr/local/angstrom/arm/environment-setup
export ARCH=arm
export CROSS_COMPILE=arm-angstrom-linux-gnueabi-
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++
OE_ENV_ROOT=/home/bgamari/OE/angstrom-dev
SYSROOT=$OE_ENV_ROOT/sysroots/armv7a-angstrom-linux-gnueabi
export LD_LIBRARY_PATH=$SYSROOT/lib:$SYSROOT/usr/lib
export CFLAGS=-I$OE_ROOT/lib/gcc/arm-angstrom-linux-gnueabi/4.3.1/include
> >
> fstat appears to be failing for every file (the file= line is printed
> right before the fstat; there seems to be a corresponding error for
> every file= so I'm inferring that it must always fail):
>
> $ make
> HOSTCC scripts/basic/fixdep
> file=scripts/basic/.fixdep.d
> fixdep: fstat failed: Invalid argument
But open succedd - because we see no output from that one.
> It actually seems as if the problem might be that none of these files
> actually exist:
>
> $ find scripts -iname .*.d
> $
>
> How are .d files supposed to be generated?
They are generated by kbuild.
See scripts/Kbuild.include:
# Execute the command and also postprocess generated .d dependencies file.
if_changed_dep = $(if $(strip $(any-prereq) $(arg-check) ), \
@set -e; \
$(echo-cmd) $(cmd_$(1)); \
scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
==> rm -f $(depfile); \
mv -f $(dot-target).tmp $(dot-target).cmd)
If you delete the line marked "==>" then you should have .d files are a build.
> > From your previous posting it looks like you have some special setting
> > that impact your choice of HOST gcc.
> > Do you define HOSTCC somewhere?
> >
> I don't think I do define HOSTCC anywhere. My cross compilation
> environment is as follows,
>
> source /usr/local/angstrom/arm/environment-setup
> export ARCH=arm
> export CROSS_COMPILE=arm-angstrom-linux-gnueabi-
So far it looks OK.
> export CC=${CROSS_COMPILE}gcc
> export CXX=${CROSS_COMPILE}g++
This part is wrong. The kernel will do this for you.
It should not cause any harm...
>
> OE_ENV_ROOT=/home/bgamari/OE/angstrom-dev
> SYSROOT=$OE_ENV_ROOT/sysroots/armv7a-angstrom-linux-gnueabi
> export LD_LIBRARY_PATH=$SYSROOT/lib:$SYSROOT/usr/lib
> export CFLAGS=-I$OE_ROOT/lib/gcc/arm-angstrom-linux-gnueabi/4.3.1/include
These looks unrelated.
Sam
On Mon, 8 Nov 2010 20:05:01 +0100, Sam Ravnborg <[email protected]> wrote:
> >
> > $ make
> > HOSTCC scripts/basic/fixdep
> > file=scripts/basic/.fixdep.d
> > fixdep: fstat failed: Invalid argument
>
> But open succedd - because we see no output from that one.
>
Yes, this is true.
> > How are .d files supposed to be generated?
>
> They are generated by kbuild.
> See scripts/Kbuild.include:
>
> If you delete the line marked "==>" then you should have .d files are a build.
>
True.
> > export CC=${CROSS_COMPILE}gcc
> > export CXX=${CROSS_COMPILE}g++
> This part is wrong. The kernel will do this for you.
> It should not cause any harm...
>
Yeah, this is for other applications.
Any idea of what could be happening?
- Ben
On Mon, Nov 08, 2010 at 03:17:16PM -0500, Ben Gamari wrote:
>On Mon, 8 Nov 2010 20:05:01 +0100, Sam Ravnborg <[email protected]> wrote:
>> >
>> > $ make
>> > HOSTCC scripts/basic/fixdep
>> > file=scripts/basic/.fixdep.d
>> > fixdep: fstat failed: Invalid argument
>>
>> But open succedd - because we see no output from that one.
>>
>Yes, this is true.
>
>> > How are .d files supposed to be generated?
>>
>> They are generated by kbuild.
>> See scripts/Kbuild.include:
>>
>> If you delete the line marked "==>" then you should have .d files are a build.
>>
>True.
>
>> > export CC=${CROSS_COMPILE}gcc
>> > export CXX=${CROSS_COMPILE}g++
>> This part is wrong. The kernel will do this for you.
>> It should not cause any harm...
>>
>Yeah, this is for other applications.
>
>Any idea of what could be happening?
>
No idea why this only happens to those .*.d files.
A blind guess would be commit 365b1818. :-/