bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strstr in gnulib


From: Дилян Палаузов
Subject: Re: strstr in gnulib
Date: Tue, 09 Nov 2010 02:17:51 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

Post Scriptum:

The same happens with gcc 4.4.5.

Any ideas what could be wrong and why doesn't nm report printf?

On 08.11.2010 19:04, Дилян Палаузов wrote:
Hello,

The full test-programme (with configure.ac, gnulib etc) can be
downloaded from http://mail.aegee.org/patches/test-strstr-1.0.tar.gz .

address@hidden:~/proj/strstr # export CFLAGS='-O0 -g'
address@hidden:~/proj/strstr # ./configure
[...]
checking whether strstr works... no
[...]
address@hidden:~/proj/strstr # make
[...]
make[2]: Entering directory `/root/proj/strstr/lib'
GEN arg-nonnull.h
GEN c++defs.h
GEN warn-on-use.h
GEN string.h
make all-recursive
make[3]: Entering directory `/root/proj/strstr/lib'
make[4]: Entering directory `/root/proj/strstr/lib'
CC dummy.o
CC strstr.o
AR libgnu.a
make[4]: Leaving directory `/root/proj/strstr/lib'
make[3]: Leaving directory `/root/proj/strstr/lib'
make[2]: Leaving directory `/root/proj/strstr/lib'
make[2]: Entering directory `/root/proj/strstr'
CC src/src_test_strstr-test-strstr.o
CCLD src/test-strstr
make[2]: Leaving directory `/root/proj/strstr'
make[1]: Leaving directory `/root/proj/strstr'

address@hidden:~/proj/strstr # nm src/test-strstr
[... all kind of symbols starting with underscore ...]
08048364 T _start
08049ef0 b completed.5894
0804842c t critical_factorization
08049ee8 W data_start
08049ef4 b dtor_idx.5896
080483d7 t frame_dummy
080483fc T main
U memchr@@GLIBC_2.0
U memcmp@@GLIBC_2.0
U puts@@GLIBC_2.0
08048bce T rpl_strstr
U strchr@@GLIBC_2.0
08048862 t two_way_long_needle
080485ee t two_way_short_needle

address@hidden:~/proj/strstr # ulimit -c unlimited

address@hidden:~/proj/strstr # src/test-strstr
Segmentation fault (core dumped)
address@hidden:~/proj/strstr # gdb src/test-strstr core
GNU gdb (GDB) 7.0.1
[...]
Reading symbols from /root/proj/strstr/src/test-strstr...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `src/test-strstr'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7ed3eef in puts () from /lib/libc.so.6
(gdb) bt
#0 0xb7ed3eef in puts () from /lib/libc.so.6
#1 0x08048429 in main () at src/test-strstr.c:7

address@hidden:~/proj/strstr # valgrind src/test-strstr
[...]
==32610== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
[...]
==32610== Conditional jump or move depends on uninitialised value(s)
==32610== at 0x400BB07: _dl_relocate_object (in /lib/ld-2.11.1.so)
==32610== by 0x4003BF9: dl_main (in /lib/ld-2.11.1.so)
==32610== by 0x4015E8B: _dl_sysdep_start (in /lib/ld-2.11.1.so)
==32610== by 0x4001257: _dl_start (in /lib/ld-2.11.1.so)
==32610== by 0x4000806: (within /lib/ld-2.11.1.so)
==32610==
==32610== Conditional jump or move depends on uninitialised value(s)
==32610== at 0x400C479: _dl_relocate_object (in /lib/ld-2.11.1.so)
==32610== by 0x4003BF9: dl_main (in /lib/ld-2.11.1.so)
==32610== by 0x4015E8B: _dl_sysdep_start (in /lib/ld-2.11.1.so)
==32610== by 0x4001257: _dl_start (in /lib/ld-2.11.1.so)
==32610== by 0x4000806: (within /lib/ld-2.11.1.so)
==32610==
==32610== Invalid read of size 1
==32610== at 0x40BBEEF: puts (in /lib/libc-2.11.1.so)
==32610== by 0x8048428: main (test-strstr.c:7)
==32610== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==32610==
==32610== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==32610== Access not within mapped region at address 0x0
==32610== at 0x40BBEEF: puts (in /lib/libc-2.11.1.so)
==32610== by 0x8048428: main (test-strstr.c:7)
==32610== If you believe this happened as a result of a stack overflow
in your
==32610== program's main thread (unlikely but possible), you can try to
increase
==32610== the size of the main thread stack using the --main-stacksize=
flag.
==32610== The main thread stack size used in this run was 8388608.
==32610==
==32610== ERROR SUMMARY: 12 errors from 7 contexts (suppressed: 0 from 0)
==32610== malloc/free: in use at exit: 0 bytes in 0 blocks.
==32610== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==32610== For counts of detected errors, rerun with: -v
==32610== Use --track-origins=yes to see where uninitialised values come
from
==32610== All heap blocks were freed -- no leaks are possible.
Segmentation fault

address@hidden:~/proj/strstr # gcc --version
gcc (GCC) 4.5.1

address@hidden:~/proj/strstr # gcc -dumpmachine
i686-pc-linux-gnu

address@hidden:~/proj/strstr # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 1
cpu MHz : 2793.246
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts pni monitor ds_cpl cid cx16 xtpr
bogomips : 5590.50
clflush size : 64

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 1
cpu MHz : 2793.246
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts pni monitor ds_cpl cid cx16 xtpr
bogomips : 5586.43
clflush size : 64

Do you want more information?

Със здраве
Дилян


Eric Blake schrieb:
On 11/08/2010 07:31 AM, Дилян Палаузов wrote:
Hello,

When I use the latest strstr implemenation from gnulib in git, the
following program crashes (causes Segmentation fault):

#include <string.h>
#include <stdio.h>

void main() {
char *find = strstr ("**AB** **CD** **AB** **CD** **CD**", "**CD**");
printf("%s\n", find);
}

Can you provide a backtrace of the crash? I can't reproduce it. In
order to use the implementation from gnulib, you should probably be
including <config.h>.

It does not crash when I use strstr from libc-2.9 .

glibc 2.9 through 2.12 have the same bug as gnulib's strstr used to
have. You have to use something newer than 2.12 (these days, most
distros have backported the glibc.git patch back to their shipped glibc
version), to avoid that bug. But that bug was unrelated to a segfault,
so I still can't figure out why your example would be crashing.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]