Packages of mingw64 i686/x86_64 openssl 1.1.1 are empty!

2022-08-11 Thread Carlo B.
Hello,
if you look these packages:

mingw64-x86_64-openssl-1.1.1q-0.1
mingw64-x86_64-openssl-1.1.1p-0.1
mingw64-i686-openssl-1.1.1q-0.1
mingw64-i686-openssl-1.1.1p-0.1

they are EMPTY.
For example, the content of mingw64-x86_64-openssl-1.1.1q-0.1 is:

usr/
usr/share/
usr/share/doc/
usr/share/doc/mingw64-x86_64-openssl/
usr/share/doc/mingw64-x86_64-openssl/AUTHORS
usr/share/doc/mingw64-x86_64-openssl/CHANGES
usr/share/doc/mingw64-x86_64-openssl/FAQ
usr/share/doc/mingw64-x86_64-openssl/LICENSE
usr/share/doc/mingw64-x86_64-openssl/NEWS
usr/share/doc/mingw64-x86_64-openssl/README

https://www.cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmingw64-x86_64-openssl%2Fmingw64-x86_64-openssl-1.1.1q-0.1&grep=openssl

Actually, if you get the "src" packages of openssl for mingw64 and you
try to build them with cygport, it happens that includes, DLLs and
libraries are installed directly into the *REAL* destination
directory, into:

/usr/x86_64-w64-mingw32/sys-root/mingw

or:

/usr/i686-w64-mingw32/sys-root/mingw

instead of the installation directory created by cygport.
I hope that you could fix them.

Sincerely,

Carlo Bramini.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: crash in newlocale()

2022-08-11 Thread Takashi Yano
On Thu, 11 Aug 2022 11:29:28 +1000
Tony Cook wrote:
> Hello everyone,
> 
> While tracking down a crash in development versions of perl the boostrap
> miniperl executable was crashing early in the build process:
> 
> $ gdb --args ./miniperl -e0
> GNU gdb (GDB) (Cygwin 11.2-1) 11.2
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 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 "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./miniperl...
> (gdb) b locale.c:1154
> Breakpoint 1 at 0x10077db13: file locale.c, line 1154.
> (gdb) r
> Starting program: /home/tony/dev/perl/git/perl/miniperl -e0
> [New Thread 13624.0x1c7c]
> [New Thread 13624.0x1978]
> [New Thread 13624.0x2958]
> [New Thread 13624.0x3374]
> 
> Thread 1 "miniperl" hit Breakpoint 1, S_emulate_setlocale_i 
> (my_perl=0x800049910, index=0, new_locale=0x800066628 "en_US.UTF-8", 
> recalc_LC_ALL=-1, line=4026) at locale.c:1154
> 1154new_obj = newlocale(mask, new_locale, basis_obj);
> (gdb) bt
> #0  S_emulate_setlocale_i (my_perl=0x800049910, index=0,
> new_locale=0x800066628 "en_US.UTF-8", recalc_LC_ALL=-1, line=4026)
> at locale.c:1154
> #1  0x000100783849 in Perl_init_i18nl10n (my_perl=0x800049910, 
> printwarn=1)
> at locale.c:4026
> #2  0x000100443c80 in perl_construct (my_perl=0x800049910)
> at /home/tony/dev/perl/git/perl/perl.c:447
> #3  0x0001007b7483 in main (argc=2, argv=0xcc30, env=0x8000281a0)
> at miniperlmain.c:108
> (gdb) p mask
> $1 = 4
> (gdb) p new_locale
> $2 = 0x800066628 "en_US.UTF-8"
> (gdb) p basis_obj
> $3 = (locale_t) 0x1802b3060 <__C_locale>
> (gdb) n
> 
> Thread 1 "miniperl" received signal SIGSEGV, Segmentation fault.
> 0x00080004a310 in ?? ()
> (gdb) bt
> #0  0x00080004a310 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> While I get a SEGV from miniperl, a simple reproducer returns a
> SIGTRAP:
> 
> tony@enceladus ~/dev/perl/git
> $ cat newlocale-test.c
> #include 
> #include 
> 
> int main() {
>   locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
> 
>   locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
>   printf("Done\n");
>   return 0;
> }
> tony@enceladus ~/dev/perl/git
> $ gcc -onewlocale-test -g newlocale-test.c
> 
> tony@enceladus ~/dev/perl/git
> $ gdb ./newlocale-test.exe
> GNU gdb (GDB) (Cygwin 11.2-1) 11.2
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 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 "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./newlocale-test.exe...
> (gdb) r
> Starting program: /home/tony/dev/perl/git/newlocale-test.exe
> [New Thread 9176.0x3a8c]
> [New Thread 9176.0x2014]
> [New Thread 9176.0x2bc4]
> [Thread 9176.0x2014 exited with code 3221225477]
> [Thread 9176.0x3a8c exited with code 3221225477]
> [Thread 9176.0x2bc4 exited with code 3221225477]
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> (gdb) b main
> Breakpoint 1 at 0x10040108d: file newlocale-test.c, line 5.
> (gdb) r
> Starting program: /home/tony/dev/perl/git/newlocale-test.exe
> [New Thread 13668.0x2a7c]
> [New Thread 13668.0x15a0]
> [New Thread 13668.0x2158]
> 
> Thread 1 "newlocale-test" hit Breakpoint 1, main () at newlocale-test.c:5
> 5 locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
> (gdb) n
> 7 locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
> (gdb)
> [Thread 13668.0x2158 exited with code 3221225477]
> [Thread 13668.0x35d0 exited with code 3221225477]
> [Thread 13668.0x2a7c exited with code 3221225477]
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> (gdb)

