Bug 474140 - electric fence and valgrind reporting problem in regexp glibc
electric fence and valgrind reporting problem in regexp glibc
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 08:18 EST by Lukas Bezdicka
Modified: 2008-12-05 03:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-05 03:11:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lukas Bezdicka 2008-12-02 08:18:05 EST
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-04 22:38:23 EST
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@perens.com>

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 03:11:44 EST
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.