This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
[achurch@achurch.org (Andrew Church)] glibc 2.2.2 strtok() segfault
- To: libc-alpha at sources dot redhat dot com
- Subject: [achurch@achurch.org (Andrew Church)] glibc 2.2.2 strtok() segfault
- From: Andreas Jaeger <aj at suse dot de>
- Date: 21 Feb 2001 11:55:51 +0100
- Cc: achurch at achurch dot org
Andrew reported a bug in strtok. I think the bug report is valid and
have added the testcase to glibc. I had to use a new file since we
have static data in strtok and the other tests in tester.c initialize
the static data.
Andrew, can we commit this to glibc's testsuite?
Uli, ok to commit?
Andreas
2001-02-21 Andreas Jaeger <aj@suse.de>
* string/tst-strok.c: New testcase, reported by
Andrew Church <achurch@achurch.org>.
============================================================
Index: string/tst-strtok.c
--- string/tst-strtok.c created
+++ string/tst-strtok.c Wed Feb 21 11:46:41 2001 1.1
@@ -0,0 +1,15 @@
+/* Testcase for strok reported by Andrew Church <achurch@achurch.org>. */
+
+int
+main (void)
+{
+ char buf[1] = {0};
+
+ strtok (buf, " ");
+ strtok (NULL, " ");
+
+ return 0;
+}
+
+
+
Topics:
glibc 2.2.2 strtok() segfault
- To: bug-glibc at gnu dot org
- Subject: glibc 2.2.2 strtok() segfault
- From: achurch at achurch dot org (Andrew Church)
There is a bug in strtok() on the i686 platform, and possibly
others, which will cause a segmentation fault under limited conditions.
The following program demonstrates this bug:
---------------------------
#include <string.h>
int main() {
char buf[1] = {0};
char *s1, *s2;
s1 = strtok(buf, " ");
s2 = strtok(NULL, " "); // segfault here
return 0;
}
---------------------------
The bug occurs because strtok()'s internal saved string pointer
(save_ptr in sysdeps/i386/i686/strtok.S) is initialized to NULL at
program start time, and is not updated after the first strtok() call
(which returns NULL), so that the NULL in the second call causes this
pointer to be used and a NULL dereference to occur.
I do realize that calling strtok() with NULL after a NULL result
could be considered improper practice, depending on how strtok() is
defined in the standards (my man page doesn't say anything about the
behavior of strtok() after a NULL result), but this is the first time
I have seen a libc that crashes in such a circumstance, and I think
that at least minimal robustness is appropriate here.
--Andrew Church
achurch@achurch.org | New address - please note.
http://achurch.org/ | $B%a!<%k%"%I%l%9$,JQ$o$j$^$7$?!#(B
_______________________________________________
Bug-glibc mailing list
Bug-glibc@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-glibc
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj