#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 3 > >> (Page 1 of 3)
  • 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.

     
1 2 3 > >> (Page 1 of 3)