From: SourceForge.net <no...@so...> - 2006-09-28 14:23:56
|
Bugs item #1567079, was opened at 2006-09-28 16:23 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Van Holder (zastai) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1567079&group_id=2435 |
From: SourceForge.net <no...@so...> - 2006-09-28 17:51:51
|
Bugs item #1567079, was opened at 2006-09-28 10:23 Message generated for change (Comment added) made by earnie 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: Pending >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: Earnie Boyd (earnie) Date: 2006-09-28 13: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 |
From: SourceForge.net <no...@so...> - 2006-09-29 06:09:09
|
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 |
From: SourceForge.net <no...@so...> - 2006-09-29 07:39:48
|
Bugs item #1567079, was opened at 2006-09-29 02:23 Message generated for change (Comment added) made by dannysmith 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: Danny Smith (dannysmith) Date: 2006-09-29 19:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 18: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-29 05: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 |
From: SourceForge.net <no...@so...> - 2006-09-29 11:19:33
|
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 13:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 09:39 Message: 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 ---------------------------------------------------------------------- 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 |
From: SourceForge.net <no...@so...> - 2006-09-29 11:34:43
|
Bugs item #1567079, was opened at 2006-09-28 10:23 Message generated for change (Settings changed) made by earnie 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: Closed 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 07:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 03:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 02: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 13: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 |
From: SourceForge.net <no...@so...> - 2006-09-29 14:14:18
|
Bugs item #1567079, was opened at 2006-09-28 10:23 Message generated for change (Comment added) made by earnie 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: Danny Smith (dannysmith) 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: Earnie Boyd (earnie) Date: 2006-09-29 10:14 Message: Logged In: YES user_id=15438 Maybe I shouldn't have closed this. Danny, I'll let you control this ticket. ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 07:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 03:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 02: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 13: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 |
From: SourceForge.net <no...@so...> - 2006-09-29 17:09:43
|
Bugs item #1567079, was opened at 2006-09-28 22:23 Message generated for change (Comment added) made by infidel 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: Danny Smith (dannysmith) 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: Luke Dunstan (infidel) Date: 2006-09-30 01:09 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-09-29 22:14 Message: Logged In: YES user_id=15438 Maybe I shouldn't have closed this. Danny, I'll let you control this ticket. ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 19:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 15:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 14: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-29 01: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 |
From: SourceForge.net <no...@so...> - 2006-09-30 12:58:56
|
Bugs item #1567079, was opened at 2006-09-28 10:23 Message generated for change (Comment added) made by earnie 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: Danny Smith (dannysmith) 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: Earnie Boyd (earnie) Date: 2006-09-30 08:58 Message: 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. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-09-29 13:09 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-09-29 10:14 Message: Logged In: YES user_id=15438 Maybe I shouldn't have closed this. Danny, I'll let you control this ticket. ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 07:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 03:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 02: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 13: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 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-10-22 17:18:15
|
Bugs item #1567079, was opened at 2006-09-28 07:23 Message generated for change (Comment added) made by earnie 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 (deprecated use WSL) Group: Known bugs >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Tim Van Holder (zastai) Assigned to: Danny Smith (dannysmith) 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: Earnie Boyd (earnie) Date: 2012-10-22 10:18 Message: At some point we provided our own implementations for these. AFAICS this issue has been resolved but I don't know when. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-09-30 05:58 Message: 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. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-09-29 10:09 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-09-29 07:14 Message: Logged In: YES user_id=15438 Maybe I shouldn't have closed this. Danny, I'll let you control this ticket. ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-29 04:19 Message: 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). ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2006-09-29 00:39 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Van Holder (zastai) Date: 2006-09-28 23: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 10: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 |