Bug#165603: man-db: me too
On Tue, Oct 29, 2002 at 07:21:01AM -0800, Jeff Bailey wrote:
On Tue, Oct 29, 2002 at 02:50:29PM +, Colin Watson wrote:
Thanks a lot! Not to rush you, but any luck so far, or can I help? I've
had five duplicates so far, so I have plenty of motivation ...
Sorry, I haven't looked at it yet. I just finished my weekend from hell
(I had 2 speaking engagements, plus another conference, but had Marcus
Brinkmann visiting from Germany). It's on my todo list for this week,
though.
If only I could put off that dayjob thing... =)
I know the feeling. :-)
I think I've found a patch from CVS that clears up this segfault. First
off, a gdb transcript to explain why I think this patch is relevant:
(gdb) run foo
Starting program: /home/cjwatson/src/debian/man-db/man-db-2.4.0/src/apropos foo
foo (1) - No manpage for this program, utility or function.
Program received signal SIGSEGV, Segmentation fault.
0x400c0968 in re_string_context_at (input=0x80bdfe8, idx=25, eflags=0,
newline_anchor=0) at regex_internal.c:540
warning: Source file is more recent than executable.
540 c = re_string_byte_at (input, idx);
(gdb) bt
#0 0x400c0968 in re_string_context_at (input=0x80bdfe8, idx=25, eflags=0,
newline_anchor=0) at regex_internal.c:540
#1 0x400c0749 in re_string_reconstruct (pstr=0xb700, idx=26, eflags=0, newline=0)
at regex_internal.c:439
#2 0x400bba7e in re_search_internal (preg=0x804f260, string=0x80bdfa4 memory
management-related functions for use with TIFF files, length=59, start=0, range=70,
stop=134995944, nmatch=0, pmatch=0x0, eflags=0) at regexec.c:665
#3 0x400bb191 in __regexec (preg=0x804f260, string=0x19 Address 0x19 out of bounds,
nmatch=0, pmatch=0x0, eflags=0) at regexec.c:210
#4 0x08049901 in parse_whatis (page=0xbab0 foo, lowpage=0x8050e00 foo,
whatis=0x80bdfa4 memory management-related functions for use with TIFF files)
at whatis.c:413
#5 0x08049a8e in apropos (page=0xbab0 foo, lowpage=0x8050e00 foo) at
whatis.c:488
#6 0x08049d94 in search (page=0xbab0 foo) at whatis.c:563
#7 0x0804a103 in main (argc=2, argv=0xb974) at whatis.c:711
(gdb) up
#1 0x400c0749 in re_string_reconstruct (pstr=0xb700, idx=26, eflags=0, newline=0)
at regex_internal.c:439
439 pstr-tip_context = re_string_context_at (pstr, offset - 1, eflags,
(gdb) list
434 offset = idx;
435 }
436
437 if (offset != 0)
438 {
439 pstr-tip_context = re_string_context_at (pstr, offset - 1, eflags,
440 newline);
441 /* Are the characters which are already checked remain? */
442 if (offset pstr-valid_len)
443 {
(gdb) p offset
$1 = 26
(gdb) p pstr-valid_len
$2 = 0
(gdb) q
Here's the patch. I've backported it such that it applies against glibc
2.1.3-4, since there were some whitespace changes in between. If you
want to take those too for simplicity, I can put together a combined
patch. The crucial bits are chunks 4 and 5 of regex_internal.c; I think
the rest are dependent.
Note that the test suite is still running here.
-
PatchSet 46089
Date: 2002/11/13 04:00:08
Author: roland
Log:
2002-11-11 Isamu Hasegawa [EMAIL PROTECTED]
* posix/regex_internal.c (re_string_skip_chars): Also return the last
wide character.
(re_string_reconstruct): Calculate the context by itself when the
offset points out of the valid range.
(re_string_context_at): Use wide character when MB_CUR_MAX 1.
* posix/regex_internal.h (WIDE_NEWLINE_CHAR): New macro.
(IS_WIDE_WORD_CHAR): New macro.
(IS_WIDE_NEWLINE): New macro.
Members:
posix/regex_internal.c:1.14-1.15
posix/regex_internal.h:1.17-1.18
Index: posix/regex_internal.c
===
RCS file: /cvs/glibc/libc/posix/regex_internal.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -p -u -u -r1.14 -r1.15
--- posix/regex_internal.c 6 Nov 2002 19:24:20 - 1.14
+++ posix/regex_internal.c 13 Nov 2002 04:00:08 - 1.15
@@ -66,7 +66,8 @@ static void re_string_construct_common (
re_string_t *pstr,
RE_TRANSLATE_TYPE trans, int icase);
#ifdef RE_ENABLE_I18N
-static int re_string_skip_chars (re_string_t *pstr, int new_raw_idx);
+static int re_string_skip_chars (re_string_t *pstr, int new_raw_idx,
+wint_t *last_wc);
#endif /* RE_ENABLE_I18N */
static re_dfastate_t *create_newstate_common (re_dfa_t *dfa,
const re_node_set *nodes,
@@ -333,21 +334,24 @@ build_wcs_upper_buffer (pstr)
Return the index. */
static int
-re_string_skip_chars (pstr, new_raw_idx)
+re_string_skip_chars (pstr, new_raw_idx, last_wc)
re_string_t *pstr;
int new_raw_idx;
+ wint_t
Bug#165603: man-db: me too
On Wed, Nov 20, 2002 at 02:12:41AM +, Colin Watson wrote: Here's the patch. I've backported it such that it applies against glibc 2.1.3-4, since there were some whitespace changes in between. If you want to take those too for simplicity, I can put together a combined patch. The crucial bits are chunks 4 and 5 of regex_internal.c; I think the rest are dependent. Note that the test suite is still running here. For the record, the tests pass here, and apropos seems much healthier: I can't get it to segfault with the new libc.so LD_PRELOADed, and valgrind is happy. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165603: man-db: me too
On Tue, Oct 29, 2002 at 07:21:01AM -0800, Jeff Bailey wrote:
On Tue, Oct 29, 2002 at 02:50:29PM +, Colin Watson wrote:
Thanks a lot! Not to rush you, but any luck so far, or can I help? I've
had five duplicates so far, so I have plenty of motivation ...
Sorry, I haven't looked at it yet. I just finished my weekend from hell
(I had 2 speaking engagements, plus another conference, but had Marcus
Brinkmann visiting from Germany). It's on my todo list for this week,
though.
If only I could put off that dayjob thing... =)
I know the feeling. :-)
I think I've found a patch from CVS that clears up this segfault. First
off, a gdb transcript to explain why I think this patch is relevant:
(gdb) run foo
Starting program: /home/cjwatson/src/debian/man-db/man-db-2.4.0/src/apropos foo
foo (1) - No manpage for this program, utility or function.
Program received signal SIGSEGV, Segmentation fault.
0x400c0968 in re_string_context_at (input=0x80bdfe8, idx=25, eflags=0,
newline_anchor=0) at regex_internal.c:540
warning: Source file is more recent than executable.
540 c = re_string_byte_at (input, idx);
(gdb) bt
#0 0x400c0968 in re_string_context_at (input=0x80bdfe8, idx=25, eflags=0,
newline_anchor=0) at regex_internal.c:540
#1 0x400c0749 in re_string_reconstruct (pstr=0xb700, idx=26, eflags=0,
newline=0) at regex_internal.c:439
#2 0x400bba7e in re_search_internal (preg=0x804f260, string=0x80bdfa4 memory
management-related functions for use with TIFF files, length=59, start=0,
range=70,
stop=134995944, nmatch=0, pmatch=0x0, eflags=0) at regexec.c:665
#3 0x400bb191 in __regexec (preg=0x804f260, string=0x19 Address 0x19 out of
bounds, nmatch=0, pmatch=0x0, eflags=0) at regexec.c:210
#4 0x08049901 in parse_whatis (page=0xbab0 foo, lowpage=0x8050e00 foo,
whatis=0x80bdfa4 memory management-related functions for use with TIFF files)
at whatis.c:413
#5 0x08049a8e in apropos (page=0xbab0 foo, lowpage=0x8050e00 foo) at
whatis.c:488
#6 0x08049d94 in search (page=0xbab0 foo) at whatis.c:563
#7 0x0804a103 in main (argc=2, argv=0xb974) at whatis.c:711
(gdb) up
#1 0x400c0749 in re_string_reconstruct (pstr=0xb700, idx=26, eflags=0,
newline=0) at regex_internal.c:439
439 pstr-tip_context = re_string_context_at (pstr, offset - 1,
eflags,
(gdb) list
434 offset = idx;
435 }
436
437 if (offset != 0)
438 {
439 pstr-tip_context = re_string_context_at (pstr, offset - 1,
eflags,
440 newline);
441 /* Are the characters which are already checked remain? */
442 if (offset pstr-valid_len)
443 {
(gdb) p offset
$1 = 26
(gdb) p pstr-valid_len
$2 = 0
(gdb) q
Here's the patch. I've backported it such that it applies against glibc
2.1.3-4, since there were some whitespace changes in between. If you
want to take those too for simplicity, I can put together a combined
patch. The crucial bits are chunks 4 and 5 of regex_internal.c; I think
the rest are dependent.
Note that the test suite is still running here.
-
PatchSet 46089
Date: 2002/11/13 04:00:08
Author: roland
Log:
2002-11-11 Isamu Hasegawa [EMAIL PROTECTED]
* posix/regex_internal.c (re_string_skip_chars): Also return the last
wide character.
(re_string_reconstruct): Calculate the context by itself when the
offset points out of the valid range.
(re_string_context_at): Use wide character when MB_CUR_MAX 1.
* posix/regex_internal.h (WIDE_NEWLINE_CHAR): New macro.
(IS_WIDE_WORD_CHAR): New macro.
(IS_WIDE_NEWLINE): New macro.
Members:
posix/regex_internal.c:1.14-1.15
posix/regex_internal.h:1.17-1.18
Index: posix/regex_internal.c
===
RCS file: /cvs/glibc/libc/posix/regex_internal.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -p -u -u -r1.14 -r1.15
--- posix/regex_internal.c 6 Nov 2002 19:24:20 - 1.14
+++ posix/regex_internal.c 13 Nov 2002 04:00:08 - 1.15
@@ -66,7 +66,8 @@ static void re_string_construct_common (
re_string_t *pstr,
RE_TRANSLATE_TYPE trans, int icase);
#ifdef RE_ENABLE_I18N
-static int re_string_skip_chars (re_string_t *pstr, int new_raw_idx);
+static int re_string_skip_chars (re_string_t *pstr, int new_raw_idx,
+wint_t *last_wc);
#endif /* RE_ENABLE_I18N */
static re_dfastate_t *create_newstate_common (re_dfa_t *dfa,
const re_node_set *nodes,
@@ -333,21 +334,24 @@ build_wcs_upper_buffer (pstr)
Return the index. */
static int
-re_string_skip_chars (pstr, new_raw_idx)
+re_string_skip_chars (pstr, new_raw_idx, last_wc)
re_string_t *pstr;
int new_raw_idx;
+ wint_t
Bug#165603: man-db: me too
On Wed, Nov 20, 2002 at 02:12:41AM +, Colin Watson wrote: Here's the patch. I've backported it such that it applies against glibc 2.1.3-4, since there were some whitespace changes in between. If you want to take those too for simplicity, I can put together a combined patch. The crucial bits are chunks 4 and 5 of regex_internal.c; I think the rest are dependent. Note that the test suite is still running here. For the record, the tests pass here, and apropos seems much healthier: I can't get it to segfault with the new libc.so LD_PRELOADed, and valgrind is happy. -- Colin Watson [EMAIL PROTECTED]
Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 05:33:15AM -0700, Jeff Bailey wrote: On Tue, Oct 22, 2002 at 11:51:32AM +0100, Colin Watson wrote: Please see http://bugs.debian.org/165603 for context. The summary is that apropos segfaults inside regexec() when using glibc 2.3.1 in a locale other than C. To reproduce, get http://people.debian.org/~branden/bug165603_index.bt.bz2, uncompress, install as ~/man/index.bt, 'export LC_ALL=en_US' (or some other non-C locale installed on the system), and run 'apropos -M ~/man xkb'. Excellent! Thanks for the test case. There have already been further patches to the regex in CVS, so I'll check this against the newest version and report upstream if necessary. Thanks a lot! Not to rush you, but any luck so far, or can I help? I've had five duplicates so far, so I have plenty of motivation ... -- Colin Watson [EMAIL PROTECTED]
Bug#165603: man-db: me too
On Tue, Oct 29, 2002 at 02:50:29PM +, Colin Watson wrote: Thanks a lot! Not to rush you, but any luck so far, or can I help? I've had five duplicates so far, so I have plenty of motivation ... Sorry, I haven't looked at it yet. I just finished my weekend from hell (I had 2 speaking engagements, plus another conference, but had Marcus Brinkmann visiting from Germany). It's on my todo list for this week, though. If only I could put off that dayjob thing... =) -- When you get to the heart, use a knife and fork. - Instructions for eating an artichoke.
Re: Bug#165603: man-db: me too
reassign 165603 libc6
thanks
Hi,
Please see http://bugs.debian.org/165603 for context. The summary is
that apropos segfaults inside regexec() when using glibc 2.3.1 in a
locale other than C. To reproduce, get
http://people.debian.org/~branden/bug165603_index.bt.bz2, uncompress,
install as ~/man/index.bt, 'export LC_ALL=en_US' (or some other non-C
locale installed on the system), and run 'apropos -M ~/man xkb'.
There are no problems with glibc 2.2.5, and according to the NEWS file
glibc's regex implementation has just been completely rewritten.
On Tue, Oct 22, 2002 at 01:54:10AM +0100, Colin Watson wrote:
Aha! On the off-chance, I tried this in a chroot with glibc 2.3.1 and it
segfaulted. Ditto with en_US, which I'm guessing Branden's using.
I now believe that this is a bug in glibc. Unfortunately I can't
persuade either gdb or valgrind to give me any line number information
from /usr/lib/debug/libc.so.6, so I can't debug it in any more detail.
(Is this a bug too? If so, I can file it separately.)
(gdb) bt
#0 0x400c29e3 in re_exec () from /lib/libc.so.6
#1 0x400c27c3 in re_exec () from /lib/libc.so.6
#2 0x400bdae3 in re_exec () from /lib/libc.so.6
#3 0x400bd1f2 in regexec () from /lib/libc.so.6
#4 0x080498ad in parse_whatis (page=0xbee8 xkb, lowpage=0x8050b40 xkb,
whatis=0x807b00a the ISO 8859-2 character set encoded in octal, decimal, and
hexadecimal) at whatis.c:413
#5 0x08049a3e in apropos (page=0xbee8 xkb, lowpage=0x8050b40 xkb) at
whatis.c:488
#6 0x08049d44 in search (page=0xbee8 xkb) at whatis.c:563
#7 0x0804a0b3 in main (argc=4, argv=0xbdd4) at whatis.c:711
A more useful backtrace with the aid of libc6-dbg is:
(gdb) bt
#0 0x400c09e3 in re_string_context_at () from /usr/lib/debug/libc.so.6
#1 0x400c07c3 in re_string_reconstruct () from /usr/lib/debug/libc.so.6
#2 0x400bbae3 in re_search_internal () from /usr/lib/debug/libc.so.6
#3 0x400bb1f2 in regexec () from /usr/lib/debug/libc.so.6
#4 0x080498ad in parse_whatis (page=0xbec6 xkb,
lowpage=0x8050b40 xkb,
whatis=0x807b00a the ISO 8859-2 character set encoded in octal, decimal, and
hexadecimal) at whatis.c:413
#5 0x08049a3e in apropos (page=0xbec6 xkb, lowpage=0x8050b40 xkb)
at whatis.c:488
#6 0x08049d44 in search (page=0xbec6 xkb) at whatis.c:563
#7 0x0804a0b3 in main (argc=4, argv=0xbdb4) at whatis.c:711
There seems to be some subtle memory corruption. I haven't managed to
pin any of this down to a segfault with a test program yet. However, I
can pin it down to something valgrind complains about quite easily, so I
would suggest that that would be the first place to look.
$ cat regtest.c
#include stdio.h
#include regex.h
int main (int argc, char **argv)
{
regex_t preg;
int errcode;
errcode = regcomp (preg, xkb, REG_EXTENDED | REG_NOSUB | REG_ICASE);
if (errcode) {
perror (regcomp);
return 1;
}
errcode = regexec (preg, hello world, 0, (regmatch_t *) 0, 0);
if (errcode == 0) {
fprintf (stderr, regexec succeeded incorrectly\n);
return 1;
} else if (errcode != REG_NOMATCH) {
perror (regexec);
return 1;
}
return 0;
}
$ LD_LIBRARY_PATH=/usr/lib/debug valgrind -v --num-callers=20 ./regtest
==7085== valgrind-1.0.3, a memory error detector for x86 GNU/Linux.
==7085== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==7085== Startup, with flags:
==7085==--suppressions=/usr/lib/valgrind/woody.supp
==7085==-v
==7085==--num-callers=20
==7085== Reading suppressions file: /usr/lib/valgrind/woody.supp
==7085== Reading syms from /home/cjwatson/regtest
==7085==object doesn't have any debug info
==7085== Reading syms from /lib/ld-2.3.1.so
==7085==object doesn't have any debug info
==7085== Reading syms from /usr/lib/valgrind/valgrind.so
==7085== Reading syms from /usr/lib/debug/libc-2.3.1.so
==7085== Estimated CPU clock rate is 506 MHz
==7085==
==7085== Conditional jump or move depends on uninitialised value(s)
==7085==at 0x402F4AAC: re_search_internal (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x402F41F2: __regexec (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x8048507: main (in /home/cjwatson/regtest)
==7085==by 0x402609D3: __libc_start_main (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x80483F1: (within /home/cjwatson/regtest)
==7085==
==7085== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)
==7085==
==7085== 12 errors in context 1 of 1:
==7085== Conditional jump or move depends on uninitialised value(s)
==7085==at 0x402F4AAC: re_search_internal (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x402F41F2: __regexec (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x8048507: main (in /home/cjwatson/regtest)
==7085==by 0x402609D3: __libc_start_main (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x80483F1: (within /home/cjwatson/regtest)
==7085== IN SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)
Re: Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 11:51:32AM +0100, Colin Watson wrote: Please see http://bugs.debian.org/165603 for context. The summary is that apropos segfaults inside regexec() when using glibc 2.3.1 in a locale other than C. To reproduce, get http://people.debian.org/~branden/bug165603_index.bt.bz2, uncompress, install as ~/man/index.bt, 'export LC_ALL=en_US' (or some other non-C locale installed on the system), and run 'apropos -M ~/man xkb'. Excellent! Thanks for the test case. There have already been further patches to the regex in CVS, so I'll check this against the newest version and report upstream if necessary. Thanks for getting this! -- learning from failures is nice in theory... but in practice, it sucks :) - Wolfgang Jaehrling -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#165603: man-db: me too
reassign 165603 libc6
thanks
Hi,
Please see http://bugs.debian.org/165603 for context. The summary is
that apropos segfaults inside regexec() when using glibc 2.3.1 in a
locale other than C. To reproduce, get
http://people.debian.org/~branden/bug165603_index.bt.bz2, uncompress,
install as ~/man/index.bt, 'export LC_ALL=en_US' (or some other non-C
locale installed on the system), and run 'apropos -M ~/man xkb'.
There are no problems with glibc 2.2.5, and according to the NEWS file
glibc's regex implementation has just been completely rewritten.
On Tue, Oct 22, 2002 at 01:54:10AM +0100, Colin Watson wrote:
Aha! On the off-chance, I tried this in a chroot with glibc 2.3.1 and it
segfaulted. Ditto with en_US, which I'm guessing Branden's using.
I now believe that this is a bug in glibc. Unfortunately I can't
persuade either gdb or valgrind to give me any line number information
from /usr/lib/debug/libc.so.6, so I can't debug it in any more detail.
(Is this a bug too? If so, I can file it separately.)
(gdb) bt
#0 0x400c29e3 in re_exec () from /lib/libc.so.6
#1 0x400c27c3 in re_exec () from /lib/libc.so.6
#2 0x400bdae3 in re_exec () from /lib/libc.so.6
#3 0x400bd1f2 in regexec () from /lib/libc.so.6
#4 0x080498ad in parse_whatis (page=0xbee8 xkb, lowpage=0x8050b40
xkb,
whatis=0x807b00a the ISO 8859-2 character set encoded in octal, decimal,
and hexadecimal) at whatis.c:413
#5 0x08049a3e in apropos (page=0xbee8 xkb, lowpage=0x8050b40 xkb) at
whatis.c:488
#6 0x08049d44 in search (page=0xbee8 xkb) at whatis.c:563
#7 0x0804a0b3 in main (argc=4, argv=0xbdd4) at whatis.c:711
A more useful backtrace with the aid of libc6-dbg is:
(gdb) bt
#0 0x400c09e3 in re_string_context_at () from /usr/lib/debug/libc.so.6
#1 0x400c07c3 in re_string_reconstruct () from /usr/lib/debug/libc.so.6
#2 0x400bbae3 in re_search_internal () from /usr/lib/debug/libc.so.6
#3 0x400bb1f2 in regexec () from /usr/lib/debug/libc.so.6
#4 0x080498ad in parse_whatis (page=0xbec6 xkb,
lowpage=0x8050b40 xkb,
whatis=0x807b00a the ISO 8859-2 character set encoded in octal, decimal,
and hexadecimal) at whatis.c:413
#5 0x08049a3e in apropos (page=0xbec6 xkb, lowpage=0x8050b40 xkb)
at whatis.c:488
#6 0x08049d44 in search (page=0xbec6 xkb) at whatis.c:563
#7 0x0804a0b3 in main (argc=4, argv=0xbdb4) at whatis.c:711
There seems to be some subtle memory corruption. I haven't managed to
pin any of this down to a segfault with a test program yet. However, I
can pin it down to something valgrind complains about quite easily, so I
would suggest that that would be the first place to look.
$ cat regtest.c
#include stdio.h
#include regex.h
int main (int argc, char **argv)
{
regex_t preg;
int errcode;
errcode = regcomp (preg, xkb, REG_EXTENDED | REG_NOSUB | REG_ICASE);
if (errcode) {
perror (regcomp);
return 1;
}
errcode = regexec (preg, hello world, 0, (regmatch_t *) 0, 0);
if (errcode == 0) {
fprintf (stderr, regexec succeeded incorrectly\n);
return 1;
} else if (errcode != REG_NOMATCH) {
perror (regexec);
return 1;
}
return 0;
}
$ LD_LIBRARY_PATH=/usr/lib/debug valgrind -v --num-callers=20 ./regtest
==7085== valgrind-1.0.3, a memory error detector for x86 GNU/Linux.
==7085== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==7085== Startup, with flags:
==7085==--suppressions=/usr/lib/valgrind/woody.supp
==7085==-v
==7085==--num-callers=20
==7085== Reading suppressions file: /usr/lib/valgrind/woody.supp
==7085== Reading syms from /home/cjwatson/regtest
==7085==object doesn't have any debug info
==7085== Reading syms from /lib/ld-2.3.1.so
==7085==object doesn't have any debug info
==7085== Reading syms from /usr/lib/valgrind/valgrind.so
==7085== Reading syms from /usr/lib/debug/libc-2.3.1.so
==7085== Estimated CPU clock rate is 506 MHz
==7085==
==7085== Conditional jump or move depends on uninitialised value(s)
==7085==at 0x402F4AAC: re_search_internal (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x402F41F2: __regexec (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x8048507: main (in /home/cjwatson/regtest)
==7085==by 0x402609D3: __libc_start_main (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x80483F1: (within /home/cjwatson/regtest)
==7085==
==7085== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)
==7085==
==7085== 12 errors in context 1 of 1:
==7085== Conditional jump or move depends on uninitialised value(s)
==7085==at 0x402F4AAC: re_search_internal (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x402F41F2: __regexec (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x8048507: main (in /home/cjwatson/regtest)
==7085==by 0x402609D3: __libc_start_main (in /usr/lib/debug/libc-2.3.1.so)
==7085==by 0x80483F1: (within /home/cjwatson/regtest)
==7085== IN SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)
Processed: Re: Bug#165603: man-db: me too
Processing commands for [EMAIL PROTECTED]: reassign 165603 libc6 Bug#165603: man-db: SEGV in apropos when running apropos xkb Bug reassigned from package `man-db' to `libc6'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 11:51:32AM +0100, Colin Watson wrote: Please see http://bugs.debian.org/165603 for context. The summary is that apropos segfaults inside regexec() when using glibc 2.3.1 in a locale other than C. To reproduce, get http://people.debian.org/~branden/bug165603_index.bt.bz2, uncompress, install as ~/man/index.bt, 'export LC_ALL=en_US' (or some other non-C locale installed on the system), and run 'apropos -M ~/man xkb'. Excellent! Thanks for the test case. There have already been further patches to the regex in CVS, so I'll check this against the newest version and report upstream if necessary. Thanks for getting this! -- learning from failures is nice in theory... but in practice, it sucks :) - Wolfgang Jaehrling
Bug#165603: man-db: me too
On Tue, Oct 22, 2002 at 01:54:10AM +0100, Colin Watson wrote: Aha! On the off-chance, I tried this in a chroot with glibc 2.3.1 and it segfaulted. Ditto with en_US, which I'm guessing Branden's using. You seem to have already narrowed this down, but yes, that's the case. $ locale LANG=POSIX LC_CTYPE=en_US LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= Not sure why that stuff didn't show up in reportbug's output. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven pgpryKMEH7o0s.pgp Description: PGP signature
