Quantcast

Pending new mingwrt and w32api releases

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

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 <[hidden email]> wrote:
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett-3
In reply to this post by Keith Marshall

________________________________________
>From: Keith Marshall <[hidden email]>
>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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

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

On 26/02/17 02:54, David Gressett wrote:
> 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.

> 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

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

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

> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett
>From: Keith Marshall [mailto:[hidden email]]
>Sent: Tuesday, February 28, 2017 3:25 PM
>To: [hidden email]
>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
> lines that it displayed in my msys window:
>
> "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.

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

>> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Eli Zaretskii
> From: David Gressett <[hidden email]>
> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett
>From: Eli Zaretskii [mailto:[hidden email]]
>Sent: Wednesday, March 01, 2017 9:37 PM
>To: MinGW Users List <[hidden email]>
>Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

>> From: David Gressett <[hidden email]>
>> 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.

$ 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=context@entry=0x25df2c0, outer_cfa=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=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=excep@entry=0x2696650) at a-exexpr.adb:353
#6  0x0041f7e7 in ada.exceptions.complete_and_propagate_occurrence (x=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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Eli Zaretskii
> From: David Gressett <[hidden email]>
> Date: Thu, 2 Mar 2017 11:46:18 -0600
>
> Breakpoint 1, 0x0046c038 in abort ()
> (gdb) backtrace
> #0  0x0046c038 in abort ()
> #1  0x00469c34 in uw_init_context_1 (context=context@entry=0x25df2c0, outer_cfa=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=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=excep@entry=0x2696650) at a-exexpr.adb:353
> #6  0x0041f7e7 in ada.exceptions.complete_and_propagate_occurrence (x=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)

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Keith Marshall
In reply to this post by David Gressett
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett
>From: Keith Marshall [mailto:[hidden email]]
>Sent: Saturday, March 04, 2017 4:57 PM
>To: [hidden email]
>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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Eli Zaretskii
> From: David Gressett <[hidden email]>
> Date: Sun, 5 Mar 2017 11:31:15 -0600
>
> >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.

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett
>From: Eli Zaretskii [mailto:[hidden email]]
>Sent: Sunday, March 05, 2017 1:58 PM
>To: MinGW Users List <[hidden email]>
>Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

>> From: David Gressett <[hidden email]>
>> Date: Sun, 5 Mar 2017 11:31:15 -0600
>>
>> >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.

>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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

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

On 06/03/17 01:20, David Gressett wrote:
> 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 ...

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

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

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

iQIcBAEBAgAGBQJYvVSWAAoJEMCtNsY0flo/x8EP/1f//dh+/F+XlromQcTC2K1m
gqWJxeeiIxBS4ToxC8GdPyJ9Ssh3ZPSgcioQ3XMBxduCfk8mIqK4HBSI2ug4Mqo6
Myf2AGKJPgruOX+m8woY2xB22gqehoFSHqKET5UdQhgh71zUHCNhjFSOMGQtR6tB
S5Ewc8gQlcilC+x74WeSnIwcPO8ewQv+ki6UNiv1ISUdu99iq0PWkXgj+VcKo0Uk
MynHum751mQHtnD+So5H/ph5EBFUwV8za+BseijPqSI1kT/lrhlEEo+PPFgycshL
U1D2P39MgVWfzspT7xebTnK2y72f4brx2b34CbYnUs+DbBJMhtvGvyOFRDkMY2Gq
XV/k0xTQTYQ1+HL4FLvOrxFxd3Wz+UdEY0eZFpSs7itoNOc6xNMykVDg98Runxud
VqFWnUgJ9WMYE5yTohdGarFWOW+s1wDntwAorcExfb5DIlzVHtZIA6aKNImD7Azq
SIF38hBz9CbHWIbpfw+oJAJm9HtBx/qqqpDQ4ID+Vdlba9MdG7C0OE8AFkIx6svT
WBAMk4YqpzBwn8gmcBaUsBIn3Ya1dgAaKnQsy2o227bAVFEsJA8Z+0yl9jXnpYvd
Ts5uRci8m+MOqQo3qM7DZKLz3KCXc9P7eJKwZPsDDIH/o/X4KU6uKjEGhuPeVdJi
iuL1xrSM8QnmF9/qd8pF
=cFhv
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe

hg.log.xz (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Keith Marshall
In reply to this post by David Gressett
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/03/17 01:20, David Gressett wrote:

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

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

David Gressett
>From: Keith Marshall [mailto:[hidden email]]
>Sent: Monday, March 06, 2017 3:17 PM
>To: [hidden email]
>Subject: Re: [Mingw-users] Pending new mingwrt and w32api releases

On 06/03/17 01:20, David Gressett wrote:
>> I ... 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
... snip ...
>> 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.
... 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Chris Johns
On 07/03/2017 11:00, David Gressett wrote:

> 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.  */

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Keith Marshall
In reply to this post by David Gressett
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/17 00:00, David Gressett wrote:
> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

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

On 07/03/17 09:22, Keith Marshall wrote:

> DTRT, but *with* libmingwex.dll.a (and/or libmingwex-0.dll) installed:
>
>   ...
>
>   $ 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

Then, when I rebuild and rerun your test case, instead of:

>   $ ./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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Eli Zaretskii
In reply to this post by Chris Johns
> From: Chris Johns <[hidden email]>
> Date: Tue, 7 Mar 2017 12:20:13 +1100
>
> >  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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pending new mingwrt and w32api releases

Keith Marshall
In reply to this post by Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/17 14:04, Keith Marshall wrote:

> If I rebuild libmingwex-0.dll, adding -static-libgcc to eliminate the
> dependency on the libgcc_s_dw2-1.dll turd,
>
> ...
>
> Then, when I rebuild and rerun your test case, instead of:
>
>>   $ ./crashdemo.exe
>>   abnormal program termination
>
> I now see normal behaviour restored:
>
>   $ ./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
[hidden email]

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:[hidden email]?subject=unsubscribe
12
Loading...