#1965 MinGW-Get GUI Beta *Crashing on run*

WSL
closed
Bug
fixed
Unknown
True
2013-05-13
2013-05-03
Melchior
No

After following all the steps to update MinGW-Get to the latest snapshot
mingw-get-0.6-mingw32-hg-20130129-1 any finally get my own PC online for a bit (nearby open WiFi ;^_^) running all the update and upgrade commands...

I try out the new MinGW-Get....

lastrites.exe -- crashes every time at the end of any MinGW-Get executes (update, upgrade, and install tested).

guimain.exe -- Never ran always crashing.. ;;
guistub.exe -- Never ran always crashing.. ;
;, this one use to display the stub.

That's all there is too the crashes I'll be attaching Windows Dr.Watson logs and dumps below. too bad I can't attach multiply files below... lol :(


Windows XP Pro SP3 32bit,
Nvidia GTS 250 512MB (drivers, 314.22 so up-to-date),
MinGW up to date, v4.7.2
TortoiseSVN (v1.7.12.24070)
CodeBlocks (v12.11)(r8629) ^_^

the rest of my system specs can be seen link below (cpu-Z).
http://valid.canardpc.com/show_oc.php?id=2449233

3 Attachments

Discussion

1 2 > >> (Page 1 of 2)
  • Earnie Boyd

    Earnie Boyd - 2013-05-03
    • labels: mingw-get, mingw-get-gui --> mingw-get-gui
    • status: unread --> assigned
    • assigned_to: Keith Marshall
    • Group: OTHER --> INSTALLER
     
  • Melchior

    Melchior - 2013-05-04

    I attached below Dependency Walker reports for all three apps.
    http://www.dependencywalker.com/

    After checking the event logs I found some more info, that the faulting module is

    Faulting app: - faulting module:
    lastrites.exe - msvcrt.dll, version 7.0.2600.5512, fault address 0x00037740.
    guimain.exe - msvcrt.dll, version 7.0.2600.5512, fault address 0x00037740.
    guistub.exe - msvcrt.dll, version 7.0.2600.5512, fault address 0x00037740.


    The application, C:\Dev-MinGW\libexec\mingw-get\guimain.exe, generated an application error
    The error occurred on 05/03/2013 @ 01:41:27.343
    The exception generated was c0000005 at address 77C47740 (msvcrt!strcmp)


    The application, C:\Dev-MinGW\libexec\mingw-get\lastrites.exe, generated an application error
    The error occurred on 05/03/2013 @ 01:44:25.437
    The exception generated was c0000005 at address 77C47740 (msvcrt!strcmp)


    Next I tried running them through the GNU Debugger (gdb):
    but without Debuging symbols for the MinGW-Get-GUI I can only
    provide limited feedback I guess..


    Starting program: C:\Dev-MinGW\libexec\mingw-get\guimain.exe
    [New Thread 3372.0xb64]
    [New Thread 3372.0x234]

    Program received signal SIGSEGV, Segmentation fault.
    0x77c47740 in strcmp () from C:\WINDOWS\system32\msvcrt.dll


    Starting program: C:\Dev-MinGW\libexec\mingw-get\guistub.exe
    [New Thread 2824.0xf64]

    Program received signal SIGSEGV, Segmentation fault.
    0x77c47740 in strcmp () from C:\WINDOWS\system32\msvcrt.dll


    Starting program: C:\Dev-MinGW\libexec\mingw-get\lastrites.exe
    [New Thread 1932.0x88c]

    Program received signal SIGSEGV, Segmentation fault.
    0x77c47740 in strcmp () from C:\WINDOWS\system32\msvcrt.dll

     
    Last edit: Melchior 2013-05-04
  • Keith Marshall

    Keith Marshall - 2013-05-06

    Thanks for following up on this strange bug; unfortunately Dr. Watson logs don't yield much of value, and I can't speak for the dependency walker analysis, because I am not equipped to handle 7zip archives, (my choice, and I will not change it, so please don't ask).

    I can confirm that this isn't a bug in mingw-get; guistub.exe, in particular, is so trivially simple that this just isn't a feasible diagnosis. It may be the result of an inconsistency in some of the libraries with which I've linked it -- or more specifically in either my MinGW start-up code image, or in my MSVCRT.dll import library. Alternatively, and quite probably, it may be that we are tripping over a Microsoft bug, which is specific to WinXP-SP2 and WinXP-SP3; (maybe also WinXP-SP1 -- I don't have access to any host on which to test that).

    It does appear, from the info you've posted, that the crash, when it occurs, is always manifest within MSVCRT.DLL; beyond that, I can also say categorically that:

    • I cannot reproduce any such crash, on a Win7 VM.
    • Neither can I reproduce it on a real Vista host, nor even on an unpatched WinXP VM -- no service packs applied.
    • I can reproduce it on a WinXP-SP2 VM.
    • I have no other reference installations, on which I can test.
    • Very oddly, if I compress all of the executables in question, with UPX, they no longer crash on the WinXP-SP2 VM, (and they continue to run fine on my other test platforms).
    • If I rebuild on the Win7 VM, using published MinGW tools and libraries -- painfully slow, in comparison to my regular Linux cross-build procedure -- the resultant executables no longer crash on my WinXP-SP2 VM, (nor on any other platform mentioned above).

    I'll continue to pursue this, when I've successfully rebuilt my working libraries, (which is another issue -- see the tickets I've recently posted against WSL, if you're interested).

     
  • Melchior

    Melchior - 2013-05-06

    can u handle RAR archives? loi..... I used 7z because they gave me the best compression ie uploading time and file size....
    what Archival programs do you use? that way I can better upload archives you can open. I have added the Dependency Walker reports to this post as un-archived attachments. :D

    if I had an extra Monitor and stuff I could test it on my older Win2k box, its an only 512MB Pentium 3 866Mhz... but its sitting in a corner of my bedroom...(stored)

    if it really is a MS Windows bug that wouldn't surprise me, ooohhh M$ please fix it people still use your WinXP OS.... loi.

    msvcrt!strcmp O_o...?


    ok... I tried out that new wsl_release-candidate package, but the pre-release packages that were available through it were causing issues with the compilation of my own Temperature Converter Program
    (Console App, a C and C++ version ^^)(compiler errors or warnings I don't remember off hand)
    it was originally a simple Fahrenheit to Celsius converter for the CS140-1(HW10.cpp) class I had taken back 2001-2002, I have since expanded it to do all three temperature types ^
    ^ and input validation checks too ^_^ I suppose I could put it up here on SourceForge, I just don't have any Copyright stuff added to it yet not sure about that stuff...

     
    Last edit: Melchior 2013-05-06
  • Keith Marshall

    Keith Marshall - 2013-05-07
    • labels: mingw-get-gui --> mingw-get-gui, WSL start-up code
    • Group: INSTALLER --> WSL
     
  • Keith Marshall

    Keith Marshall - 2013-05-07

    My preferred archive format is the humble UNIX standard tarball, optionally compressed with gzip (*.tar.gz), bzip2 (*.tar.bz2), lzma (*.tar.lzma), or xz (*.tar.xz); best compression is achieved with lzma or xz, both of which use the same lzma algorithm as 7zip.

    If you can't manage any of those (why not?), then I'll accept plain old zip.

    That said, I don't need any additional log files from you, for I've identified the point of failure, as anticipated not within mingw-get itself, but within the new start-up code for WSL:

    GLOB_INLINE int glob_signed( const char *check, const char *magic )
    {
      /* Inline helper function, used exclusively by the glob_registry()
       * function, to confirm that the gl_magic field within a glob_t data
       * structure has been set, to indicate a properly initialised state.
       */
      return (check == magic) ? 0 : (check != NULL) ? strcmp( check, magic ) : 1;
    }
    

    That's called, possibly with "check" uninitialised, specifically to test for that very state; WinXP-Pro-SP2 is crashing, when it a) isn't already an alias for "magic", and b) it isn't simply NULL. IMO, this is categorically a Microsoft bug, but I guess we could work around it by requiring that "check" be an alias for "magic", and ignoring the possibility that it could be a pointer to an alternative copy of a matching signature string.

    In any case, this has now become a WSL issue, so I'm reclassifying it accordingly.

     
    • Melchior

      Melchior - 2013-05-07

      Keith Marshall:
      My preferred archive format is the humble UNIX standard tarball, optionally compressed with gzip (.tar.gz), bzip2 (.tar.bz2), lzma (.tar.lzma), or xz (.tar.xz); best compression is achieved with lzma or xz, both of which use the same lzma algorithm as 7zip.

      Ooh :D Ok ^^ :D that's no problem ^^, I can create xz(lzma) archives with 7zip :D, I believe I can select .tar format with 7zip but to lzma it I may have to run it through 7zup a second time....

      If its alright with you I'll skip the tarball phase and just use xz(lzma) ^_^

      From now on, all further times I will post archives in the xz(lzma) format when bug reporting on MinGW :D :D


      That's called, possibly with "check" uninitialised, specifically to test for that very state; WinXP-Pro-SP2 is crashing, when it a) isn't already an alias for "magic", and b) it isn't simply NULL. IMO, this is categorically a Microsoft bug, but I guess we could work around it by requiring that "check" be an alias for "magic", and ignoring the possibility that it could be a pointer to an alternative copy of a matching signature string.

      In any case, this has now become a WSL issue, so I'm reclassifying it accordingly.

      Oooh ok. Microsoft bug (possible to report it too them?)?

      Outa Net time so till next time I get in (library, so 1.5 hrs/day)


      ps:
      The tarball I have seen it over the years in many of the archives I have downloaded over the years, its like the windows .cab file right? no compression, just used to store files in a single file for better distribution..?

       
  • Earnie Boyd

    Earnie Boyd - 2013-05-07
    • Group: WSL --> INSTALLER
     
  • Earnie Boyd

    Earnie Boyd - 2013-05-07

    Let's leave it as an Installer issue for now. I'll test XP SP3 when I have a few moments.

     
    • Keith Marshall

      Keith Marshall - 2013-05-08

      Let's leave it as an Installer issue for now.

      I can kludge around it in the installer, by setting _CRT_glob = 0, but that just leaves the real source of the problem in WSL, waiting to jump out and bite any number of other projects. I do note that you later changed your mind, and reverted to the WSL classification; this is where it really does need to be fixed.

      On reflection, I think passing a possibly unintialised non-NULL pointer to strcmp() is always going to be unsafe. While a segfault abort on read is rather a draconian action, (after all, we have no intention of modifying memory at that address, and failure to read could be safely handled), it seems that MS-Windows in general, offers no reliable method to check a memory address for readability without raising a segfault. The best solution, I think, is just to require exact pointer aliasing in this case.

       
      • Earnie Boyd

        Earnie Boyd - 2013-05-08

        Yes, I decided you were correct in moving it to WSL. Now we just need a graceful patch.

         
        • Keith Marshall

          Keith Marshall - 2013-05-08

          I'll formulate one tomorrow. It's a one line fix, but on the way to finding it I noticed another loosely related anomaly, (which I initially misidentified as the cause of this problem); I'll include the fix for that too.

           
    • Earnie Boyd

      Earnie Boyd - 2013-05-08

      I tested on SP3, and yes, it fails there as well.

       
  • Earnie Boyd

    Earnie Boyd - 2013-05-07
    • Group: INSTALLER --> WSL
     
  • Keith Marshall

    Keith Marshall - 2013-05-09

    I've attached the promised patch. It removes the circumstances which may cause the segfault, but do note the FIXME I've added in glob.c; this will not affect our start-up code, but it could induce unpredictable behaviour in the (perhaps unlikely) event of a user creating the scenario described.

     
    • Earnie Boyd

      Earnie Boyd - 2013-05-09

      The only comment I have on the patch are the Copyright lines and that is let's be consistent. I prefer to use the - character for consecutive years.

      As to the FIXME, the research I did yesterday on the issue pointed me to use SEH which isn't doable for WIN32 gcc. The patent for SEH was only given for WIN32 and doesn't extend to WIN64 so Kai was able to implement it for WIN64 gcc. The issue continues though that SEH is a configurable option for the build.

       
      • Keith Marshall

        Keith Marshall - 2013-05-09

        The only comment I have on the patch are the Copyright lines and that is let's be consistent. I prefer to use the - character for consecutive years.

        Even if the range spans only two consecutive years? Not that it matters to me, either way, as long as each range is truly continuous.

        As to the FIXME, the research I did yesterday on the issue pointed me to use SEH which isn't doable for WIN32 gcc. The patent for SEH was only given for WIN32...

        Does this mean that we can't use AddVectoredExceptionHandler() and friends, to implement a sigaction()-like alternative? If so, then we'll just have to live with the limitations outlined in the FIXME, until the patent expires, (which should be okay in 99.9% of use cases anyway). How do Cygwin get around this, to implement sigaction() on WIN32?

         
  • Keith Marshall

    Keith Marshall - 2013-05-09
    • Patch attached: False --> True
     
  • Keith Marshall

    Keith Marshall - 2013-05-09
     
  • Keith Marshall

    Keith Marshall - 2013-05-09

    Updated patch attached, with reformatted copyright notices, as requested.

     
  • Earnie Boyd

    Earnie Boyd - 2013-05-09
    • Resolution: none --> accepted
     
  • Earnie Boyd

    Earnie Boyd - 2013-05-09

    Looks good to me.

    OT rant:
    I hate those GD big file icons.

     
    • Melchior

      Melchior - 2013-05-10

      GD big file icons??

      as soon as a new compile/package is up I'll download it and try it out ^^...
      now if I could only remember where they Beta downloads for the MinGW-Get are located lol..;
      ;

       
      Last edit: Melchior 2013-05-10
      • Earnie Boyd

        Earnie Boyd - 2013-05-10

        now if I could only remember where they Beta downloads for the MinGW-Get are located lol..;;

        Simply remember the author of it.

         
1 2 > >> (Page 1 of 2)

Log in to post a comment.