Web lists-archives.com

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




>From: Keith Marshall [mailto:keithmarshall@xxxxxxxxxxxxxxxxxxxxx] 
>Sent: Saturday, March 04, 2017 4:57 PM
>To: mingw-users@xxxxxxxxxxxxxxxxxxxxx
>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
   Err: exception;
begin
   raise Err;
end CrashDemo;

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
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