cygwin 2.4.1: broken ps_AF and ps_AF.utf8 locales

2016-02-01 Thread Tony Cook 
Hi list,

Simplified to a C program below, calls to sprintf() under the ps_AF
and ps_AF.utf8 locales are returning a value that doesn't match the
length of the formatted string:

tony@phobos ~
$ cat ps_AF.c
#include 
#include 
#include 

int main(int argc, char **argv) {
  char buf[100];
  char *loc = argc > 1 ? argv[1] : "ps_AF";
  const char *real_loc;
  if (!(real_loc = setlocale(LC_NUMERIC, loc))) {
perror("setlocale");
return 1;
  }
  printf("locale %s\n", real_loc);
  size_t len = sprintf(buf, "%g", 2.34);
  printf("len %zu\n", len);
  printf("strlen %zu\n", strlen(buf));

  return 0;
}

tony@phobos ~
$ gcc -ops_AF.exe ps_AF.c

tony@phobos ~
$ ./ps_AF
locale ps_AF
len 4
strlen 5

tony@phobos ~
$ ./ps_AF ps_AF.utf8
locale ps_AF.utf8
len 4
strlen 5

tony@phobos ~
$ ./ps_AF en_US.utf8
locale en_US.utf8
len 4
strlen 4

tony@phobos ~
$ uname -a
CYGWIN_NT-6.1-WOW phobos 2.4.1(0.293/5/3) 2016-01-24 11:24 i686 Cygwin

The man pages and C standard could be read as sprintf() returning the
number of multi-byte characters, but if cygwin is intended to follow
Linux behaviour:

tony@mars:~/play$ gcc -ops_AF ps_AF.c 
tony@mars:~/play$ ./ps_AF
locale ps_AF
len 5
strlen 5
tony@mars:~/play$ ./ps_AF ps_AF.utf8
locale ps_AF.utf8
len 5
strlen 5
tony@mars:~/play$ ./ps_AF en_AU.utf8
locale en_AU.utf8
len 4
strlen 4
tony@mars:~/play$ uname -a
Linux mars 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
x86_64 GNU/Linux

(and the decimal point under ps_AF on Linux is multi-byte, character
0x66b or ARABIC DECIMAL SEPARATOR.)

POSIX is less confusing and specifies:

Upon successful completion, the sprintf() function shall return the
number of bytes written to s, excluding the terminating null byte.

(http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html)

Tony


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

Re: cygwin 2.4.1: broken ps_AF and ps_AF.utf8 locales

2016-02-02 Thread Tony Cook 
Achim Gratz said:
> You've been digging at the Perl locale test fails?

More that Karl Williamson was, I just turned it into a report.

Tony

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

Re: [ANNOUNCEMENT] Updated: perl-5.22.1-2

2016-03-09 Thread Tony Cook 
On Wed, Mar 09, 2016 at 11:46:39PM +0100, Achim Gratz wrote:
> 
> A new release of Perl version 5.22.1 is available, which fixes two cases
> of losing taint.  Immediate update is recommended if either the
> environment or the input to any Perl program can be controlled by an
> untrusted party.

Does this refer to the CVE-2015-8607 and CVE-2016-2381 fixes?

The second is a bit more complex than losing taint.

Tony

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

strxfrm() returns an incorrect value on a short buffer

2016-04-11 Thread Tony Cook 
strxfrm() returns an incorrect value if you supply an output buffer
and that buffer is too short for the result.

With the code following:

#include 
#include 
#include 

int main() {
  char xbuf[5] = "";
  char *lc = setlocale(LC_ALL, "en_AU.utf8");
  if (!lc) {
perror("setlocale");
return 1;
  }
  size_t sza = strxfrm(xbuf, "alphabet", sizeof(xbuf));
  printf("sz: %zd\n", sza);
  size_t szb = strxfrm(NULL, "alphabet", 0);
  printf("sz: %zd\n", szb);

  return 0;
}

On cygwin:

tony@phobos ~
$ gcc -ostrxfrmtest strxfrmtest.c

