Menu

#1434 regcomp in libregex crashes

MSYS
closed
nobody
None
none
Behaves_as_Documented
2016-10-27
2010-05-31
Bruce Merry
No

I have compiled a trivial C program that just calls regcomp in libregex, and it segfaults in regcomp. Running it in gdb gives this rather unexpected backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x7105d806 in strsep () from C:\msys\bin\msys-1.0.dll
(gdb) bt
#0 0x7105d806 in strsep () from C:\msys\bin\msys-1.0.dll
#1 0x7102d6b7 in msys-1!calloc () from C:\msys\bin\msys-1.0.dll
#2 0x7108cd41 in strftime () from C:\msys\bin\msys-1.0.dll
#3 0x7102d3b0 in msys-1!malloc () from C:\msys\bin\msys-1.0.dll
#4 0x6af42da4 in regcomp () from C:\msys\bin\msys-regex-1.dll
#5 0x004013eb in main () at hello.c:7

The test program is:
#include <regex.h>
#include <string.h>

int main()
{
regex_t preg;
regcomp(&preg, "test", REG_NOSUB | REG_EXTENDED);
return 0;
}

and it is compiled with: gcc -o hello hello.c -Wall -g -lregex

GCC version:
gcc -v:
Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

binutils version:
GNU ld (GNU Binutils) 2.20

regex version:
libregex-1.20090805-2-msys-1.0.13-dev.tar.lzma
libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma

Build environment:
MSYS_NT-5.1 HACTAR 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys
(occurs with both msys.bat --rxvt MSYS and msys.bat --norxvt MSYS)

I installed mingw and msys by creating directories c:\mingw and c:\msys and installing the files below into one or the other (those with msys in the same into c:\msys, the rest into c:\mingw), creating an /etc/fstab to mount /mingw, and adding /c/msys/include and /c/msys/lib to CPATH and LIBRARY_PATH respectively.
binutils-2.20.1-2-mingw32-bin.tar.gz
gcc-c++-4.5.0-1-mingw32-bin.tar.lzma
gcc-core-4.5.0-1-mingw32-bin.tar.lzma
gdb-7.1-2-mingw32-bin.tar.gz
gmp-5.0.1-1-mingw32-dev.tar.lzma
libexpat-2.0.1-1-mingw32-dll-1.tar.gz
libgcc-4.5.0-1-mingw32-dll-1.tar.lzma
libgmp-5.0.1-1-mingw32-dll-10.tar.lzma
libgomp-4.5.0-1-mingw32-dll-1.tar.lzma
libmpc-0.8.1-1-mingw32-dll-2.tar.lzma
libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma
libpthread-2.8.0-3-mingw32-dll-2.tar.lzma
libssp-4.5.0-1-mingw32-dll-0.tar.lzma
libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma
mingwrt-3.18-mingw32-dev.tar.gz
mingwrt-3.18-mingw32-dll.tar.gz
mpc-0.8.1-1-mingw32-dev.tar.lzma
mpfr-2.4.1-1-mingw32-dev.tar.lzma
pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma
w32api-3.14-mingw32-dev.tar.gz
bash-3.1.17-3-msys-1.0.13-bin.tar.lzma
bison-2.4.2-1-msys-1.0.13-bin.tar.lzma
bzip2-1.0.5-2-msys-1.0.13-bin.tar.lzma
coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
gettext-0.17-2-msys-1.0.13-bin.tar.lzma
grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
less-436-2-msys-1.0.13-bin.tar.lzma
libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
libiconv-1.13.1-2-msys-1.0.13-bin.tar.lzma
libiconv-1.13.1-2-msys-1.0.13-dll-2.tar.lzma
libintl-0.17-2-msys-dll-8.tar.lzma
libregex-1.20090805-2-msys-1.0.13-dev.tar.lzma
libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
m4-1.4.14-1-msys-1.0.13-bin.tar.lzma
msysCORE-1.0.14-1-msys-1.0.14-bin.tar.lzma
perl-5.6.1_2-2-msys-1.0.13-bin.tar.lzma
rxvt-2.7.2-3-msys-1.0.14-bin.tar.lzma
sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
tar-1.23-1-msys-1.0.13-bin.tar.lzma

Discussion

  • Bruce Merry

    Bruce Merry - 2010-05-31

    I built libregex from source (same version of regex as above, although I had to install a bunch of extra packages to support the build), and that version seems to run without crashing (I'm still fighting other bugs in the system to see if it'll work on my production code instead of this example).

     
  • Bruce Merry

    Bruce Merry - 2010-05-31

    I've now tested with the real-world use of libregex where I ran into this problem, and it seems that building libregex myself fixes the problem.

     
  • Earnie Boyd

    Earnie Boyd - 2010-05-31

    The issue here is that you are using a dll package built to require the MSYS runtime instead of the MSVCRT runtime and trying to use it with a native application. It just isn't going to work. When you rebuilt from source you built a library that wasn't dependent on MSYS runtime but instead MSVCRT.

    See http://www.mingw.org/PackageIdentificationHOWTO for more information on identifying the use of a distributed package.

     
  • Earnie Boyd

    Earnie Boyd - 2010-05-31
    • milestone: --> Behaves_as_Documented
    • status: open --> closed
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-21
    • labels: MSYS -->
    • resolution: --> none
    • category: --> Behaves_as_Documented
    • milestone: Behaves_as_Documented --> MSYS
     
  • Simon Sobisch

    Simon Sobisch - 2016-10-27

    As I've just had the same problem, here's how to use the MSVCRT variant via mingw instead of using the MSYS variant:

    • optional (in my case): use the installer to remove the MSYS versions of the additional libraries (in my case gmp/pdcurses)
    • check that you either build the needed libraries from source with --prefix=/mingw (I guess CPPFLAGS=-I/mingw/include LD_FLAGS=-L/mingw/lib may be enough) or use the installer to get the mingw32 variant
    • build whatever you wanted to originally use, with the options above