I looked into this problem and found the access violation
occurs at:
newlib/libc/locale/newlocale.c
@@ 188,7 @@ _newlocale_r (

Re: crash in newlocale()

2022-08-11 Thread Ken Brown

On 8/10/2022 9:29 PM, Tony Cook wrote:

While I get a SEGV from miniperl, a simple reproducer returns a
SIGTRAP:

tony@enceladus ~/dev/perl/git
$ cat newlocale-test.c
#include 
#include 

int main() {
   locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);

   locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
   printf("Done\n");
   return 0;
}
tony@enceladus ~/dev/perl/git
$ gcc -onewlocale-test -g newlocale-test.c

tony@enceladus ~/dev/perl/git
$ gdb ./newlocale-test.exe
GNU gdb (GDB) (Cygwin 11.2-1) 11.2

[...]

Reading symbols from ./newlocale-test.exe...
(gdb) r
Starting program: /home/tony/dev/perl/git/newlocale-test.exe
[New Thread 9176.0x3a8c]
[New Thread 9176.0x2014]
[New Thread 9176.0x2bc4]
[Thread 9176.0x2014 exited with code 3221225477]
[Thread 9176.0x3a8c exited with code 3221225477]
[Thread 9176.0x2bc4 exited with code 3221225477]

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.


I can't explain the SIGTRAP (but you'll find a lot of information if you search 
the internet).  But I don't think it necessarily indicates a problem with 
newlocale.  What happens if you just run your test program normally, not under 
gdb?  It works fine for me:


$ ./newlocale-test.exe

$ echo $?
0

Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: resolv.conf and gnupg2

2022-08-11 Thread Christian Franke

Andrey Repin wrote:

Greetings, Christian Franke!

...

Unfortunately the ipconfig output is always localized, so this does only
work OOTB with English versions of Windows. The ipconfig parsing is also broken 
due to two reasons:
- The current Cygwin versions of awk, grep and sed no longer convert CR/LF
-> LF on stdin, so '/FooBar$/' patterns never match.
- ipconfig may output scoped IPv6 addresses ("fe80::1%12") which are not 
matched by the awk script.
A draft patch is attached. It also avoids the tmp file and uses shell builtins 
where possible.

Why not use netsh with `chcp 65001`?


How would netsh help?

Netsh is also localized and changing the codepage does possibly not 
change the output language. Changing the language would also require 
'.../en-US/netsh.exe.mui' file which is not necessarily installed.


If netsh is run interactively, it prints a deprecation warning for 
'interface' and other commands and recommends usage of powershell.


This works but is slow and might violate local security policy:

 powersh()
 {
   local x
   # May require '-ExecutionPolicy ...'
   if ! x=$(powershell -NoProfile -Command "$@" 2>/dev/null); then
 echo "powershell: failed" >&2
     return 1
   fi
   echo "$x" | tr -d '\r'
 }

 search=$(powersh \
   'Get-DnsClientGlobalSetting `
    | ForEach-Object SuffixSearchList')

 nameservers=$(powersh \
   'Get-DnsClientServerAddress `
    | ForEach-Object ServerAddresses `
    | select -Unique')

 # Alternatively
 nameservers=$(powersh \
   'Get-NetIPConfiguration `
    | ForEach-Object DNSServer `
    | ForEach-Object ServerAddresses `
    | select -Unique')

...

--
Regards,
Christian


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: crash in newlocale()

2022-08-11 Thread Corinna Vinschen
On Aug 11 21:18, Takashi Yano wrote:
> On Thu, 11 Aug 2022 11:29:28 +1000
> Tony Cook wrote:
> > Hello everyone,
> > 
> > While tracking down a crash in development versions of perl the boostrap
> > miniperl executable was crashing early in the build process:
> > [...]
> 
> I looked into this problem and found the access violation
> occurs at:
> newlib/libc/locale/newlocale.c
> @@ 188,7 @@ _newlocale_r (struct _reent *p, int category_mask, const char 
> *locale,
>   if (tmp_locale.lc_cat[i].buf == (const void *) -1)
> {
>   tmp_locale.lc_cat[i].buf = base->lc_cat[i].buf;
>   base->lc_cat[i].ptr = base->lc_cat[i].buf = NULL; <-- Here!!!
> }
> #endif /* __HAVE_LOCALE_INFO__ */
>   _freelocale_r (p, base);
> 
> This is because
> locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
> returns
>   extern const struct __locale_t __C_locale;
>   return (struct __locale_t *) &__C_locale;
> , which is in the const area that cannot be modified.
> 
> This seems to be a newlib bug.
> 
> I also found following patch solves the issue.
> 
> diff --git a/newlib/libc/locale/newlocale.c b/newlib/libc/locale/newlocale.c
> index 0789d5fd9..1974665ec 100644
> --- a/newlib/libc/locale/newlocale.c
> +++ b/newlib/libc/locale/newlocale.c
> @@ -108,10 +108,12 @@ _newlocale_r (struct _reent *p, int category_mask, 
> const char *locale,
>  }
>/* If the new locale is supposed to be all default locale, just return
>   a pointer to the default locale. */
> +#if 0
>if ((!base && category_mask == 0)
>|| (category_mask == LC_VALID_MASK
> && (!strcmp (locale, "C") || !strcmp (locale, "POSIX"
>  return __get_C_locale ();
> +#endif
>/* Start with setting all values to the default locale values. */
>tmp_locale = *__get_C_locale ();
>/* Fill out new category strings. */

I think the right thing to do is to avoid freeing this data, if the base
locale is the C locale.  I sent a patch to cygwin-patches for review.
Can you please take a look?


Thanks,
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] Updated: mutt-2.2.7-1

2022-08-11 Thread Marco Atzeri via Cygwin-announce

New version 2.2.7-1 of

  mutt

is available in the Cygwin distribution:

CHANGES
Last upstream bugfix update release.

Full details on:
https://gitlab.com/muttmua/mutt/raw/master/UPDATING

DESCRIPTION
The Mutt E-Mail Client
"All mail clients suck. This one just sucks less."

Mutt is a small but very powerful text-based mail client
for Unix operating systems.

HOMEPAGE
http://www.mutt.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] Updated: libtirpc-1.3.3-1

2022-08-11 Thread Marco Atzeri via Cygwin-announce

Updated version 1.3.3-1 of

  libtirpc-common
  libtirpc-devel
  libtirpc-doc
  libtirpc3

have been uploaded for cygwin

CHANGES
Last upstream release
https://sourceforge.net/p/libtirpc/mailman/message/37690832/

DESCRIPTION
Libtirpc is a port of Suns Transport-Independent
RPC library to Linux. It's being developed by the
Bull GNU/Linux NFSv4 project.

HOMEPAGE
https://sourceforge.net/projects/libtirpc/

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


[ANNOUNCEMENT] Updated: gnupg2-2.2.35-2

2022-08-11 Thread Marco Atzeri via Cygwin-announce

Version  2.2.35-2  of

gnupg2

is available in the Cygwin distribution:

CYGWIN CHANGES
Rebuilt to remove usage of libdns and need of /etc/resolv.conf

CHANGES
Latest upstream security fix release
https://lists.gnupg.org/pipermail/gnupg-announce/2022q2/

DESCRIPTION
The GNU Privacy Guard

GnuPG is a command line tool without any graphical user interface.
It is an universal crypto engine which can be used directly from
a command line prompt, from shell scripts, or from other programs.
Therefore GnuPG is often used as the actual crypto backend of other
applications.

Full OpenPGP implementation (see RFC4880 at RFC Editor).
Full CMS/X.509 (S/MIME) implementation.
Ssh-agent implementation
Runs on all Unix platforms, Windows and macOS.
A full replacement of PGP; written from scratch.
Does not use any patented algorithms.
Freely available under the GPL;
Can be used as a filter program.
Better functionality than PGP with state of the art security features.
Decrypts and verifies PGP 5, 6 and 7 messages.
Supports RSA, ECDH, ECDSA, EdDSA, Elgamal, DSA, AES, Camellia, 
3DES, Twofish, SHA2, and many more algorithms.

Language support for a load of languages.
Online help system.
Optional anonymous message receivers.
Integrated support for HKP keyservers (sks-keyservers.net).
and many more things….

HOMEPAGE
http://www.gnupg.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: [ANNOUNCEMENT] Updated: irssi-1.4.2-1

2022-08-11 Thread Marco Atzeri

On 02.08.2022 13:14, Frank Hedrich wrote:


Marco Atzeri wrote:


New version 1.4.2-1



irssi


The command /notify -list in irssi makes the application crash. /notify (without
-list) works. This didn't happen in the previous version.

I get an irssi.exe.stackdump with Exception: STATUS_ACCESS_VIOLATION
(thread main), as standard user and as administrator.

This is in mintty with bash, with a current Cygwin (3.3.5-1) and current
Windows 11 with all updates installed respectively, everything 64-bit.



Hi Frank,

I can not replicate, no crash on my side


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: gpg-agent stuck at 100%

2022-08-11 Thread Marco Atzeri

On 02.08.2022 15:43, Henry S. Thompson wrote:

: cygcheck -c cygwin gnupg2

cygwin 3.3.5-1  OK
gnupg2 2.2.35-1 OK

About once a week, gpg-agent starts consuming 100% of a CPU according
to top, and any client that tries to get an answer from it hangs.

kill -9 doesn't succeed.  Killing with Process Explorer works, and
then everything is OK for another week or so.

Anyone else experiencing this?  Any advice on how to debug?

Thanks,

ht


Hi Henry,

I have not noticed such issue, and my ssh-agent is always running
when cygwin is active.

Are you running the gpg-agent for a full week or it is just a average 
statistics ?


regards
Marco

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Warning message about not found stats package on R-4.2.1-1

2022-08-11 Thread Marco Atzeri

On 09.07.2022 13:12, Xavier Delaruelle wrote:

Hello All,

I am using Cygwin through GitHub actions to test the software I maintain
(Environment Modules) on this system.

I would like to report that after the update to the new version of the R
package (4.2.1-1), a warning message appears about the "stats" package of R
which seem missing:

During startup - Warning message:
package 'stats' in options("defaultPackages") was not found

By comparing the hint file of this new package with the previous version
(4.1.2-1), we can observe that the liblapack0 dependency has been removed.

By manually installing the liblapack0 package, the warning message
described above disappear. So it seems that the "stats" module of R
requires this liblapack0 cygwin package to load properly.

Regards,
Xavier



thanks Xavier
for the info.

It is caused by a glitch in my build system, I had a spurious 
cyglapack0.dll in the wrong place that was not recognized for R depency



I will update R package dependency

Regards
Marco



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: gpg-agent stuck at 100%

2022-08-11 Thread Henry S. Thompson
Marco Atzeri writes:

> ...
> I have not noticed such issue, and my ssh-agent is always running
> when cygwin is active.
>
> Are you running the gpg-agent for a full week or it is just a average
> statistics ?

I'm using gpg-agent instead of ssh-agent, so it's always running.

After a week or two it goes rogue.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: crash in newlocale()

2022-08-11 Thread Takashi Yano
On Thu, 11 Aug 2022 19:35:39 +0200
Corinna Vinschen wrote:
> On Aug 11 21:18, Takashi Yano wrote:
> > On Thu, 11 Aug 2022 11:29:28 +1000
> > Tony Cook wrote:
> > > Hello everyone,
> > > 
> > > While tracking down a crash in development versions of perl the boostrap
> > > miniperl executable was crashing early in the build process:
> > > [...]
> > 
> > I looked into this problem and found the access violation
> > occurs at:
> > newlib/libc/locale/newlocale.c
> > @@ 188,7 @@ _newlocale_r (struct _reent *p, int category_mask, const char 
> > *locale,
> > if (tmp_locale.lc_cat[i].buf == (const void *) -1)
> >   {
> > tmp_locale.lc_cat[i].buf = base->lc_cat[i].buf;
> > base->lc_cat[i].ptr = base->lc_cat[i].buf = NULL; <-- Here!!!
> >   }
> > #endif /* __HAVE_LOCALE_INFO__ */
> >   _freelocale_r (p, base);
> > 
> > This is because
> > locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
> > returns
> >   extern const struct __locale_t __C_locale;
> >   return (struct __locale_t *) &__C_locale;
> > , which is in the const area that cannot be modified.
> > 
> > This seems to be a newlib bug.
> > 
> > I also found following patch solves the issue.
> > 
> > diff --git a/newlib/libc/locale/newlocale.c b/newlib/libc/locale/newlocale.c
> > index 0789d5fd9..1974665ec 100644
> > --- a/newlib/libc/locale/newlocale.c
> > +++ b/newlib/libc/locale/newlocale.c
> > @@ -108,10 +108,12 @@ _newlocale_r (struct _reent *p, int category_mask, 
> > const char *locale,
> >  }
> >/* If the new locale is supposed to be all default locale, just return
> >   a pointer to the default locale. */
> > +#if 0
> >if ((!base && category_mask == 0)
> >|| (category_mask == LC_VALID_MASK
> >   && (!strcmp (locale, "C") || !strcmp (locale, "POSIX"
> >  return __get_C_locale ();
> > +#endif
> >/* Start with setting all values to the default locale values. */
> >tmp_locale = *__get_C_locale ();
> >/* Fill out new category strings. */
> 
> I think the right thing to do is to avoid freeing this data, if the base
> locale is the C locale.  I sent a patch to cygwin-patches for review.
> Can you please take a look?

LGTM. Thanks!

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: crash in newlocale()

2022-08-11 Thread Tony Cook
On Thu, Aug 11, 2022 at 09:13:21AM -0400, Ken Brown wrote:
> On 8/10/2022 9:29 PM, Tony Cook wrote:
> > While I get a SEGV from miniperl, a simple reproducer returns a
> > SIGTRAP:
> > 
> > tony@enceladus ~/dev/perl/git
> > $ cat newlocale-test.c
> > #include 
> > #include 
> > 
> > int main() {
> >locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
> > 
> >locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
> >printf("Done\n");
> >return 0;
> > }
> > tony@enceladus ~/dev/perl/git
> > $ gcc -onewlocale-test -g newlocale-test.c
> > 
> > tony@enceladus ~/dev/perl/git
> > $ gdb ./newlocale-test.exe
> > GNU gdb (GDB) (Cygwin 11.2-1) 11.2
> [...]
> > Reading symbols from ./newlocale-test.exe...
> > (gdb) r
> > Starting program: /home/tony/dev/perl/git/newlocale-test.exe
> > [New Thread 9176.0x3a8c]
> > [New Thread 9176.0x2014]
> > [New Thread 9176.0x2bc4]
> > [Thread 9176.0x2014 exited with code 3221225477]
> > [Thread 9176.0x3a8c exited with code 3221225477]
> > [Thread 9176.0x2bc4 exited with code 3221225477]
> > 
> > Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> > The program no longer exists.
> 
> I can't explain the SIGTRAP (but you'll find a lot of information if you
> search the internet).  But I don't think it necessarily indicates a problem
> with newlocale.  What happens if you just run your test program normally,
> not under gdb?  It works fine for me:
> 
> $ ./newlocale-test.exe
> 
> $ echo $?
> 0

Where is the "Done"?

Tony

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: crash in newlocale()

2022-08-11 Thread Ken Brown

On 8/11/2022 8:11 PM, Tony Cook wrote:

On Thu, Aug 11, 2022 at 09:13:21AM -0400, Ken Brown wrote:

It works fine for me:

$ ./newlocale-test.exe

$ echo $?
0


Where is the "Done"?


You're right, there is indeed a crash in newlocale.  This is provided by newlib, 
so the discussion moved to the newlib list, where Takashi explained the cause 
and Corinna provided a fix. See


  https://sourceware.org/pipermail/newlib/2022/019844.html

Sorry for the noise.

Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple