[Mingw-notify] [ mingw-Bugs-1567079 ] VERY weird crash bug in cross-compiled app

[SourceForge.net <no...@so...>]

Bugs item #1567079, was opened at 2006-09-28 16:23
Message generated for change (Comment added) made by zastai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1567079&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mingw runtime
Group: Known bugs
>Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Tim Van Holder (zastai)
Assigned to: Earnie Boyd (earnie)
Summary: VERY weird crash bug in cross-compiled app

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Tim Van Holder (zastai)
Date: 2006-09-29 08:09

Message:
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.


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2006-09-28 19:51

Message:
Logged In: YES 
user_id=15438

Known issue resolved with
http://prdownloads.sourceforge.net/mingw/mingw-runtime-3.10-20060909-1-src.tar.gz?download

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1567079&group_id=2435