[Mingw-users] Pending new mingwrt and w32api releases

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,

Almost two weeks ago, I invited you to test pre-release snapshots of the
proposed version 5.0 releases of these two package sets. Vadim Zeitlin has kindly done so, in conjunction with his builds of wxWidgets, and has
identified one minor issue, (which arises due to an upstream GCC bug; I
have identified a workaround, to be included in the final release).

Since I posted the snapshots, the download statistics, as reported by SF,
have been rather disappointing. I would like to get these two package
sets formally released by the end of February, and I'm interpreting the
general apathy, and absence of feed back, as tacit approval for the code
base, as it currently stands. If you have any concerns about this code,
and its suitability for formal release, you had best act quickly to let
me know.

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

iQIcBAEBAgAGBQJYsDn8AAoJEMCtNsY0flo/kFMP/ibuSVb7CSZJTv4pFaxG+AWo
9ZY/pAmb1Cw+vX7E7v/r6JlXwL/BYpaVIY6FE05T7oZLy/uo84F4h3NN6gKXh62P
dkHTmesT3Z2cyLDzX2tvvZnWctl9tpFGlY5LfngdNAazoj4n9zPw4Y6UsVjdUQqW
yFOHcgkUf/gzdQdtbxkWMAY+nErGQNxEqP9qEH6ZsoU2OudW+2b3p6/pgsDCnLHJ
P+aD/Z8+h2syhvMspFYtVd0reHMR8kiGpCwPq5RVMgl7LLuil8h59sSrnchc8avp
Oty1DarohbOIeB9C0pvpQuppZ9v+KqIZUFuasVy29AOmyvwU6GNWWsQDMMVJw0lj
tYi/tPHIAP8d5tp8v+VQu70f0BaLFM5ai91V7uYfI3qXWtL8A+zddIlZZx9ocFIg
Lq4Oenb8Q0DPe106Akn40GfKm4m+oWIw1gBWvDGGcdTKY3OSehvUzv2gn64OHY1e
dcO7f/MoC0TUYSX+UumMKIQKnnyT194ZEssziQnTOyTskCUBB2VQs0+IGRI40Y+Q
xuKTYwmEVrJ7DEBO1Kqe/g2ZcCZYm/J4JHplnYgCBDSV1FnBysSDYlmqSsh36L1O
5Xx9M3WV5lbclxiWACgtVCkdEZC90crAK3SRXkYVhghD19NNu6FaYwuyYyt6Yxav
RUsjuWA9/b77nRFo+nqa
=bqxp
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Lorin K]

Dear Keith,

I must have missed the announcement.

I haven't compiled on windows lately (I once compile Amarok long ago), thus
I ask:

Are there some (manual) test cases you'd recommend?


If yes, should I simply install mingw with the latest installer and then
manually replace all files from
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/mingwrt-5.0/
and
https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0/
and then compile something of which I know that it used to work
(suggestions)?

On 24 February 2017 at 14:49, Keith Marshall <

Post by Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folks,
Almost two weeks ago, I invited you to test pre-release snapshots of the
proposed version 5.0 releases of these two package sets. Vadim Zeitlin
has kindly done so, in conjunction with his builds of wxWidgets, and has
identified one minor issue, (which arises due to an upstream GCC bug; I
have identified a workaround, to be included in the final release).
Since I posted the snapshots, the download statistics, as reported by SF,
have been rather disappointing. I would like to get these two package
sets formally released by the end of February, and I'm interpreting the
general apathy, and absence of feed back, as tacit approval for the code
base, as it currently stands. If you have any concerns about this code,
and its suitability for formal release, you had best act quickly to let
me know.
- --
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)
iQIcBAEBAgAGBQJYsDn8AAoJEMCtNsY0flo/kFMP/ibuSVb7CSZJTv4pFaxG+AWo
9ZY/pAmb1Cw+vX7E7v/r6JlXwL/BYpaVIY6FE05T7oZLy/uo84F4h3NN6gKXh62P
dkHTmesT3Z2cyLDzX2tvvZnWctl9tpFGlY5LfngdNAazoj4n9zPw4Y6UsVjdUQqW
yFOHcgkUf/gzdQdtbxkWMAY+nErGQNxEqP9qEH6ZsoU2OudW+2b3p6/pgsDCnLHJ
P+aD/Z8+h2syhvMspFYtVd0reHMR8kiGpCwPq5RVMgl7LLuil8h59sSrnchc8avp
Oty1DarohbOIeB9C0pvpQuppZ9v+KqIZUFuasVy29AOmyvwU6GNWWsQDMMVJw0lj
tYi/tPHIAP8d5tp8v+VQu70f0BaLFM5ai91V7uYfI3qXWtL8A+zddIlZZx9ocFIg
Lq4Oenb8Q0DPe106Akn40GfKm4m+oWIw1gBWvDGGcdTKY3OSehvUzv2gn64OHY1e
dcO7f/MoC0TUYSX+UumMKIQKnnyT194ZEssziQnTOyTskCUBB2VQs0+IGRI40Y+Q
xuKTYwmEVrJ7DEBO1Kqe/g2ZcCZYm/J4JHplnYgCBDSV1FnBysSDYlmqSsh36L1O
5Xx9M3WV5lbclxiWACgtVCkdEZC90crAK3SRXkYVhghD19NNu6FaYwuyYyt6Yxav
RUsjuWA9/b77nRFo+nqa
=bqxp
-----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
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.
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/mingw-users

[David Gressett]

________________________________________

Subject: [Mingw-users] Pending new mingwrt and w32api releases
Folks,
Almost two weeks ago, I invited you to test pre-release snapshots of the
proposed version 5.0 releases of these two package sets. Vadim Zeitlin has kindly done so, in conjunction with his builds of wxWidgets, and has
identified one minor issue, (which arises due to an upstream GCC bug; I
have identified a workaround, to be included in the final release).

I am working on native Windows builds of gcc and have
successfully built 5.3.0, 5.4.0, and 6.3.0, with my
MinGW installation using the current mingwrt and w32api.

After successfully building 6.3.0, I installed 6.3.0 to replace
the gcc 5.3.0 installed by the MinGW installer and successfully
built 6.3.0 again.

I then downloaded and installed the proposed version 5 releases
of mingwrt and w32api and tried the gcc 6.3.0 build again

It failed, with the crash of a program that is part of the Ada build
system: xsinfo.exe, located in my build tree at

gcc-6.3.0-mingw32/gcc/ada/bldtools/sinfo/xsinfo.exe

xsinfo almost completed successfully; Here are the last few
lines that it displayed in my msys window:

"Check for missing functions in body
OK

Check Set procedures in body
OK

Check for missing set procedures in body
OK

All tests completed successfully, no errors detected

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

The "unusual way" line also appeared in a Windows popup error message box.
I will supply more information later as I do more detective work to try to
find the cause of the failure.






------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by David Gressett
I then downloaded and installed the proposed version 5 releases
of mingwrt and w32api and tried the gcc 6.3.0 build again

Okay, thanks.

Post by David Gressett
It failed, with the crash of a program that is part of the Ada
build system: xsinfo.exe, located in my build tree at
gcc-6.3.0-mingw32/gcc/ada/bldtools/sinfo/xsinfo.exe
xsinfo almost completed successfully; Here are the last few
"Check for missing functions in body
OK
Check Set procedures in body
OK
Check for missing set procedures in body
OK
All tests completed successfully, no errors detected

So, it appears that it may have reached the end of it's main()
function, then failed in the termination code.

Post by David Gressett
This application has requested the Runtime to terminate it in
an unusual way. Please contact the application's support team
for more information."

That's got to be one of the least useful error messages, ever.

Post by David Gressett
The "unusual way" line also appeared in a Windows popup error
message box. I will supply more information later as I do more
detective work to try to find the cause of the failure.

Did that popup message box not report a status code? Knowing
that might have been helpful. 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?

If you can do this, I'll hold off on the release of 5.0 for a
couple of weeks, until we can glean some useful information
about this crash.

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

iQIcBAEBAgAGBQJYteqqAAoJEMCtNsY0flo/6O4P/RcNkv8LYRgqu2wstjY/d/6A
zAgHJ8iXJyxQE3Dv8H8vZGUS9HgmWH8CDgxleCesJ9coSRWlltZirfQgUkmOZ2EF
0gZo1YZDl2MJTYts1o51S/5Szlq/b2d7yEGqqKPl6rloxU2x7HwrytywgK0GOhRe
dp+bTGGd1UdK383nB6vZ9N86myGQgcQ397LQUewp15covMionukvqJvq5iAWiqkY
gUm/T5dRwdwvlphEwe/9YZpo++rxsBSuKYfPOkIEkbu6SLtoxmTeIiGr7gbYsTbq
YEL4iw6u5LmAm85G3qNQDQxGiN0Pu5s9CaI/u+Lf8wij2yiTRND8hrEYk34R6XGt
4kLHpybkaFdIZtWm496M6O3YBFbllKjq11EJcJV9MLKuS/hbcp4/wGoe3UDqC0hQ
IeXyHICK1BT+p1AiuYTM9UiOMJDhUErEskz7935j7fEHGckWdt5gNucCE99il3pn
UTTxd/r6P0zKDJEclrD05dxhKxEnfsa+eytGBGNSShhvyuSlbOWPKODjFWTyIHVZ
lxnZoHpdgFH7IVstKgvsDCOv2SkAU1oTasZwSOr0EvkKzb/lwVK8jw81YRKuVK2w
1usqefShTJllMpUurCrcfDRjAl5bdtz9rqNtODtw6AwLjULOhLemuVw1k1Xicbzg
vyJGbVg0YHibvHdGYnTB
=+AlD
-----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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Tuesday, February 28, 2017 3:25 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

... snip ...

It failed, with the crash of a program that is part of the Ada
build system: xsinfo.exe, located in my build tree at
gcc-6.3.0-mingw32/gcc/ada/bldtools/sinfo/xsinfo.exe
xsinfo almost completed successfully; Here are the last few
"Check for missing functions in body

... snip ...

All tests completed successfully, no errors detected
So, it appears that it may have reached the end of it's main()
function, then failed in the termination code.

Post by David Gressett
This application has requested the Runtime to terminate it in
an unusual way. Please contact the application's support team
for more information."

That's got to be one of the least useful error messages, ever.

Agreed

Post by David Gressett
The "unusual way" line also appeared in a Windows popup error
message box. I will supply more information later as I do more
detective work to try to find the cause of the failure.

Did that popup message box not report a status code? Knowing
that might have been helpful.

There was no code.

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. 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. I will resume tomorrow:

$ gdb xsinfo
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\build_gcc-6.3.0_mingw-pkg\workspace\build3\gcc-6.3.0-mingw32\gcc\ada\bldtools\sinfo\xsinfo.exe...done.
(gdb) start
Temporary breakpoint 1 at 0x41656f
Starting program: c:\build_gcc-6.3.0_mingw-pkg\workspace\build3\gcc-6.3.0-mingw32\gcc\ada\bldtools\sinfo/xsinfo.exe
[New Thread 18324.0x5ff4]
[New Thread 18324.0x3d6c]
[New Thread 18324.0x769c]
[New Thread 18324.0x5f18]

Temporary breakpoint 1, 0x0041656f in _ada_xsinfo ()
(gdb) n
Single stepping until exit from function _ada_xsinfo,
which has no line number information.

Check for field name consistency
OK

Check for function consistency
OK

Check for missing functions
OK

Check for set procedure consistency
OK

Check for missing set procedures
OK

Check pragma Inlines are all for existing subprograms
OK

Check no pragma Inlines were omitted
OK

Check references in functions in body
OK

Check for missing functions in body
OK

Check Set procedures in body
OK

Check for missing set procedures in body
OK

All tests completed successfully, no errors detected

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
[Inferior 1 (process 18324) exited with code 03]
(gdb)
The program is not being run.
(gdb)

If you can do this, I'll hold off on the release of 5.0 for a
couple of weeks, until we can glean some useful information
about this crash.

How tightly bound are the win32api and the mingwrt to each other?
would it make sense to try them one at a time?

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Eli Zaretskii]

Date: Wed, 1 Mar 2017 18:57:18 -0600
Check for missing set procedures in body
OK
All tests completed successfully, no errors detected
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
[Inferior 1 (process 18324) exited with code 03]

This means the program called 'abort'. So please do this:

(gdb) break abort

then run the program as you did under GDB, and whe the breakpoint
breaks, type

(gdb) backtrace

and post here the results.

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Wednesday, March 01, 2017 9:37 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

Date: Wed, 1 Mar 2017 18:57:18 -0600
Check for missing set procedures in body
OK
All tests completed successfully, no errors detected
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
[Inferior 1 (process 18324) exited with code 03]

(gdb) break abort
then run the program as you did under GDB, and whe the breakpoint
breaks, type
(gdb) backtrace
and post here the results.

$ gdb xsinfo
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\build_gcc-6.3.0_mingw-pkg\workspace\build3\gcc-6.3.0-mingw32\gcc\ada\bldtools\sinfo\xsinfo.exe...done.
(gdb) break abort
Breakpoint 1 at 0x46c038
(gdb) run
Starting program: c:\build_gcc-6.3.0_mingw-pkg\workspace\build3\gcc-6.3.0-mingw32\gcc\ada\bldtools\sinfo/xsinfo.exe
[New Thread 5832.0x83e0]
[New Thread 5832.0x4688]
[New Thread 5832.0x6178]
[New Thread 5832.0x8294]

Check for field name consistency
OK

Check for function consistency
OK

Check for missing functions
OK

Check for set procedure consistency
OK

Check for missing set procedures
OK

Check pragma Inlines are all for existing subprograms
OK

Check no pragma Inlines were omitted
OK

Check references in functions in body
OK

Check for missing functions in body
OK

Check Set procedures in body
OK

Check for missing set procedures in body
OK

All tests completed successfully, no errors detected

Breakpoint 1, 0x0046c038 in abort ()
(gdb) backtrace
#0 0x0046c038 in abort ()
#1 0x00469c34 in uw_init_context_1 (context=***@entry=0x25df2c0, outer_cfa=***@entry=0x25df4a0,
outer_ra=0x41eb8f <ada.exceptions.exception_propagation.propagate_gcc_exception+16>) at ../../../../src/gcc-6.3.0/libgcc/unwind-dw2.c:1563
#2 0x0046a25e in _Unwind_RaiseException (exc=0x2696620) at ../../../../src/gcc-6.3.0/libgcc/unwind.inc:88
#3 0x004659d5 in __gnat_Unwind_RaiseException (e=***@entry=0x2696620) at raise-gcc.c:1374
#4 0x0041eb8f in ada.exceptions.exception_propagation.propagate_gcc_exception (gcc_exception=0x2696620) at a-exexpr.adb:321
#5 0x0041ebd1 in ada.exceptions.exception_propagation.propagate_exception (excep=***@entry=0x2696650) at a-exexpr.adb:353
#6 0x0041f7e7 in ada.exceptions.complete_and_propagate_occurrence (x=***@entry=0x2696650) at a-except.adb:937
#7 0x0041f847 in <__gnat_raise_exception> (e=0x47504c <done.4057>, message=...) at a-except.adb:978
#8 0x0041c3ad in xsinfo__getline.4575 ()
#9 0x00419281 in _ada_xsinfo ()
(gdb)

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Eli Zaretskii]

Date: Thu, 2 Mar 2017 11:46:18 -0600
Breakpoint 1, 0x0046c038 in abort ()
(gdb) backtrace
#0 0x0046c038 in abort ()
outer_ra=0x41eb8f <ada.exceptions.exception_propagation.propagate_gcc_exception+16>) at ../../../../src/gcc-6.3.0/libgcc/unwind-dw2.c:1563
#2 0x0046a25e in _Unwind_RaiseException (exc=0x2696620) at ../../../../src/gcc-6.3.0/libgcc/unwind.inc:88
#4 0x0041eb8f in ada.exceptions.exception_propagation.propagate_gcc_exception (gcc_exception=0x2696620) at a-exexpr.adb:321
#7 0x0041f847 in <__gnat_raise_exception> (e=0x47504c <done.4057>, message=...) at a-except.adb:978
#8 0x0041c3ad in xsinfo__getline.4575 ()
#9 0x00419281 in _ada_xsinfo ()
(gdb)

I guess the question now becomes what's with that Ada exception?

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by David Gressett

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.

Post by David Gressett
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.

Post by David Gressett
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Saturday, March 04, 2017 4:57 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

Post by David Gressett

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.

Post by David Gressett
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.

Post by David Gressett
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Eli Zaretskii]

Date: Sun, 5 Mar 2017 11:31:15 -0600

Post by Keith Marshall
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
procedure CrashDemo is
Err: exception;
begin
raise Err;
end CrashDemo;
gnatmake -g CrashDemo
This produces the same gdb traceback that I got with xsinfo.

Ada is not even a read-only language for me, but doesn't the above
raise an exception that has no handler? If so, the fact that the
runtime calls 'abort' is expected, I think, as that's what should
happen when there's an unhandled exception.

------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Sunday, March 05, 2017 1:58 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

Date: Sun, 5 Mar 2017 11:31:15 -0600

Post by Keith Marshall
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
procedure CrashDemo is
Err: exception;
begin
raise Err;
end CrashDemo;
gnatmake -g CrashDemo
This produces the same gdb traceback that I got with xsinfo.

Ada is not even a read-only language for me, but doesn't the above
raise an exception that has no handler? If so, the fact that the
runtime calls 'abort' is expected, I think, as that's what should
happen when there's an unhandled exception.

It does indeed raise an unhandled exception, but such exceptions
are handled inside the Ada runtime. When crashdemo.exe is built
with the current V3 system libraries, it runs with no crash and exits
with as message saying that it raised CRASHDEMO.ERR. When run
from GDB with a breakpoint set for abort, it runs to completion
and the break does not happen.

When it is compiled with the V5 prerelease system libraries, it crashes
inside the Ada runtime library before it can produce the CRASHDEMO.ERR
message. When run from GDB with a breakpoint set for abort, the
break does happen.

I have done all of this with both the current MinGW gcc 5.3.0 and with
my experimental gcc 6.3.0, and get the same results with both.


------------------------------------------------------------------------------
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-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by David Gressett
It does indeed raise an unhandled exception, but such exceptions
are handled inside the Ada runtime.

So ... the Ada runtime establishes its own default handler for
otherwise unhandled exceptions ...

Post by David Gressett
When crashdemo.exe is built with the current V3 system libraries, it
runs with no crash and exits with as message saying that it raised
CRASHDEMO.ERR. When run from GDB with a breakpoint set for abort, it
runs to completion and the break does not happen.

... and that default handler gets control, as expected, for Ada
applications which are built against mingwrt/w32api-3.x, but ...

Post by David Gressett
When it is compiled with the V5 prerelease system libraries, it crashes
inside the Ada runtime library before it can produce the CRASHDEMO.ERR
message. When run from GDB with a breakpoint set for abort, the
break does happen.

... it doesn't get control, for the same applications, when they
are built against a mingwrt/w32api-5.0 preview. Apparently ...

Post by David Gressett
I have done all of this with both the current MinGW gcc 5.3.0 and with
my experimental gcc 6.3.0, and get the same results with both.

... there is some change, introduced in mingwrt/w32api-5.0, which
interferes with the implementation of Ada's default exception
handler; we need to understand that interaction, if we are to have
any chance of resolving this issue.

FWIW, I've attached a copy of the commit log from my working clone
of the mingwrt/w32api code. Note that the changeset numbers shown
are local to this clone, (and the hashes are mercurial's, which may
not match git hashes); V5 development begins at changeset 253, and
follows the leftmost branch of the graph, thereafter. (Prior to
this, that leftmost branch represents V3 development, which moves
one branch to the right, after the V5 branch point). Also note
that changeset 385, (tagged default/5.0-active, and qparent), ends
the public line of V5 development; later changesets relate to my
local patch queue, and are not included in the V5 preview.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I ... proceeded to work on shrinking xsinfo into a minimal test case.
When I finished, xsinfo had completely vanished; it is now replaced
procedure CrashDemo is
Err: exception;
begin
raise Err;
end CrashDemo;
gnatmake -g CrashDemo
This produces the same gdb traceback that I got with xsinfo.

FTR, I tried to reproduce this, in my cross-compiler environment:

$ mingw32-gnatmake --version
GNATMAKE 5.3.0
Copyright (C) 1995-2015, Free Software Foundation, Inc.
...

$ cat crashdemo.adb
procedure CrashDemo is
Err: exception;
begin
raise Err;
end CrashDemo;

$ mingw32-gnatmake -g crashdemo
mingw32-gcc -c -g crashdemo.adb
mingw32-gnatbind -x crashdemo.ali
mingw32-gnatlink crashdemo.ali -g

$ ./crashdemo.exe
raised CRASHDEMO.ERR : crashdemo.adb:4

which I think is what you expect. Do note that this is with the tip
revision of mingwrt/w32api-5.0, (including my local patches, which are
unlikely to have any bearing on the issue), running under wine, (which
is masquerading as Win7, and is usually less forgiving than real Win7),
with statically linked Ada runtime, (IIRC, you were able to produce a
DLL variant of that, but I never succeeded in doing so). IOW, I can't
reproduce your crash, so I can't debug it; is it possible that the
issue lies within your dynamically linked Ada runtime?

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

iQIcBAEBAgAGBQJYvdG9AAoJEMCtNsY0flo/zKAQALBeXXx1WoxhemPaVRtB8uNM
s2iB+tF6ibSIWmGJBDanxG+egZO29XP1DUdLXHytb4XMDBPoWsKznE8k6kCBRNNY
3FjzKuHs4B1lFeBqAl59irpbtE1LjJyZRLhrM1EBHWMm8w+j+N8yQb6GWf1zzYzV
g9P6dIS3WrrYAw4qS1IZW1XQo0iLGtOFeNpwcNUeToGr0wP3pCl5EpvjOtiPkgfj
RMGGrmVe5AN8fCF0JeMdHLc57N9J1oEzrG+Xi7XUgIEvV/5ZtT4B6Ora2VZ+nIDp
Vp0HnypY6g9qdpWy968cVuaNN5BITzgMtxDm1oCdgx8r+dyGnaAfZRGEucl8lBH6
w8PMsGR63BXF8a4qn1uYMtuiZCYDxB5dfNXV4y39ru0zdp0hC48niYCLbbM/USLQ
7fLR50gIJaM7R5xE+fsv399vPD/E1lrcXzNfbanvroUxM3qA8p3QlMCf3TeT1grF
jEX2Max0G3WLHbdESq+GHN2IYb+eRUKYR+S/gP417vuo7GsJ4DI3h/oW+f4SPokj
WuD8gNd4Eq4wkc7A1Fb4LdagxcEG+65pd7AJ3DjZtIIF/KOdv0KuEaDBNqhtVSGV
Or6t5Ul2TrDa2NBFjSxcB0/R9zyNtoGtoEM8ULb961jfGXFdFY51Fo9w7E8ZAoKz
GiyA9NFV6vvF0kBqlv81
=kZWf
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Monday, March 06, 2017 3:17 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

I ... proceeded to work on shrinking xsinfo into a minimal test case.
When I finished, xsinfo had completely vanished; it is now replaced
procedure CrashDemo is

... snip ...

This produces the same gdb traceback that I got with xsinfo.

$ mingw32-gnatmake --version
GNATMAKE 5.3.0
Copyright (C) 1995-2015, Free Software Foundation, Inc.

... snip ...

$ ./crashdemo.exe
raised CRASHDEMO.ERR : crashdemo.adb:4
which I think is what you expect. Do note that this is with the tip
revision of mingwrt/w32api-5.0, (including my local patches, which are
unlikely to have any bearing on the issue), running under wine, (which
is masquerading as Win7, and is usually less forgiving than real Win7),
with statically linked Ada runtime, (IIRC, you were able to produce a
DLL variant of that, but I never succeeded in doing so). IOW, I can't
reproduce your crash, so I can't debug it; is it possible that the
issue lies within your dynamically linked Ada runtime?

I did a quick test by making a copy of my MinGW directory tree from
which both gnat dlls had been deleted and renamed it to MinGW.

The rebuild of CrashDemo.adb produced a crashdemo.exe which
was exactly the same size as the previous one and behaved the
same, so it appears that the gnat dlls are not used and the static
Ada runtime is linked by default.

I did do some more debugging, comparing two copies of
crashdemo run by gdb side-by side. Both were compiled with
my experimental gcc 6.3.0, which is installed with gcc runtime
libraries not stripped, but one with the V3 mingwrt/w32api
and the other built with the V5 mingwrt/w32api . The V5
crashdemo has libmingwex-0.dll copied into thedirectory
so that it will run when the main MinGW is set up with the
current V3.

I stepped through both of them one step at a time
in parallel. I found that the paths taken through the runtime
handling the exception diverge well before the crash happens
in the V5 crashdemo. The divergence occurs not in an Ada
routine, but in one written in C:

src/gcc-6.3.0/libgcc/unwind-dw2-fde.c

The divergence occurs in the very last procedure in
the file, _Unwind_Find_FDE, which starts at line 998.
The divergence starts at the very first executable lines
(1004 and 1005). I didn't get a screen capture of the displays;
I will do that when I try it again.

998 const fde *
999 _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
1000 {
1001 struct object *ob;
1002 const fde *f = NULL;
1003
1004 init_object_mutex_once ();
1005 __gthread_mutex_lock (&object_mutex);
1006
1007 /* Linear search through the classified objects, to find the one
1008 containing the pc. Note that pc_begin is sorted descending, and
1009 we expect objects to be non-overlapping. */

FYI, the patch needed to get the gnat dlls to build is very simple. This is
the gcc 5.3.0 version, but it is very nearly the same thing for gcc 5.4.0
and gcc 6.3.0; the main difference is that the line numbers are different.
This produces only one extra gnat tool, gnatdll.exe, which is needed to
make dlls that are written in Ada.

diff -pNaur gcc-5.3.0-current/gnattools/Makefile.in gcc-5.3.0-working/gnattools/Makefile.in
--- gcc-5.3.0-current/gnattools/Makefile.in 2014-02-23 10:30:11 -0600
+++ gcc-5.3.0-working/gnattools/Makefile.in 2015-12-27 17:21:45 -0600
@@ -193,7 +193,7 @@ gnattools-native: $(GCC_DIR)/stamp-tools
../../gnatmake$(exeext) ../../gnatlink$(exeext)
# gnattools2
$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
- $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
+ $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS)

# gnatmake/link can be built with recent gnatmake/link if they are available.
# This is especially convenient for building cross tools or for rebuilding
@@ -205,7 +205,7 @@ regnattools: $(GCC_DIR)/stamp-gnatlib-rt
gnatmake-re gnatlink-re
# gnattools2
$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
- $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
+ $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS)

gnattools-cross: $(GCC_DIR)/stamp-tools
# gnattools1-re
@@ -214,7 +214,7 @@ gnattools-cross: $(GCC_DIR)/stamp-tools
gnatmake-re gnatlink-re
# gnattools2
$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
- $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools
+ $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools $(EXTRA_GNATTOOLS)
# Rename cross tools to where the GCC makefile wants them when
# installing. FIXME: installation should be done elsewhere.
if [ -f $(GCC_DIR)/gnatbind$(exeext) ] ; then \






------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Chris Johns]

Post by David Gressett
I stepped through both of them one step at a time
in parallel. I found that the paths taken through the runtime
handling the exception diverge well before the crash happens
in the V5 crashdemo. The divergence occurs not in an Ada
src/gcc-6.3.0/libgcc/unwind-dw2-fde.c
The divergence occurs in the very last procedure in
the file, _Unwind_Find_FDE, which starts at line 998.
The divergence starts at the very first executable lines
(1004 and 1005). I didn't get a screen capture of the displays;
I will do that when I try it again.
998 const fde *
999 _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
1000 {
1001 struct object *ob;
1002 const fde *f = NULL;
1003
1004 init_object_mutex_once ();
1005 __gthread_mutex_lock (&object_mutex);
1006
1007 /* Linear search through the classified objects, to find the one
1008 containing the pc. Note that pc_begin is sorted descending, and
1009 we expect objects to be non-overlapping. */

This is the runtime support in GCC to manage exceptions and this looks
like the DWARF, ie ELF support. It uses the runtime and language
specific hooks to locate the information needed to handle the exception.
Failures here resulting in an abort tend to mean you have information
missing in your executable that is needed or there may be a change in
the data format or the wrong data format.

I did not know Windows executables used dwarf based information for
exceptions?

Chris

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Eli Zaretskii]

Date: Tue, 7 Mar 2017 12:20:13 +1100

Post by David Gressett
998 const fde *
999 _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
1000 {
1001 struct object *ob;
1002 const fde *f = NULL;
1003
1004 init_object_mutex_once ();
1005 __gthread_mutex_lock (&object_mutex);
1006
1007 /* Linear search through the classified objects, to find the one
1008 containing the pc. Note that pc_begin is sorted descending, and
1009 we expect objects to be non-overlapping. */

This is the runtime support in GCC to manage exceptions and this looks
like the DWARF, ie ELF support.

MinGW GCC produces DWARF debug info inside a COFF-PE executable, so
DWARF is used with MinGW even though ELF isn't.

I did not know Windows executables used dwarf based information for
exceptions?

DWARF is used by MinGW since long ago.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The V5 crashdemo has libmingwex-0.dll copied into the directory

Ah! I didn't link my test against libmingwex.dll.a, so I was using
static libmingwex.a; thus, without libmingwex.dll.a installed:

$ mingw32-gnatmake --version
GNATMAKE 5.3.0
Copyright (C) 1995-2015, Free Software Foundation, Inc.
...

$ cat crashdemo.adb
procedure CrashDemo is
Err: exception;
begin
raise Err;
end CrashDemo;

$ mingw32-gnatmake -g crashdemo
mingw32-gcc -c -g crashdemo.adb
mingw32-gnatbind -x crashdemo.ali
mingw32-gnatlink crashdemo.ali -g

$ mingw32-ldd crashdemo.exe
crashdemo.exe
+- ADVAPI32.DLL
+- KERNEL32.dll
+- msvcrt.dll
+- msvcrt.dll
+- SHELL32.DLL

$ ./crashdemo.exe
raised CRASHDEMO.ERR : crashdemo.adb:4

DTRT, but *with* libmingwex.dll.a (and/or libmingwex-0.dll) installed:

$ cp ../mingwrt/libmingwex.dll.a ~/mingw32/lib

$ rm b-*; rm *.o *.exe *.ali

$ mingw32-gnatmake -g crashdemo
mingw32-gcc -c -g crashdemo.adb
mingw32-gnatbind -x crashdemo.ali
mingw32-gnatlink crashdemo.ali -g

$ mingw32-ldd crashdemo.exe
crashdemo.exe
+- ADVAPI32.DLL
+- KERNEL32.dll
+- libmingwex-0.dll
+- msvcrt.dll
+- msvcrt.dll
+- SHELL32.DLL

$ ln ../mingwrt/libmingwex-0.dll .

$ ./crashdemo.exe
abnormal program termination

exhibits wine's report of similar abnormal termination to that which
you have seen. It appears that dynamic linking of libmingwex may not
be a universally viable option, just yet.

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

iQIcBAEBAgAGBQJYvnvgAAoJEMCtNsY0flo/1gYP/ixKYObRY1cWy0271fJ4QiGw
mwgsfTu2r5TwEJNUt77J44wIbG88hrHG1yaRtn4qyELT5QwGD3Faeuwn1aW/yLyh
uxPuI7GkgJyUd1Xyd6yTCK3+JzVFVur25zwBg9gdPdrqUoKqENPa3gfjmlZGLdp6
y3cNuLSvblIrqsJsNCjlwyhPzYzURht6vfPeBG68BzwnKOQ6c23OYjjwfClUWzYd
/r6+gL3yH/sEc0wlWia1uZ51WSoXSjYgjTglrQ+D4kqFtxmSTWefRGH1nho4OwMn
W0/xmtq5XOBoh7+2sT1uK87CbA7zAn+oiQ4UzlqlUPwod5vgu37a7URpRXs81F9w
7JjQSplGJUxZtAtAc6xRG6rnfwzOfKGuzVTxAxfkWud32TioudmZ87GCKibuJSIQ
fwehEikav6ri9AHbQi8sr+5BcgYpAgTplxmk/DBsO+2010/SDpkk4kdPRpocTgI2
TP//t2bjLBWd+nTgJ27C5s7pDnNFW4SbnWktcs+2Vs6EBG5DUuQDIhIoJILqg8j+
AyMc3zeoUS/KrRJ8SMaaCw4tFrFZWb4wxgy4nZ18erF1hLt+Tx+uQ90Lo+65hnKG
V66n2betHcreY0NWbp34/XIhUNS8LJTevpw2x82nJqYCizFlBGaP8wfq7mV4qYvW
nB9saC1f7V4stP4hSRdB
=7ZxW
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Keith Marshall
...
$ mingw32-ldd crashdemo.exe
crashdemo.exe
+- ADVAPI32.DLL
+- KERNEL32.dll
+- libmingwex-0.dll
+- msvcrt.dll
+- msvcrt.dll
+- SHELL32.DLL
$ ln ../mingwrt/libmingwex-0.dll .

After the latter command, if I rerun the former I see:

$ mingw32-ldd crashdemo.exe
crashdemo.exe
+- ADVAPI32.DLL
+- KERNEL32.dll
+- libmingwex-0.dll
| +- msvcrt.dll
| +- msvcrt.dll
| +- ADVAPI32.DLL
| +- KERNEL32.dll
| +- libgcc_s_dw2-1.dll
+- msvcrt.dll
+- msvcrt.dll
+- SHELL32.DLL

Note the (likely unnecessary) dependency on libgcc_s_dw2-1.dll, which
we already know to be critically bug ridden w.r.t. termination; cf.
https://sourceforge.net/p/mingw/mailman/mingw-users/thread/514C8040.7000207%40gmail.com/#msg30633081

If I rebuild libmingwex-0.dll, adding -static-libgcc to eliminate the
dependency on the libgcc_s_dw2-1.dll turd, and then rebuild your test
case, its dependencies become:

$ $ mingw32-ldd crashdemo.exe
crashdemo.exe
+- ADVAPI32.DLL
+- KERNEL32.dll
+- libmingwex-0.dll
| +- msvcrt.dll
| +- msvcrt.dll
| +- ADVAPI32.DLL
| +- KERNEL32.dll
+- msvcrt.dll
+- msvcrt.dll
+- SHELL32.DLL

Post by Keith Marshall
$ ./crashdemo.exe
abnormal program termination

I now see normal behaviour restored:

$ ./crashdemo.exe
raised CRASHDEMO.ERR : crashdemo.adb:4

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

iQIcBAEBAgAGBQJYvr3zAAoJEMCtNsY0flo/v5oQALw/rh/qycSHf+7jcU4BXxWW
7wfI709IMtegm//dOx+lyKl2xQ6wNlG4GG5rqUFZtc0EDRIeowYE4B9Cp5ET7RO3
4EQbLlNl262Y3k3ljUiY4kGpK6GJi6YfUXvlecLT6iYz/iY20fgjUGzrvQv7fX6C
tBIs88TAfrxvBROvcnepDbTiVlhmhJh2uu4y8VZIvuK87ryPkvUlHaHeJGnKJy9X
FdNBBQGHOt6pkneSz2/l+whgoPRSbSMN4q2kP+RkPKK/3otCWnQq66zwL81jsDsg
WN8xYArBh2OIYbzJa1oVtb2OJw5MFwi/ZBUdARP3+ewidvoRyg0H1rToLVEMn2Dd
q/e86JCr6NCPxzZr+6t/YNTjLZqPqQ0YDpu5iH0dgKJ7RZZ2emtmIiNlLrtw8dfg
WDoxszAudXr7b117mj2XgIvdb4IMwLwXUMFhkkBktGpBUnaYcW81FeBkKNAA9vQO
eW93MKnD3xDHXbJBzX4RgEvzM3FA0QsQvFvm8GVFIdm7j9FN64gn5q3BmP3CX21P
72c/I53AgPOKOUONddpm8wSawtPUYhSgb80GAczXVVXVtQh1xfnKlQAax1T4hywl
6e43DryG+8zUpdslvjbVB7++h1/AWTISs1x3fWQk2tgr9aBMbuTdKdgkrHW0QDuT
08k9DqdmRp9GsTmD5k7x
=2iPY
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Keith Marshall
If I rebuild libmingwex-0.dll, adding -static-libgcc to eliminate the
dependency on the libgcc_s_dw2-1.dll turd,
...

Post by Keith Marshall
$ ./crashdemo.exe
abnormal program termination

$ ./crashdemo.exe
raised CRASHDEMO.ERR : crashdemo.adb:4

Consequently, I've uploaded new mingwrt/w32api-5.0 snapshots, with the
rebuilt libmingwex-0.dll, and some C++ specific issues resolved.

Please test.

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

iQIcBAEBAgAGBQJYvxxoAAoJEMCtNsY0flo/dn4P/3lLAoYBcSn9rKsNsLZNbEfF
R33uZUXSjHCylEy/LqcKJdKk78+vXCW3nyGg4FH+L5uEEJrWbNnuy9KyDCzn7mgr
efOpkfxvAFgNPFWW+qdrwdth6uLK1hOFfyzrmhR5W/ohXJZmYKaxstsMQ6G4NlMz
hx7nEhi0BGeZCJaMq6HXcURhZZ65onZSUaVi/nsdL3P8rjZxFT1DwqVLSGYNDzJq
20Ufp+cZ/AAOha61O5z84/Mr0nLPgcbnZdcHCJHTGXjtYmhLzrobmI8pef13h96b
9oiD2ukAOPIqbIHFmaKcYAcg/hf0UiwxGh3GVFVwUTlHES6f8UmD+nk6wt/CtIEq
gMLHpTK2slD0vvyJ51KEpcSHX5GNJHw3mSUvXShdw2J/GHJxba+/XbhSrYyqhu25
l9eZGh9zjh9bnJYqh3j5tG0c9EjgRkHsH/ZJhqvYv69pLqtrCZ30fHLmaNtG8zvZ
FALsU3HyyJA45pxKU6jIsVMbVlYJQNmryvkivqi+I7znjAd2jfZrh/RJUYsnqwnw
J1n7btHIfO7QMvL/NKvPbE6YjgW88evUjYEk/5IGCZGa4G8s3qlty+uvDGKNH6Kr
B+E6R5fMoCq9VcCDugeApQQWgo7aqPuuhZuzoPFOZ6Zx0ke/Siz5D6bPbJzCWR2W
8VR4eSSvqEm+NHL7BEiv
=GFly
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[David Gressett]

Sent: Tuesday, March 07, 2017 2:48 PM
Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

... snip ...

I've uploaded new mingwrt/w32api-5.0 snapshots, with the
rebuilt libmingwex-0.dll, and some C++ specific issues resolved.
Please test.

I tested both Crashdemo and xsinfo in a two-step process.

I constructed a new MinGW with the latest snapshots.

Step 1.
I removed the local copies of libmingwex-0.dll from the directories
in which the the offending executables were located. I
then ran them with the new snapshots active. They worked perfectly.

Step 2.
I then rebuilt them with the latest snapshots and tried them again,
and again, they DTRT.

The Ada exception problem is gone.





------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by David Gressett

I've uploaded new mingwrt/w32api-5.0 snapshots, with the rebuilt
libmingwex-0.dll, and some C++ specific issues resolved.
Please test.

I tested both Crashdemo and xsinfo in a two-step process.
I constructed a new MinGW with the latest snapshots.
Step 1.
I removed the local copies of libmingwex-0.dll from the directories
in which the the offending executables were located. I
then ran them with the new snapshots active. They worked perfectly.
Step 2.
I then rebuilt them with the latest snapshots and tried them again,
and again, they DTRT.
The Ada exception problem is gone.

Thanks, David. I guess this is sufficient for mingwrt/w32api-5.0
publication; I hope to get to that by the coming weekend.

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

iQIcBAEBAgAGBQJYwCTsAAoJEMCtNsY0flo/XrYP/RUK6rl/cYd4bS7ClADZccI0
syKo2SKl6y0JrVW/xfAsspY0daCTRmLHLZ20xxzA69tlwA7z47LFTZBC8/nKedYq
VWBt2gtdn6EkN0B+Br2BlBujtll70vs96j7eNmBUYh8v7AErKgdeACLVtO8taCbd
w+k0SN0HymFyGXSfbzTlUQNpugnvB7+/W4GqHuIYquouhMlXU3FWVVpnIfbuUNdy
g+QvhwPJ4wCaXNb7QxW+luuxzVBpgtdWsBXuK1mm6WX15jftzKzdpMy/WrvUWs40
S3GtsrCK5QqYZKXn/6HpCPIxc/GEIDnt/zGudSJrmotOdj6Exc5JNX/RMXK2Fnyl
rzzaJoj1u6BXdx5TqzqnnGg0l2qUA74pFn8LqV5VNJrLpC8LRGotnQYZbey6zHdO
ecHzUPUe/CePJeX4MucuvtM3wSz06TdlRoLcKKMNNf/G46M40U8B8zss7DN9yswM
QHPRACeodQ0KLY+B42tRdsRRbvYq/lsKHGj2V1A7VUBdQUN0xTyZtXdP8XwWv4gp
Pwth5v+C8An9q4YmDBvAEHIxKADl8NeZs2ZgCTvumgT11JtjB3PpP18G4suKJvJB
6yAx4z7CPhGcXHjIwNnTU5MCkowwMe7KgUubVXCG2wxmf0YHS0WjEEZ9BMYl8BGn
xBwTYVVeLdrO+tJPjcmr
=qCW1
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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-***@lists.sourceforge.net?subject=unsubscribe