Failing sscanf tests

[kangaroo]

I haven't spent any real time investigating this yet, brain dump follows.

Several sscanf tests are currently broken on mac and linux:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/binaries/CMake$ ./src/pal/tests/palsuite/c_runtime/sscanf/test3/paltest_sscanf_test3
vagrant@vagrant-ubuntu-trusty-64:/vagrant/binaries/CMake$ ./src/pal/tests/palsuite/c_runtime/sscanf/test3/paltest_sscanf_test3 ; echo $?
5
vagrant@vagrant-ubuntu-trusty-64:/vagrant/binaries/CMake$ gdb --args ./src/pal/tests/palsuite/c_runtime/sscanf/test3/paltest_sscanf_test3 ; echo $?
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/pal/tests/palsuite/c_runtime/sscanf/test3/paltest_sscanf_test3...done.
(gdb) r
Starting program: /vagrant/binaries/CMake/src/pal/tests/palsuite/c_runtime/sscanf/test3/paltest_sscanf_test3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6bc9700 (LWP 2047)]
[New Thread 0x7ffff63c8700 (LWP 2048)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000510c57 in __tinput_s (stream=0x7fffffffda78, format=0x7fffffffdd87 "n", arglist=0x7fffffffdc30) at /vagrant/src/pal/src/safecrt/input.inl:1038
1038                                        *(int UNALIGNED *)pointer = (unsigned int)number;
(gdb) bt
#0  0x0000000000510c57 in __tinput_s (stream=0x7fffffffda78, format=0x7fffffffdd87 "n", arglist=0x7fffffffdc30) at /vagrant/src/pal/src/safecrt/input.inl:1038
dotnet/coreclr#1  0x0000000000488714 in vscan_fn (inputfn=0x50ed60 <__tinput_s>, string=0x52ccd0 "bar1", format=0x7fffffffdd80 "%[a-z]%n", arglist=0x7fffffffdc30) at /vagrant/src/pal/src/safecrt/sscanf.c:65
dotnet/coreclr#2  0x00000000004884aa in sscanf_s (string=0x52ccd0 "bar1", format=0x7fffffffdd80 "%[a-z]%n") at /vagrant/src/pal/src/safecrt/sscanf.c:201
dotnet/coreclr#3  0x0000000000423c09 in PAL_vsscanf (Buffer=0x52ccd0 "bar1", Format=0x52ccd5 "%[a-z]", ap=0x7fffffffe380) at /vagrant/src/pal/src/cruntime/printf.cpp:1178
dotnet/coreclr#4  0x0000000000428198 in PAL_sscanf (buffer=0x52ccd0 "bar1", format=0x52ccd5 "%[a-z]") at /vagrant/src/pal/src/cruntime/printf.cpp:1479
dotnet/coreclr#5  0x0000000000420306 in DoStrTest (inputstr=0x52ccd0 "bar1", formatstr=0x52ccd5 "%[a-z]", checkstr=0x52ccdc "bar") at /vagrant/src/pal/tests/palsuite/c_runtime/sscanf/test3/../sscanf.h:47
dotnet/coreclr#6  0x0000000000420d53 in main (argc=1, argv=0x7fffffffe628) at /vagrant/src/pal/tests/palsuite/c_runtime/sscanf/test3/test3.c:27

On OSX 3, 9 and 10 are broken. It appears that 9, 10 are passing on Linux just based on luck of where the pointer is:

(gdb) 
1038                                        *(int UNALIGNED *)pointer = (unsigned int)number;
1: *arglist = {gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffdc70, reg_save_area = 0x7fffffffdb80}
(gdb) 
1042                                } else /*NULL*/;
1: *arglist = {gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffdc70, reg_save_area = 0x7fffffffdb80}
(gdb) p pointer
$1 = (void *) 0x7ffff6f8a000 <tzname>
(gdb) 

It seems the 3 cases share a similar base cause of entering the case to parse an array width, which seems at a quick glance like an incorrect branch.

[sergiy-k]

@kangaroo Thank you very much for reporting the issue. We have never seen this before (these tests used to pass all the time on Linux). I guess, like you said, this was just based on luck. I will take a look.

[kangaroo]

@sergiy-k They do pass, mostly because the overconsumption of the va_list happens to return a writeable pointer on linux. So its kind of a false pass :)

[sergiy-k]

Hi @kangaroo, I have fixed these sscanf issues in dotnet/coreclr#258.
Unfortunately, these three tests that you mentioned did not crash when I ran them on Mac (debug and release) so I stepped through them under debugger to make sure the code does the right thing. Luckily, two of the sscanf tests (9 and 11) were crashing on a release build on Linux so that gave me a good starting point since all these failures shared the common root problem. Thank you!

[kangaroo]

@sergiy-k Ok, I'll check the tests on my mac where they were failing shortly to confirm the status.

[kangaroo]

LGTM

Finished running PAL tests.

PAL Test Results:
Passed: 820
Failed: 0

[sergiy-k]

@kangaroo Thank you!