tony@phobos ~
$ ./strxfrmtest
sz: 5
sz: 20

tony@phobos ~
$ uname -a
CYGWIN_NT-6.1-WOW phobos 2.5.0(0.297/5/3) 2016-04-11 09:55 i686 Cygwin

On Linux:

tony@mars:~$ gcc -ostrxfrmtest strxfrmtest.c 
tony@mars:~$ ./strxfrmtest
sz: 26
sz: 26
tony@mars:~$ uname -a
Linux mars 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
x86_64 GNU/Linux

>From looking at the source:

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/nlsfuncs.cc;h=9dbd9b16d53094c60aa835756c967c054ced8e62;hb=HEAD#l1286

It appears that strxfrm() is just returning the size of the output
buffer on an overflow error rather than calling LCMapString() again
with cchDest set to zero to get the required buffer length that
strxfrm() is meant to return on a short buffer.

This came out of the discussion in:

https://rt.perl.org/Ticket/Display.html?id=121734

(not that I've reproduced that issue.)

Tony

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

Re: strxfrm() returns an incorrect value on a short buffer

2016-04-12 Thread Tony Cook 
On Tue, Apr 12, 2016 at 10:20:13AM +, Achim Gratz wrote:
> Tony Cook  develop-help.com> writes:
> > strxfrm() returns an incorrect value if you supply an output buffer
> > and that buffer is too short for the result.
> 
> The text in the C standard is:
> 
> >>>>>
> The strxfrm function returns the length of the transformed string (not
> including the
> terminating null character). If the value returned is n or more, the
> contents of the array
> pointed to by s1 are indeterminate.
> 
> EXAMPLE The value of the following expression is the size of the array
> needed to hold the
> transformation of the string pointed to by s.
> 1 + strxfrm(NULL, s, 0)
> <<<<<
> 
> It doesn't really provide for an explanation of what should happen if you
> start with a buffer that is too small, but from the standpoint of
> defensiveness, if you are getting the size of your buffer or larger, then
> you should ask again with a size of zero to get the actual minimum size
> needed or try again with a larger buffer until the returned value is smaller
> than the buffer size.
> 
> > It appears that strxfrm() is just returning the size of the output
> > buffer on an overflow error rather than calling LCMapString() again
> > with cchDest set to zero to get the required buffer length that
> > strxfrm() is meant to return on a short buffer.
> 
> So, you may be expecting something that the standard doesn't explicitly
> specify, although you might reasonhably invoke that Cygwin should behave
> like Linux in this case.

The specification of strxfrm() in the standard doesn't special-case a
length of zero beyond allowing for s1 to be NULL.

If an implementation were permitted to return the lesser of the full
length of the transformed string and the size of the buffer the
example in the standard wouldn't return what the description says it
does.

Tony

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

Re: strxfrm() returns an incorrect value on a short buffer

2016-04-12 Thread Tony Cook 
On Tue, Apr 12, 2016 at 03:30:49PM +0200, Corinna Vinschen wrote:
> On Apr 12 15:07, Tony Cook wrote:
> > strxfrm() returns an incorrect value if you supply an output buffer
> > and that buffer is too short for the result.
> > 
> > With the code following:
> > [...]
> > It appears that strxfrm() is just returning the size of the output
> > buffer on an overflow error rather than calling LCMapString() again
> > with cchDest set to zero to get the required buffer length that
> > strxfrm() is meant to return on a short buffer.
> 
> Thanks for the testcase.  I applied a patch
> 
>   https://sourceware.org/git/?p=newlib-cygwin.git;h=e1854211
> 
> and created new snapshots on
> 
>   https://cygwin.com/snapshots/
> 
> Please give them a try.

Thanks, fixed in snapshot 20160412.

Tony

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

_GNU_SOURCE doesn't enable cuserid() declaration

2018-11-28 Thread Tony Cook 
Linux stdio.h exposes the declaration of cuserid() both with standard
version macros and with _GNU_SOURCE:

tony@mars:~/play$ cat testcuserid.c
#define _GNU_SOURCE
#include 

int main() {
  puts(cuserid(NULL));
  return 0;
}
tony@mars:~/play$ gcc -otestcuserid -Werror=all testcuserid.c
tony@mars:~/play$ ./testcuserid
tony
tony@mars:~/play$ uname -a
Linux mars 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 
GNU/Linux

while on Cygwin _GNU_SOURCE doesn't expose cuserid():

tony@phobos /cygdrive/n/play
$ gcc -otestcuserid.exe -Werror=all testcuserid.c
testcuserid.c: In function ‘main’:
testcuserid.c:5:8: error: implicit declaration of function ‘cuserid’; did you 
mean ‘L_cuserid’? [-Werror=implicit-function-declaration]
   puts(cuserid(NULL));
^~~
L_cuserid
testcuserid.c:5:8: warning: passing argument 1 of ‘puts’ makes pointer from 
integer without a cast [-Wint-conversion]
In file included from testcuserid.c:2:0:
/usr/include/stdio.h:221:5: note: expected ‘const char *’ but argument is of 
type ‘int’
 int puts (const char *);
 ^~~~
cc1: some warnings being treated as errors

tony@phobos /cygdrive/n/play
$ uname -a
CYGWIN_NT-6.1 phobos 2.11.2(0.329/5/3) 2018-11-08 14:34 x86_64 Cygwin

This seems unintentional, since L_cuserid is exposed with _GNU_SOURCE
on Cygwin:

tony@phobos /cygdrive/n/play
$ cat testlcuserid.c
#define _GNU_SOURCE
#include 

int main() {
  printf("%d\n", (int)L_cuserid);
  return 0;
}

tony@phobos /cygdrive/n/play
$ gcc -otestlcuserid.exe -Werror=all testlcuserid.c

and on Linux:

tony@mars:~/play$ gcc -otestlcuserid -Werror=all testlcuserid.c

(neither produces a diagnostic)

Tony

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

deleted current directory behaviour

2018-01-15 Thread Tony Cook 
Currently cygwin emulates* Linux (and most other POSIXish systems that
I'm aware of) by allowing the current directory to be removed:

tony@saturn ~/dev/perl/git
$ mkdir foo

tony@saturn ~/dev/perl/git
$ cd foo

tony@saturn ~/dev/perl/git/foo
$ rmdir ~/dev/perl/git/foo

but is inconsistent after that:

tony@saturn ~/dev/perl/git/foo
$ pwd
/home/tony/dev/perl/git/foo

tony@saturn ~/dev/perl/git/foo
$ cd ~/dev/perl/git/foo
bash: cd: /home/tony/dev/perl/git/foo: No such file or directory

tony@saturn ~/dev/perl/git/foo
$ cd ~/dev/perl/git

tony@saturn ~/dev/perl/git
$ ls foo
ls: cannot access 'foo': No such file or directory

The pwd isn't (only) the shell caching the current directory:

tony@saturn ~/dev/perl/git
$ cat 132648.c
#include 
#include 
#include 
#include 

int main(void) {
  char buf[1000]; /* keeping this simple */
  if (mkdir("foo", 0700) < 0) {
perror("mkdir");
return 1;
  }
  if (chdir("foo") < 0) {
perror("chdir");
return 1;
  }
  if (rmdir("../foo") < 0) {
perror("rmdir");
return 1;
  }

  if (!getcwd(buf, sizeof(buf))) {
perror("getcwd");
return 1;
  }
  puts(buf);

  return 0;
}

tony@saturn ~/dev/perl/git
$ cc -o132648.exe 132648.c

tony@saturn ~/dev/perl/git
$ ./132648
/home/tony/dev/perl/git/foo

On Linux that program outputs:

tony@mars:.../newlib/git$ ./132648
getcwd: No such file or directory

Is that inconsistency with other platforms intentional?

If it isn't, are there any plans to make it consistent with
Linux/other POSIX-like systems?

Note: I'm not requesting this be fixed.  I have perl test code that
needs to be skip the test with the current behaviour, or allow
execution if the behaviour is made more consistent.

Thanks,
Tony

If it matters:

tony@saturn ~/dev/perl/git
$ uname -a
CYGWIN_NT-6.1-WOW saturn 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin

* Win32 doesn't allow removing the current directory:
  C:\Users\tony>.\132648
  rmdir: Permission denied

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

crash in newlocale()

2022-08-10 Thread Tony Cook 
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)

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

possible snprintf() regression in 3.3.2

2021-11-16 Thread Tony Cook 
This came up from regression testing perl.

Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c
used (from uname):

 cygwin_nt-10.0 fv-az177-186 3.3.1(0.34153) 2021-10-28 20:52 x86_64 cygwin

this did not exhibit the problem.  See 
https://github.com/Perl/perl5/runs/4084168038?check_suite_focus=true

Testing of perl @a85e04e2281234a61c051f8f3ff63bed7381902c, the next
commit, which is purely a documentation change did exhibit the bug, used:

  cygwin_nt-10.0 fv-az177-290 3.3.2(0.34153) 2021-11-08 16:55 x86_64 cygwin

which did crash.  See 
https://github.com/Perl/perl5/runs/4159124596?check_suite_focus=true

snprintf() appears to be crashing internally to ldtoa_r(), without
cygwin-debuginfo the backtrace is:

Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x7ffd26b21040 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x7ffd26b20e7b in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3  0x7ffd26b413a8 in ntdll!RtlRaiseException ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x7ffd26b90bfe in ntdll!KiUserExceptionDispatcher ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x0001801fec7c in eiremain () from /usr/bin/cygwin1.dll
#6  0x000180200319 in _ldtoa_r () from /usr/bin/cygwin1.dll
#7  0x0001801cfca9 in _svfprintf_r () from /usr/bin/cygwin1.dll
#8  0x0001801bf327 in snprintf () from /usr/bin/cygwin1.dll
#9  0x00018018eb0b in _sigfe () from /usr/bin/cygwin1.dll
#10 0x52162647 in Perl_sv_vcatpvfn_flags (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501  "%.9f",
patlen=4, args=0xc550, svargs=0x0, sv_count=0, maybe_tainted=0x0,
flags=0) at sv.c:13482
#11 0x5215e360 in Perl_sv_vsetpvfn (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501  "%.9f",
patlen=4, args=0xc550, svargs=0x0, sv_count=0, maybe_tainted=0x0)
at sv.c:11271
#12 0x5215dde9 in Perl_sv_vsetpvf (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501  "%.9f",
args=0xc550) at sv.c:11101
#13 0x5215dd6a in Perl_sv_setpvf (my_perl=0x80004a3e0, sv=0x800ca9e78,
pat=0x523a3501  "%.9f") at sv.c:11076
#14 0x5210aa74 in Perl_upg_version (my_perl=0x80004a3e0,
ver=0x800cacb00, qv=false) at /home/tony/dev/perl/git/perl/vutil.c:700
#15 0x520440a4 in XS_universal_version (my_perl=0x80004a3e0,
cv=0x80004dfa0) at /home/tony/dev/perl/git/perl/vxs.inc:122
#16 0x52142b10 in Perl_pp_entersub (my_perl=0x80004a3e0)
at pp_hot.c:5361
#17 0x521318e7 in Perl_runops_standard (my_perl=0x80004a3e0)
at run.c:41
#18 0x520376ff in S_run_body (my_perl=0x80004a3e0, oldscope=1)
at perl.c:2715
#19 0x52037214 in perl_run (my_perl=0x80004a3e0) at perl.c:2643
#20 0x00010040117c in main (argc=4, argv=0xcc00, env=0x8000281a0)
at perlmain.c:110

With cygwin-debuginfo installed the backtrace is:

Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x7ffd26b21040 in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x7ffd26b20e7b in ntdll!RtlVirtualUnwind ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3  0x7ffd26b413a8 in ntdll!RtlRaiseException ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x7ffd26b90bfe in ntdll!KiUserExceptionDispatcher ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x0001801fec7c in eiremain (den=0x1, num=0x0, ldp=0x5)
at /usr/src/debug/cygwin-3.3.2-1/newlib/libc/stdlib/ldtoa.c:3736
#6  0x0001802bb0b0 in etens () from /usr/bin/cygwin1.dll
#7  0xbac2 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The stack appears to be badly corrupted (etens isn't a function).

Unfortunately I haven't been able to make a simple pure C reproducer
for this.

To reproduce:

Fetch and build perl (needs make, gcc):

   $ git clone https://github.com/Perl/perl5.git
   $ cd perl5
   $ ./Configure -des -Dusedevel -Doptimize=-O0\ -g
   # adjust -j6 to the desired parallel jobs
   $ make -j6 test-prep

reproducing the original failure:

  $ cd t ; gdb --args ./perl -I.. -MTestInit ../cpan/version/t/01base.t

a simpler test case, with some debugging:

  $ echo '$Foo::VERSION = 9.e99; eval { Foo->VERSION(9e99) }' >mytest.pl
  $ gdb --args ./perl mytest.pl
  ...
  Reading symbols from ./perl...
  (gdb) b vutil.c:700
  No source file named vutil.c.
  Make breakpoint pending on future shared library load? (y or [n]) y
  Breakpoint 1 (vutil.c:700) pending.
  (gdb) r
  Starting prog

