Web lists-archives.com

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




-----BEGIN PGP SIGNED MESSAGE-----
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".

- -- 
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYu0Y7AAoJEMCtNsY0flo/GNcP+wVcG2AaKht0psBabVnBmpaE
XbpwVDj2aiU6C0gNfqxFL62n1SOsB9n+cgMClYT6KmGtMEYuznBLl69Uf+QcFPnb
j1z8wYPbGUKvu9/itXu3qEwn96zr0UgaaZ2FWI+tQ11yflU8xG4/IigLCaVbJpT0
FA5jE03y7xnSI8/kV7ox6MxbkGHl1EDLsOipB9uElKhUSr3tTQq91LWW/8yN5lri
NqEJ/h8ZnDOjJhSRZKR5wZbRI3Cok0GYWHuAz3H7qofJkMX+FLqbQ8kH970gWlRT
/g8nySMDMMkngdvqocroGS52E4Z5ajP/v4dfhSSF8pV1VuV+q1dDTdHZPOKY0BQK
Bodc03Yq+YXZ7HA0z8+dahMM4IIgBeWj2cti0IBSoZOtq906lMYEIdef56WFiviO
mE7U5oPqFqdv1FjSo122JG9zNjTtRtw9+zIpLczRjQgrCmIU+rhOqCH3pDxIyzij
lHI3JNBZAg5HvaeVt7TjvPGeljcQtcjMT1s8mvqGzDimcifV7jb2Xo/6qxiV7RVN
jU1Mzkc/ResgD22pyU9RxP3k8WokkHAVpMdRyxpff0vfgDKnpHU8plAaUeGEiyC5
fr5JnOMFCmjbFczpdD/HMgR+0vErDa/U5M5pkjjj02xImDwoUj+8HyxCZ3HhBmz1
Xi8Fbq/HPxWJ0gRCGTOz
=4Ufj
-----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
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe