0

I have a network and multithreaded application that was originally developed for Linux. It uses libev, mbedtls, protobuf-c and other libraries. My goal is to run it on Windows. I tried to port it with msys2 and cygwin. I decided to do it with cygwin, because seems there were more packages in the repository. Finally, I started it on Windows, but it works extremely unstable. In gdb it almost always crashes with damaged stack. After recovering SP the backtrace usually shows:

Thread 1 "App" received signal SIGABRT, Aborted.
0x0000000100b86619 in operator new (sz=0) at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/new_op.cc:50
50      /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/new_op.cc: No such file or directory.
(gdb) bt
#0  0x0000000100b86619 in operator new (sz=0) at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/new_op.cc:50
#1  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) set $pc = *(void **)$rsp
(gdb) set $rsp = $rsp + 8
(gdb) info stack
#0  0x00007ff85c4e415f in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/KERNELBASE.dll
#1  0x000000018013efde in sig_send (p=<optimized out>, p@entry=0x0, si=..., tls=<optimized out>) at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/sigproc.cc:719
#2  0x00000001801656d4 in pthread_kill (thread=<optimized out>, sig=6) at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/thread.cc:3314
#3  0x000000018013b61b in raise (sig=<optimized out>) at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/signal.cc:306
#4  0x000000018013b94f in abort () at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/signal.cc:402
#5  0x0000000180176905 in dlmalloc (bytes=bytes@entry=32) at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/malloc.cc:4587
#6  0x00000001800d4369 in malloc (size=32) at /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/malloc_wrapper.cc:56
#7  0x00000001801367ab in _sigfe () at sigfe.s:35
#8  0x0000000100b86619 in operator new (sz=32) at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/new_op.cc:50
#9  0x00000001008bd229 in __gnu_cxx::new_allocator<char>::allocate (this=<optimized out>, __n=<optimized out>)
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/ext/new_allocator.h:102
#10 std::string::_Rep::_S_create (__capacity=__capacity@entry=7, __old_capacity=__old_capacity@entry=0, __alloc=...)
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/bits/basic_string.tcc:1058
#11 0x00000001008bc97b in std::string::_S_construct<char*> (__beg=0x100c40ae5 "0.0.0.0", __end=<optimized out>, __a=...)
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:138
#12 0x00000001008be8d7 in std::string::_S_construct_aux<char const*> (__a=..., __end=<optimized out>, __beg=0x100c40ae5 "0.0.0.0")
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/bits/basic_string.h:5137
#13 std::string::_S_construct<char const*> (__a=..., __end=<optimized out>, __beg=0x100c40ae5 "0.0.0.0")
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/bits/basic_string.h:5140
#14 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0xffffc548, __s=0x100c40ae5 "0.0.0.0", __a=...)
    at /usr/src/debug/gcc-9.3.0-2/x86_64-pc-cygwin/libstdc++-v3/include/bits/basic_string.tcc:665
. . .
#21 0x00000003f50310f2 in ev_invoke_pending () from /usr/bin/cygev-4.dll
#22 0x00000003f5033f95 in ev_run () from /usr/bin/cygev-4.dll
#23 0x00000001005c4471 in ev::loop_ref::run (this=0x100be7a28 <app+8>, flags=0) at /usr/include/ev++.h:211

Sometimes it crashes in malloc(). Obviously it has memory corruption. I have some questions:

  • are there any memory tools in cygwin? (sanitizer etc)
  • is it real to get a stable application on cygwin?
  • does it make sense to use mingw/msys2 instead of cygwin?

UPD: Tested it on msys2 with the same results. So I think there's not much difference between cygwin and msys2. The problem is with the code, not the environments.

swampmanster
  • 1
  • 2
  • as there are thousands of application ported on Cygwin, I will bet on a application error, probably due to wrong assumption about the system on which is run. But of course it is possible a subtle error on the Cygwin "kernel". Most of the system calls are build around BSD like source – matzeri May 21 '20 at 17:06
  • "are there any memory tools in cygwin?" Yes, you can use Valgrind on Cygwin for example. "is it real to get a stable application on cygwin?" yes, I have non-trivial software that runs stable on Cygwin. "does it make sense to use mingw/msys2 instead of cygwin?" mingw and msys2 are very different things--msys2 could work as well as (or as poorly as Cygwin) but it depends on your application. The libraries you're trying to use are very non-trivial and might take additional effort to port to Cygwin. But if you can provide *minimal* example code that reproduces the problem I could take a look. – Iguananaut May 22 '20 at 15:20
  • Thanks, Iguananaut, but I just can't provide such example of code, at least now ... About Valgrind - I couldn't find it for cygwin. I still have a problem with the app crash. I updated backtrace above, it crashes usually in new() operator. – swampmanster Jun 02 '20 at 20:43

1 Answers1

0

I've also encountered a SIGABRT crash on Cygwin when performing malloc. The software under test is GNU nano version 5.4. However, it only crashes when it has NOT been run with gdb, so I added fprintf everywhere trying to pinpoint the place it crashes. To my surprise, it seems that an abort was called inside of malloc, which I've never met before. Here are the steps to reproduce it:

  • Get the code: git clone --depth 1 --branch v5.4 git://git.savannah.gnu.org/nano.git
  • Build the app:
  • Prepare the rcfile: echo "set indicator" > test.nanorc
  • Run the app: ./nano.exe --rcfile=test.nanorc
  • After that, click on the upper right "Full Screen" button
  • Observe that the app crashes
  • An alternative way (which is how I tested it) is to run inside of tmux:
    • Run the app
    • Split window horizontally
    • Close the newly created panel
    • Press an enter to the app

full screen nano crashed

My tracing is that it crashes at malloc, from nmalloc (utils.c:295), from add_undo (text.c:968), from do_enter (text.c:898), from process_a_keystroke (nano.c:1653). After some googling, this post said that it's likely to be a heap corruption somewhere else, so maybe a memory checking tool is needed (eg. Valgrind, but unfortunately it doesn't seem to be supported on Cygwin).

davidhcefx
  • 130
  • 1
  • 8