Bug 474140
| Summary: | electric fence and valgrind reporting problem in regexp glibc | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lukas Bezdicka <social> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | drepper, jakub, lkundrak |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-12-05 08:11:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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 |
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: