Re: [Mingw-users] Pending new mingwrt and w32api releases
- Date: Sun, 5 Mar 2017 11:31:15 -0600
- From: David Gressett <DGressett@xxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases
>From: Keith Marshall [mailto:keithmarshall@xxxxxxxxxxxxxxxxxxxxx]
>Sent: Saturday, March 04, 2017 4:57 PM
>Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases
>On 02/03/17 00:57, David Gressett wrote:
>>> It's possible that this is some sort of latent bug in the
>>> xsinfo.exe program itself, just as it may be due to some change in
>>> mingwrt or w32api. Could you run xsinfo.exe under GDB, to determine
>>> where it is crashing? Or, build mingwrt and w32api from the
>>> repository, then run a git bisect over the changes since the last
>>> 3.x releases?
>> I know almost nothing about git.
>Well, I'm no expert either. I find git every bit as repulsive as its
>name leads me to expect, (per the OED definition of the British idiom),
>so I don't actually use it. Instead, I rely on the capability afforded
>by mercurial's hg-git extension, and use hg to manage our repositories.
>> My first attempt at gdb on the offending xsinfo.exe didn't turn up
>> very much. It is written in Ada. here is what I got on my only
>> attempt today.
>> [Inferior 1 (process 18324) exited with code 03]
>Eli has already offered some follow-up dialogue on this.
I saw that, and proceeded to work on shrinking xsinfo into
a minimal test case. When I finished, xsinfo had completely
vanished; it is now replaced with CrashDemo.adb, which
has only 5 lines of actual code:
procedure CrashDemo is
It is built with this command line:
gnatmake -g CrashDemo
This produces the same gdb traceback that I got with xsinfo.
>> How tightly bound are the win32api and the mingwrt to each other?
>> would it make sense to try them one at a time?
>No. The two packages are derived from subdirectories of a common git
>repository, and their commits are interleaved. To identify the commit
>which may have caused an adverse change in behaviour, you need to work
>with a clone of the entire repository. Using either "git bisect", or
>"hg bisect", you specify a range of commits to analyse, starting from
>a known "good" point, and progressing to a known "bad" one, and you
>allow the tool to choose, (using a form of binary partitioning of the
>commit range), which particular commits to test. At each cycle, you
>force a rebuild of the offending xsinfo.exe program, using the code
>built and installed from the respective commit. You then run the
>xsinfo.exe program, and use its result to update the bisect state,
>by specifying whether the current commit is "good" or "bad", until
>the partition size has been reduced to just one commit, which should
>be the commit at which the state transitioned from "good" to "bad".
OK. I will see what I can do with this. Can you supply a starting date
for the first point at which the V5 win32api and mingwrt actually
worked in your testing?
- - -
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: