Bug 474140 - electric fence and valgrind reporting problem in regexp glibc
Summary: electric fence and valgrind reporting problem in regexp glibc
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 10
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-02 13:18 UTC by Lukas Bezdicka
Modified: 2008-12-05 08:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-05 08:11:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Lukas Bezdicka 2008-12-02 13:18:05 UTC
Description of problem:
When running crystalspace's walktest in electricfence i noticed that it had problem with regexp function from glibc. So I tried to run grep in ef and it reported similar problem.

Version-Release number of selected component (if applicable):
glibc-common-2.9-2.x86_64
glibc-devel-2.9-2.x86_64
glibc-2.9-2.i386
glibc-2.9-2.x86_64
glibc-debuginfo-2.9-2.x86_64
glibc-headers-2.9-2.x86_64


How reproducible:
always

Steps to Reproduce:
1. ulimit -c xyz; ef grep lala || valgrind --tool=memcheck grep lala
2. you get core open it in gdb or read valgrind output
3. 
(gdb) bt
#0  0x00000033d70331c7 in kill () from /lib64/libc-2.9.so
#1  0x0000000000112235 in ?? () from /usr/lib64/libefence.so.0.0
#2  0x00000000001127cd in EF_Abort () from /usr/lib64/libefence.so.0.0
#3  0x0000000000111d77 in memalign () from /usr/lib64/libefence.so.0.0
#4  0x00000033d70c2900 in analyze () at regcomp.c:1105
#5  re_compile_internal (preg=0x7f446f874fa8, pattern=0x7fff77960523 "lala", length=<value optimized out>, syntax=2822) at regcomp.c:778
#6  0x00000033d70c392b in __re_compile_pattern (pattern=0x7f446f8396e0 "", length=<value optimized out>, bufp=0xfae) at regcomp.c:229
#7  0x000000000040d673 in fflush () at iofflush.c:36
#8  0x0000000000404814 in fflush () at iofflush.c:36
#9  0x00000033d701e546 in __libc_start_main (main=0x403eb0 <fflush+7272>, argc=2, ubp_av=0x7fff7795fba8, init=0x410950, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=0x7fff7795fb98) at libc-start.c:220
#10 0x0000000000402289 in fflush () at iofflush.c:36
#11 0x00007fff7795fb98 in ?? ()
#12 0x000000000000001c in ?? ()
#13 0x0000000000000002 in ?? ()
#14 0x00007fff7796051e in ?? ()
#15 0x00007fff77960523 in ?? ()
#16 0x0000000000000000 in ?? ()

  
Actual results:
ef reports problem

Expected results:
it shouldn't :)

Additional info:

Comment 1 Ulrich Drepper 2008-12-05 03:38:23 UTC
I cannot reproduce any problem.  ef crashes, yes, but that's an ef problem:

ef /bin/grep lala

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens <bruce>

ElectricFence Aborting: Allocating 0 bytes, probably a bug.
/usr/bin/ef: line 20:  8790 Illegal instruction     ( export LD_PRELOAD=libefence.so.0.0; exec "$@" )


Under valgrind I see no problem at all.

The backtrace you show also doesn't indicate a problem in the code.  A crash inside ef's memory allocation code can indicate a problem in ef just as well.

You'll have to provide more detailed instructions on how to reproduce the problem.

Comment 2 Jakub Jelinek 2008-12-05 08:11:44 UTC
Allocating 0 bytes, probably a bug.
says it all, not a bug.
EF_ALLOW_MALLOC_0
By default, Electric Fence traps calls to malloc() with a size of zero, because  they  are  often  the result  of  a software bug. If EF_ALLOW_MALLOC_0 is non-zero, the software will not trap calls to malloc() with a size of zero.  To change this value, set EF_ALLOC_MALLOC_0 in the shell environment to an
integer value, or assign to the global integer variable EF_ALLOC_MALLOC_0 using a debugger.

So just use EF_ALLOC_MALLOC_0=0 ef /bin/grep lala


Note You need to log in before you can comment on or make changes to this bug.