This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
'make check' failure
- To: libc-alpha@cygnus.com
- Subject: 'make check' failure
- From: Junichi Saito <j.saito@wanadoo.fr>
- Date: Mon, 15 Mar 1999 09:36:03 +0100 (CET)
>Submitter-Id: net
>Originator:
>Organization:
>Confidential: no
>Synopsis: make check fails and 'sh' dumps core
>Severity: serious
>Priority: high
>Category: libc
>Class: sw-bug
>Release: libc-2.1.1
>Environment:
Host type: i586-pc-linux-gnu
System: Linux saito 2.2.2 #1 Sun Feb 28 10:39:01 CET 1999 i586 unknown
Architecture: i586
Addons: crypt linuxthreads nss-v1
Build CC: gcc
Compiler version: pgcc-2.91.60 19981201 (egcs-1.1.1 release)
Kernel headers: 2.2.2
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: no
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
'make check' fails with:
/bin/sh -e tst-rpmatch.sh /usr/local/src/build/
make[2]: *** [do-tst-rpmatch] Segmentation fault (core dumped)
make[2]: Leaving directory `/usr/local/src/glibc-2.1.1pre1/localedata'
I have a staticaly linked bash 2.03 (comiled against glibc 2.1)
installed as 'sh'.
Run by bash 1.14.7 (linked against libc5), 'make check' runs
without errors.
The backtrace follows:
Core was generated by `/bin/sh -e tst-rpmatch.sh /usr/local/src/build/'.
Program terminated with signal 11, Segmentation fault.
#0 dispose_word (w=0x10fcc30) at dispose_cmd.c:202
202 FREE (w->word);
(gdb) bt
#0 dispose_word (w=0x10fcc30) at dispose_cmd.c:202
#1 0x806412b in expand_word_internal (word=0x80fc9a8, quoted=0, isexp=0,
contains_dollar_at=0xbfffefa4, expanded_something=0xbfffefa8) at subst.c:5039
#2 0x8064d08 in shell_expand_word_list (tlist=0x80fc818, eflags=31) at
subst.c:5797
#3 0x8064eca in expand_word_list_internal (list=0x80fbfd8, eflags=31) at
subst.c:5911
#4 0x8064983 in expand_words (list=0x80fbfd8) at subst.c:5581
#5 0x8054855 in execute_simple_command (simple_command=0x80fbfc0, pipe_in=-1,
pipe_out=-1, async=0, fds_to_close=0x80fc8a8) at execute_cmd.c:2362
#6 0x8052586 in execute_command_internal (command=0x80fbfa8, asynchronous=0,
pipe_in=-1, pipe_out=-1, fds_to_close=0x80fc8a8) at execute_cmd.c:702
#7 0x8051e7b in execute_command (command=0x80fbfa8) at execute_cmd.c:284
#8 0x805423a in execute_if_command (if_command=0x80fc350) at execute_cmd.c:2041
#9 0x8052709 in execute_command_internal (command=0x80fc368, asynchronous=0,
pipe_in=-1, pipe_out=-1, fds_to_close=0x80fbf00) at execute_cmd.c:799
#10 0x8051e7b in execute_command (command=0x80fc368) at execute_cmd.c:284
#11 0x80541db in execute_while_or_until (while_command=0x80fc380, type=0) at
execute_cmd.c:2010
#12 0x805415a in execute_while_command (while_command=0x80fc380) at
execute_cmd.c:1969
#13 0x80526c9 in execute_command_internal (command=0x80fc390, asynchronous=0,
pipe_in=-1, pipe_out=-1, fds_to_close=0x80fc3b8) at execute_cmd.c:787
#14 0x8051e7b in execute_command (command=0x80fc390) at execute_cmd.c:284
#15 0x804a00b in reader_loop () at eval.c:139
#16 0x80487b4 in main (argc=4, argv=0xbffff224, env=0xbffff238) at shell.c:633
#17 0x8090ede in __libc_start_main (main=0x8048190 <main>, argc=4,
argv=0xbffff224, init=0x80480b4 <_init>, fini=0x80cfd4c <_fini>, rtld_fini=0,
stack_end=0xbffff21c) at ../sysdeps/generic/libc-start.c:78
This may be a problem in bash, not in glibc. I already sent a mail to
bug-bash@gnu.org also.
junichi