Re: possible snprintf() regression in 3.3.2

2021-11-17 Thread Tony Cook 
On Wed, Nov 17, 2021 at 01:27:55PM +0100, Corinna Vinschen via Cygwin wrote:
> On Nov 17 18:21, Takashi Yano via Cygwin wrote:
> > On Wed, 17 Nov 2021 11:37:18 +1100
> > Tony Cook wrote:
> > > This came up from regression testing perl.
> > > 
> > > Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c
> > > used (from uname):
> > > [...]
> > I found the caused by the commit:
> > commit 4d90e5335914551862831de3e02f6c102b78435b
> > Author: Corinna Vinschen 
> > Date:   Thu Nov 4 11:30:44 2021 +0100
> > 
> > ldtoa: fix dropping too many digits from output
> > 
> > ldtoa cuts the number of digits it returns based on a computation of
> > number of supported bits (144) divide by log10(2).  Not only is the
> > integer approximation of log10(2) ~= 8/27 missing a digit here, it
> > also fails to take really small double and long double values into
> > account.
> > 
> > Allow for the full potential precision of long double values.  At the
> > same time, change the local string array allocation to request only as
> > much bytes as necessary to support the caller-requested number of
> > digits, to keep the stack size low on small targets.
> > 
> > In the long run a better fix would be to switch to gdtoa, as the BSD
> > variants, as well as Mingw64 do.
> > 
> > Signed-off-by: Corinna Vinschen 
> > 
> > Reverting this commit solves the problem.
> > 
> > Corinna, could you please have a look?
> 
> I don't have a good solution.  The old ldtoa code is lacking, for
> switching newlib to gdtoa I simply don't have the time.  On the newlib
> list was a short discussion starting at
> https://sourceware.org/pipermail/newlib/2021/018626.html but nothing
> came out of it yet.
> 
> Patches gratefully accepted (except just reverting the above change).

>From what I can tell the problem has nothing to do with the extra
precision, but has to do with misusing ndigits for the buffer size
with a %f format string, leading to a buffer overflow.

At entry to _ldtoa_r() ndigits is 9, but for a %f format with a large
number the number of digits is more closely related to the magnitude
of the number, not ndigits.

With the input number (9e99) and the supplied format I'd expect 109
characters output, but outbuf is only:

   ndigits + MAX_EXP_DIGITS + 10 = 9 + 5 + 10 = 24

characters in length.

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: possible snprintf() regression in 3.3.2

2021-11-20 Thread Tony Cook 
On Thu, Nov 18, 2021 at 09:08:40PM +, Sam Edge via Cygwin wrote:
> I use newlib on embedded with threading libs that have predetermined
> fixed thread stack sizes. While we tend to have more RAM than in former
> times we also have multiple thread stacks. Use of alloca() or variable
> length automatic arrays makes me wince especially in code I might not be
> able to avoid calling which is often the case with XXXprintf() in
> third-party libraries' debug output. I'd usually rather take the
> performance hit from using heap instead of having to make all my stacks
> bigger.

A simple option would be to use an small auto fixed buffer for most
conversions, but use malloc() for %f formats for numbers greater in
magnitude than some limit, though it would also need to be adjusted
for the precision (ndigits here), since they take extra space.

