Re: [Mingw-users] Pending new mingwrt and w32api releases
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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".
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
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: