Red Hat Bugzilla – Bug 199000
Seg fault pointing to glibc-2.4-8.
Last modified: 2007-11-30 17:11:37 EST
Description of problem: Seg faults in a large program have been traced to the regex function of glibc using the Electric Fence memory checker. Version-Release number of selected component (if applicable): glibc-2.4-8 How reproducible: Compile attached test program: g++ -g -o tr test_regex_match.cc -lefence Run program: tr 1 Actual results: =====> WARNING(test_regex_match.cc,16): regex empty! WARNING(test_regex_match.cc,19): test string empty! Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com> ElectricFence Aborting: Allocating 0 bytes, probably a bug. Illegal instruction (core dumped) <===== Expected results: =====> WARNING(test_regex_match.cc,18): regex empty! WARNING(test_regex_match.cc,22): test string empty! Normal end. <===== Additional info: Ouput from stack backtrace (`gdb tr core`): =====> tomtomjr 1% gdb tr core GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x970000 Core was generated by `./tr 1'. Program terminated with signal 4, Illegal instruction. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libefence.so.0...done. Loaded symbols for /usr/lib/libefence.so.0 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x00970402 in __kernel_vsyscall () (gdb) bt #0 0x00970402 in __kernel_vsyscall () #1 0x009b6456 in kill () from /lib/libc.so.6 #2 0x006e0e77 in Page_Create () from /usr/lib/libefence.so.0 #3 0x006e1177 in EF_Abort () from /usr/lib/libefence.so.0 #4 0x006e095a in memalign () from /usr/lib/libefence.so.0 #5 0x006e0a93 in malloc () from /usr/lib/libefence.so.0 #6 0x00a3a1dd in re_compile_internal () from /lib/libc.so.6 #7 0x00a3a81f in regcomp () from /lib/libc.so.6 #8 0x08048b84 in regex_match (regex=@0xbfb779bc, s=@0xbfb779b4, case_sensitive=true) at test_regex_match.cc:34 #9 0x08048e2f in main (argc=2, argv=0xbfb77a74) at test_regex_match.cc:135 (gdb) quit tomtomjr 2% <=====
Created attachment 132490 [details] Test program to demonstrate the Electric Fence diagnostic pointing to glibc.
*** Bug 199003 has been marked as a duplicate of this bug. ***
1. I forgot to add the header for the test case, but all it does is declare the "regex_match" function: bool regex_match(const std::string& regex, const std::string& s, const bool case_sensitive = true); 2. Note that I tested the "regex_match" function using const char pointers instead of std strings and got the same results. And the same failure occurs without the empty regex and test strings.
Note some other errors seem to be evident. When I used the Boost regex library instead of glibc on the identical set of test strings and regexes, Boost threw an exception on the regex "\\([csu])\\)" which has an unmatched right parenthesis. That may not be a POSIX error, but it should be. In addition, no errors were indicated by the regexec function for an empty regex ("").
You just need to use EF_ALLOW_MALLOC_0=1 in the environment for this testcase, allocating 0 bytes here is not a bug.