This would avoid using the optional-to-implement VLA feature too.

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: possible snprintf() regression in 3.3.2

2021-11-22 Thread Tony Cook 
On Mon, Nov 22, 2021 at 02:04:06PM +0100, Corinna Vinschen via Cygwin wrote:
> On Nov 22 11:34, Corinna Vinschen via Cygwin wrote:
> > On Nov 21 11:16, Tony Cook wrote:
> > > On Thu, Nov 18, 2021 at 09:08:40PM +, Sam Edge via Cygwin wrote:
> > > > I use newlib on embedded with threading libs that have predetermined
> > > > fixed thread stack sizes. While we tend to have more RAM than in former
> > > > times we also have multiple thread stacks. Use of alloca() or variable
> > > > length automatic arrays makes me wince especially in code I might not be
> > > > able to avoid calling which is often the case with XXXprintf() in
> > > > third-party libraries' debug output. I'd usually rather take the
> > > > performance hit from using heap instead of having to make all my stacks
> > > > bigger.
> > > 
> > > A simple option would be to use an small auto fixed buffer for most
> > > conversions, but use malloc() for %f formats for numbers greater in
> > > magnitude than some limit, though it would also need to be adjusted
> > > for the precision (ndigits here), since they take extra space.
> > > 
> > > This would avoid using the optional-to-implement VLA feature too.
> > 
> > Good idea.  I guess I create a simple fix doing just that.
> 
> I created a patch:
> https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=68faeef4be71
> 
> Please test the latest developer snapshot from http://cygwin.com/snapshots/

I don't think this solves the fundamental problem.

Simply looking at ndigits isn't enough for %f.

For %f with a large number (like 9e99), the buffer size required is
ndigits plus (roughly) log10(n), which we can further estimate
with log2(n)*146/485 (log2(10) is 3.32 ~== 485/146)

I think something more like:

  size_t outsize;
  if (mode == 3) {/* %f */
int expon = (e[NI-1] & 0x7fff) - (EXONE - 1); /* exponent part of float */
/* log2(10) approximately 485/146 */
outsize = expon * 146 / 485 + ndigits + 10;
  }
  else { /* %g/%e */
outsize = ndigits + MAX_EXP_DIGITS + 10;
  }
  if (outsize > NDEC_SML) {
outbuf = (char *)_malloc_r(ptr, outsize);
  }

You'll probably need to pass outsize into etoasc() rather than
calculating it.

See https://github.com/Perl/perl5/blob/blead/sv.c#L13295 for code in
perl that calculates the buffer size needed for %f (precis aka ndigits
is added at line 13385).

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

[perl #81268] static_ext Cwd: wrong deps

2012-06-01 Thread Tony Cook via RT 
On Thu Mar 31 05:00:37 2011, tonyc wrote:
> I have a set of fixes for this in branch tonyc/staticcwd, but I don't
> know if this should be applied with the code freeze.

This was applied in 6c5941c785207c7779c0d0f98546b9e4ada88064 and
de4c0096ebdaf46695cc56e6e72c823fc693d433, over a year ago, by me.

I guess I can close this ticket now :)

Tony





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

[perl #81268] [RESOLVED] static_ext Cwd: wrong deps

2012-06-01 Thread Tony Cook via RT 
According to our records, your request regarding 
  "static_ext Cwd: wrong deps" 
has been resolved. 

If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

https://rt.perl.org:443/rt3/Ticket/Display.html?id=81268 >

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