Bootstrapping gcc leads to this error message during stage2: stage1/xgcc -Bstage1/ -B/gnu/tools/i486-pc-freebsd-gnu/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I/gnu/build/gcc-3.1/gcc -I/gnu/build/gcc-3.1/gcc/. -I/gnu/build/gcc-3.1/gcc/config -I/gnu/build/gcc-3.1/gcc/../include /gnu/build/gcc-3.1/gcc/lists.c -o lists.o In file included from /gnu/build/gcc-3.1/gcc/system.h:157, from /gnu/build/gcc-3.1/gcc/lists.c:23: /gnu/tools/i486-pc-freebsd-gnu/include/unistd.h:500:27: bits/confname.h: No such file or directory The include file bits/confname.h exists under one of the -I directories. The problem is that find_or_create_entry() returns a splay_tree_node containing 'struct include_file' with err_no == ENOMEM, which then causes open_file() to behave as if the file did not exist. Now where does this ENOMEM come from? In find_or_create_entry(), right after the _cpp_simplify_pathname call, errno is 0, because the file exists. Then inside xcnew() malloc() is called, which clobbers ENOMEM. (At this point one of the malloc() strategies fails, brk() returns ENOMEM, and malloc() falls back on mmap().) The assumption that errno is not clobbered by successful calls to malloc() is invalid. Release: 3.1 Environment: System: FreeBSD linuix.math.u-bordeaux.fr 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 root@monster.cdrom.com:/usr/src/sys/compile/GENERIC i386 host: i486-pc-freebsd-gnu build: i486-pc-freebsd-gnu target: i486-pc-freebsd-gnu configured with: /gnu/build/gcc-3.1/configure --enable-shared --disable-nls --prefix=/gnu/usr --with-local-prefix=/gnu/usr/local --with-as=/gnu/usr/bin/as --with-gnu-as --with-ld=/gnu/usr/bin/ld --with-gnu-ld --enable-languages=c --enable-threads i486-pc-freebsd-gnu How-To-Repeat: On a FreeBSD system with glibc chroot environment, configure gcc as described above and run "make bootstrap".
Fix: Apply this patch. 2002-07-14 Bruno Haible <bruno@clisp.org> * cppfiles.c (find_or_create_entry): Fetch errno immediately after _cpp_simplify_pathname returns. *** gcc-3.1/gcc/cppfiles.c.bak Fri Jan 18 14:40:28 2002 --- gcc-3.1/gcc/cppfiles.c Sun Jul 14 01:16:19 2002 *************** *** 193,203 **** --- 193,205 ---- cpp_reader *pfile; const char *fname; { + int saved_errno; splay_tree_node node; struct include_file *file; char *name = xstrdup (fname); _cpp_simplify_pathname (name); + saved_errno = errno; node = splay_tree_lookup (pfile->all_include_files, (splay_tree_key) name); if (node) free (name); *************** *** 205,211 **** { file = xcnew (struct include_file); file->name = name; ! file->err_no = errno; node = splay_tree_insert (pfile->all_include_files, (splay_tree_key) file->name, (splay_tree_value) file); --- 207,213 ---- { file = xcnew (struct include_file); file->name = name; ! file->err_no = saved_errno; node = splay_tree_insert (pfile->all_include_files, (splay_tree_key) file->name, (splay_tree_value) file);
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, bruno@clisp.org Cc: Subject: Re: bootstrap/7312: bootstrap failure due to invalid use of errno Date: Wed, 7 May 2003 21:24:02 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=7312 Hello, could the submitter of this bug please confirm whether this problem still occurs with a current version of gcc (ie 3.2.3). Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question.
From: Bruno Haible <bruno@clisp.org> To: Dara Hazeghi <dhazeghi@yahoo.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: bootstrap/7312: bootstrap failure due to invalid use of errno Date: Thu, 8 May 2003 12:43:58 +0200 (CEST) Dara Hazeghi writes: > could the submitter of this bug please confirm whether this problem > still occurs with a current version of gcc (ie 3.2.3). The bug is still there, as you can see from a look at the gcc-3.2.3 source code: _cpp_simplify_pathname (name); node = splay_tree_lookup (pfile->all_include_files, (splay_tree_key) name); if (node) free (name); else { file = xcnew (struct include_file); file->name = name; file->err_no = errno; xcnew calls malloc and therefore can clobber errno. Bruno
From: Zack Weinberg <zack@codesourcery.com> To: gcc-bugs@gcc.gnu.org, bruno@clisp.org Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: preprocessor/7312: bootstrap failure due to invalid use of errno Date: Fri, 09 May 2003 08:26:33 -0700 http://gcc.gnu.org/PR?7312 I apologize for not noticing this bug earlier. It's indeed a bug, but I don't think your suggested fix is right. At that point in the code, nothing has been done to give errno a meaningful value, so ->err_no should just be cleared to 0. I will apply this patch later today, along with some other changes, if bootstrap succeeds. zw PR preprocessor/7312 * cppfiles.c (find_or_create_entry): Initialize file->err_no to 0, not errno. =================================================================== Index: cppfiles.c --- cppfiles.c 21 Apr 2003 19:21:53 -0000 1.168 +++ cppfiles.c 9 May 2003 15:24:48 -0000 @@ -184,7 +184,7 @@ find_or_create_entry (pfile, fname) file = xcnew (struct include_file); file->name = name; file->header_name = name; - file->err_no = errno; + file->err_no = 0; node = splay_tree_insert (pfile->all_include_files, (splay_tree_key) file->name, (splay_tree_value) file);
Responsible-Changed-From-To: unassigned->neil Responsible-Changed-Why: Neil, this file seems to be your pet. There's a patch in this PR that seems like relatively low risk (and is small). Would you mind taking a look at it? Thanks W.
State-Changed-From-To: feedback->open State-Changed-Why: .
From: Zack Weinberg <zack@codesourcery.com> To: Neil Booth <neil@daikokuya.co.uk> Cc: Bruno Haible <bruno@clisp.org>, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: preprocessor/7312: bootstrap failure due to invalid use of errno Date: Fri, 09 May 2003 15:24:56 -0700 Neil Booth <neil@daikokuya.co.uk> writes: > Bruno Haible wrote:- > >> Zack Weinberg writes: >> > At that point in the code, >> > nothing has been done to give errno a meaningful value, so ->err_no >> > should just be cleared to 0. >> >> Well, I thought (and still think) that 'errno' here means the error >> status from cpp_simplify_path. See the comments at the head of the >> function cpp_simplify_path. >> >> I also think that validate_pch() should not ignore this error status. > > I agree that Bruno's original patch is the right one. Would you please check it in, then? I'm in the middle of a messy unrelated project, and not in a position to test stuff. zw
Responsible-Changed-From-To: neil->zack Responsible-Changed-Why: Working on a fix.
From: Bruno Haible <bruno@clisp.org> To: Zack Weinberg <zack@codesourcery.com> Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: preprocessor/7312: bootstrap failure due to invalid use of errno Date: Fri, 9 May 2003 18:04:09 +0200 (CEST) Zack Weinberg writes: > At that point in the code, > nothing has been done to give errno a meaningful value, so ->err_no > should just be cleared to 0. Well, I thought (and still think) that 'errno' here means the error status from cpp_simplify_path. See the comments at the head of the function cpp_simplify_path. I also think that validate_pch() should not ignore this error status. Bruno
From: Neil Booth <neil@daikokuya.co.uk> To: Bruno Haible <bruno@clisp.org> Cc: Zack Weinberg <zack@codesourcery.com>, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: preprocessor/7312: bootstrap failure due to invalid use of errno Date: Fri, 9 May 2003 23:09:03 +0100 Bruno Haible wrote:- > Zack Weinberg writes: > > At that point in the code, > > nothing has been done to give errno a meaningful value, so ->err_no > > should just be cleared to 0. > > Well, I thought (and still think) that 'errno' here means the error > status from cpp_simplify_path. See the comments at the head of the > function cpp_simplify_path. > > I also think that validate_pch() should not ignore this error status. I agree that Bruno's original patch is the right one. Neil.
State-Changed-From-To: open->closed State-Changed-Why: Fixed in 3.4. I'll update 3.3 when it's open.