From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: I seem to be seeing a problem in strtok that is causing id-utils3.2 to fail. I downloaded the id-utils3.2 source on my redhat 8 machine, ran ./configure, then make install. Everything seems ok, but when I run mkid I get a segfault right away. I seem to be dying in strtok during the processing of parse_file_name #0 vectorize_string (string=0x804edfb ".", delimiter_class=0x804f147 "/") at walker.c:659 #1 0x0804d8e0 in parse_file_name (file_name=0x804edfb ".", relative_dir_link=0x8059900) at walker.c:534 #2 0x08049305 in main (argc=0, argv=0x8050038) at mkid.c:275 #3 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) l 654 vectorize_string (char *string, char *delimiter_class) 655 { 656 char **vector_0 = MALLOC (char *, 2 + strlen (string) / 2); 657 char **vector = vector_0; 658 659 *vector = strtok (string, delimiter_class); 660 while (*vector) 661 *++vector = strtok (0, delimiter_class); 662 return REALLOC (vector_0, char *, ++vector - vector_0); 663 } (gdb) p string $1 = 0x804edfb "." (gdb) p delimiter_class $2 = 0x804f147 "/" (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x4207af65 in strtok () from /lib/i686/libc.so.6 [root@messugah dublin]# ldd /usr/local/bin/mkid libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) file /lib/i686/libc.so.6 /lib/i686/libc.so.6: symbolic link to libc-2.2.93.so According to the docs this looks like the right way to use strtok. Peter Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. download id-utils3.2 2.build 3.try running mkid Actual Results: SEGV Expected Results: A big lovely ID file should have been created Additional info:
Wild guess. Isn't that "." passed to vectorize_string a string literal (ie. read-only data)?
No feedback, plus the hypothesis that "." is in .rodata sounds very likely (0x804edfb is not really too far away from 0x804d8e0 which certainly is in r/o segment).