#967 VERY weird crash bug in cross-compiled app

WSL
closed
None
fixed
Aged_issue
2013-01-28
2006-09-28
No

Situation:

We're building windows executables via a mingw
cross-compiler on debian linux (tried both with the
debian 'tetsing' mingw32 packages and a self-compiled
gcc 4.0.2 targeting mingw32 + latest runtime/w32api;
both produced same result).
In 99.9% of cases, there are no problems, but for some
input files, one of the application (reproducibly)
segaults. Unfortunately, when run under gdb, the crash
goes away, making it impossible to debug - until we
discovered drmingw :)
Use of drmingw showed the location of the crash, in a
C++ wrapper around sprintf:

string
format(const char* const format, ...)
{
char* message = 0;
string retval;
va_list arg_list;
va_start (arg_list, format);
#if defined(__GLIBC__) // vasprintf is the easiest way,
but only glibc has it
vasprintf (&message, format, arg_list);
#else // vsnprintf() is fine too, just slightly less
efficient
const int default_size = 4096;
message = (char*) malloc (default_size);
if (message != 0) {
int required_size = vsnprintf (message,
default_size, format, arg_list);
if (required_size + 1 > default_size) {
message = (char*) realloc (message, required_size + 1);
if (message != 0)
vsnprintf (message, required_size + 1, format,
arg_list);
}
}
#endif
va_end (arg_list);
if (message != 0) {
retval = message; <<<< crash here
free (message);
}
return retval;
}

In particular, it seemed that a strlen() call internal
to the string assignment operator was causing the
segfault. The problem is that the pointer being
assigned is guaranteed not to be null, so the only
remaining possibility I can think of is a bad pointer,
and the code precludes that too.
This is when the weirdness really started - changing
the default buffer size to any value other than 4096
(512, 4095, 4097, 10 * 1024 * 1024) made the crash go
away on 2 of 3 test PCs. So unless the program's
memory was already screwed up by some buffer overflow
somewhere (valgrind on the non-cross linux build
suggests otherwise, but we don't have any valgrind-like
tools for windows to make sure), it looks like there
may be some problem in the memory allocation routines.

I have not been able to reduce this to a compact
testcase, unfortunately.

Discussion

  • Earnie Boyd

    Earnie Boyd - 2006-09-28
    • assigned_to: nobody --> earnie
    • milestone: --> Known_bugs
    • status: open --> pending-duplicate
     
  • Tim Van Holder

    Tim Van Holder - 2006-09-29

    Logged In: YES
    user_id=82337

    Oh goody - I hadn't expected to see this resolved based on
    the less-than-stellar evidence I was able to provide.

    Thanks.

     
  • Tim Van Holder

    Tim Van Holder - 2006-09-29
    • status: pending-duplicate --> open-duplicate
     
  • Danny Smith

    Danny Smith - 2006-09-29

    Logged In: YES
    user_id=11494

    I don't believe this is resolved.
    This code:

    int required_size = vsnprintf (message,
    default_size, format, arg_list);
    if (required_size + 1 > default_size) {
    message = (char*) realloc (message, required_size + 1);

    will not do what is expected on mingw32. Namely, if the
    buffer isn't large enough, vsnprintf returns -1, not
    required size. See,eg
    http://sourceware.org/ml/win32-x11/2005-q4/msg00049.html
    or google for mingw snprintf bug

    Danny

     
  • Tim Van Holder

    Tim Van Holder - 2006-09-29

    Logged In: YES
    user_id=82337

    Yes but vsnprintf() is guaranteed to write a terminating
    NUL, no? Then at worst, that behaviour results in truncated
    strings, not a crash. It's partly why I chose to use a
    buffer for the initial call (instead of pass NULL first, as
    in the code referenced from that mailing list message).

     
  • Earnie Boyd

    Earnie Boyd - 2006-09-29
    • status: open-duplicate --> closed-duplicate
     
  • Earnie Boyd

    Earnie Boyd - 2006-09-29
    • assigned_to: earnie --> dannysmith
    • status: closed-duplicate --> open-duplicate
     
  • Earnie Boyd

    Earnie Boyd - 2006-09-29

    Logged In: YES
    user_id=15438

    Maybe I shouldn't have closed this. Danny, I'll let you
    control this ticket.

     
  • Luke Dunstan

    Luke Dunstan - 2006-09-29

    Logged In: YES
    user_id=30442

    No, _vsnprintf() / _snprintf() are not guaranteed to write
    a NUL. Read the documentation at msdn.microsoft.com.
    Perhaps it is unfortunate that MinGW provides the aliases
    vsnprintf/snprintf without the underscores because it
    leads people to believe that the functions behave
    according to the ISO C standard functions of the same
    names, which they don't.

     
  • Earnie Boyd

    Earnie Boyd - 2006-09-30

    Logged In: YES
    user_id=15438

    So perhaps we should reverse the default logic for
    MOLDNAMES? We set the default to not define the MOLDNAMES
    unless USE_MOLDNAMES is set. And we give a warning if
    USE_MOLDNAMES is set that states that the functions may not
    be per ISO C standard specifications ant that
    MSDN.MICROSOFT.COM should be checked.

     
  • Earnie Boyd

    Earnie Boyd - 2012-10-22
    • status: open-duplicate --> closed-out-of-date
     
  • Earnie Boyd

    Earnie Boyd - 2012-10-22

    At some point we provided our own implementations for these. AFAICS this issue has been resolved but I don't know when.

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-28
    • labels: mingw runtime (deprecated use WSL) -->
    • status: closed-out-of-date --> closed
    • resolution: --> fixed
    • category: --> Aged_issue
    • milestone: Known_bugs --> WSL
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks