Web lists-archives.com

Re: [Mingw-users] Pending new mingwrt and w32api releases

Hash: SHA1

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
Version: GnuPG v2.0.20 (GNU/Linux)


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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe