Segmentation fault before main

Segmentation fault before main

[Marco Atzeri]

Hi Corinna,

as mention some time ago, testing netcdf 4.4.0 release candidates
I see a puzzling SIGSEGV before reaching main, so something goes wrong
on cygwin loading/inizialization of the program.

It happens in a simple test programs that is linked to
cygnetcdf-7.dll and its only job is to create a test file
called ctest0.nc.

Previous 4.3.3.1 test case runs fine.
The new ctest.c fails both with the new and with the old library.
Test case and binaries are here :
   http://matzeri.altervista.org/works/segfault/

$ gcc ctest.c -o ctest.exe -lnetcdf

$ gdb ./ctest.exe
(gdb) break main
Breakpoint 1 at 0x100401171
(gdb) run
Starting program: /cygdrive/e/cyg_pub/devel/netcdf/tests/ctest-440.exe
[New Thread 8404.0x18f4]
[New Thread 8404.0xa8c]
[New Thread 8404.0x2270]

Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at 
/usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:146
146             orq     $0x0, (%rcx)            /* probe there */


$ uname -svrm
CYGWIN_NT-6.1 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64


libnetcdf-devel                         4.3.3.1-2
libnetcdf7                              4.3.3.1-2
netcdf                                  4.3.3.1-2
netcdf-debuginfo                        4.3.3.1-2


Unfortunately I have no clue about this code:

/* ___chkstk_ms is a *special* function call, which uses %rax as the 
argument.
    We avoid clobbering any registers.  Unlike ___chkstk, it just probes the
    stack and does no stack allocation.  */
         .global ___chkstk_ms
#ifdef __x86_64__
         cfi_startproc()
___chkstk_ms:
         pushq   %rcx                    /* save temps */
         cfi_push(%rcx)
         pushq   %rax
         cfi_push(%rax)
         cmpq    $0x1000, %rax           /* > 4k ?*/
         leaq    24(%rsp), %rcx          /* point past return addr */
         jb      2f

1:      subq    $0x1000, %rcx           /* yes, move pointer down 4k */
         orq     $0x0, (%rcx)            /* probe there */

Any help will be really appreciated.

Regards
Marco

--
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: Segmentation fault before main

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

On Oct 30 16:25, Marco Atzeri wrote:
> Hi Corinna,
> 
> as mention some time ago, testing netcdf 4.4.0 release candidates
> I see a puzzling SIGSEGV before reaching main, so something goes wrong
> on cygwin loading/inizialization of the program.
> 
> It happens in a simple test programs that is linked to
> cygnetcdf-7.dll and its only job is to create a test file
> called ctest0.nc.
> 
> Previous 4.3.3.1 test case runs fine.
> The new ctest.c fails both with the new and with the old library.
> Test case and binaries are here :
>   http://matzeri.altervista.org/works/segfault/
> 
> $ gcc ctest.c -o ctest.exe -lnetcdf
> 
> $ gdb ./ctest.exe
> (gdb) break main
> Breakpoint 1 at 0x100401171
> (gdb) run
> Starting program: /cygdrive/e/cyg_pub/devel/netcdf/tests/ctest-440.exe
> [New Thread 8404.0x18f4]
> [New Thread 8404.0xa8c]
> [New Thread 8404.0x2270]
> 
> Program received signal SIGSEGV, Segmentation fault.
> ___chkstk_ms () at
> /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:146
> 146             orq     $0x0, (%rcx)            /* probe there */
> 
> 
> $ uname -svrm
> CYGWIN_NT-6.1 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64
> 
> 
> libnetcdf-devel                         4.3.3.1-2
> libnetcdf7                              4.3.3.1-2
> netcdf                                  4.3.3.1-2
> netcdf-debuginfo                        4.3.3.1-2
> 
> 
> Unfortunately I have no clue about this code:
> 
> /* ___chkstk_ms is a *special* function call, which uses %rax as the
> argument.
>    We avoid clobbering any registers.  Unlike ___chkstk, it just probes the
>    stack and does no stack allocation.  */
>         .global ___chkstk_ms
> #ifdef __x86_64__
>         cfi_startproc()
> ___chkstk_ms:
>         pushq   %rcx                    /* save temps */
>         cfi_push(%rcx)
>         pushq   %rax
>         cfi_push(%rax)
>         cmpq    $0x1000, %rax           /* > 4k ?*/
>         leaq    24(%rsp), %rcx          /* point past return addr */
>         jb      2f
> 
> 1:      subq    $0x1000, %rcx           /* yes, move pointer down 4k */
>         orq     $0x0, (%rcx)            /* probe there */
> 
> Any help will be really appreciated.

Well, it's a stack probe.  It's typically called when trying to allocate
big datastructures on the stack, e.g. with alloca.  Did you try to raise
the default stacksize in the executable header (see peflags -x and -X
options).  There's not much else to work with...


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Segmentation fault before main

[Marco Atzeri]

On 30/10/2015 20:18, Corinna Vinschen wrote:
> On Oct 30 16:25, Marco Atzeri wrote:
>> Hi Corinna,
>>

>> Any help will be really appreciated.
>
> Well, it's a stack probe.  It's typically called when trying to allocate
> big datastructures on the stack, e.g. with alloca.  Did you try to raise
> the default stacksize in the executable header (see peflags -x and -X
> options).  There's not much else to work with...
>
>
> HTH,
> Corinna

I increased it to 20M and was still failing; after I gave up.

Upstream mentioned a change to be implemented on the matter.
May be I was not the only one reporting it

Thanks
Marco








--
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: Segmentation fault before main

[Marco Atzeri]

On 30/10/2015 20:45, Marco Atzeri wrote:
> On 30/10/2015 20:18, Corinna Vinschen wrote:
>> On Oct 30 16:25, Marco Atzeri wrote:
>>> Hi Corinna,
>>>
>
>>> Any help will be really appreciated.
>>
>> Well, it's a stack probe.  It's typically called when trying to allocate
>> big datastructures on the stack, e.g. with alloca.  Did you try to raise
>> the default stacksize in the executable header (see peflags -x and -X
>> options).  There's not much else to work with...
>>


For the archive, I found the culprit in the test code.
Using "%lu" to print int is not a good idea on cygwin 64 bit.


-       bbprintf0(stmt,"%ssize_t %s_countset[%lu] = {",
+       bbprintf0(stmt,"%ssize_t %s_countset[%u] = {",
                         indented(1),
                         cname(vsym),
                         rank);


as it could produce

     size_t br_startset[25769803777] = {0} ;
     size_t br_countset[25769803777] = {2};

instead of
    size_t br_startset[1] = {0} ;
    size_t br_countset[1] = {2};


as 25769803777 = 0x00060001

Regards
Marco

--
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: Segmentation fault before main

[Csaba Raduly]

On Wed, Nov 4, 2015 at 10:42 PM, Marco Atzeri  wrote:
>
>
> For the archive, I found the culprit in the test code.
> Using "%lu" to print int is not a good idea on cygwin 64 bit.

That's why we have -Wformat=2

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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: Segmentation fault before main

[Marco Atzeri]

On 05/11/2015 09:49, Csaba Raduly wrote:
> On Wed, Nov 4, 2015 at 10:42 PM, Marco Atzeri  wrote:
>>
>>
>> For the archive, I found the culprit in the test code.
>> Using "%lu" to print int is not a good idea on cygwin 64 bit.
>
> That's why we have -Wformat=2
>
> Csaba
>

Thanks for the suggestion, but it seems not
effective for this type of issue.

I rebuilt the original code and no additional
warning arises.



--
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: Segmentation fault before main

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On Nov  4 22:42, Marco Atzeri wrote:
> On 30/10/2015 20:45, Marco Atzeri wrote:
> >On 30/10/2015 20:18, Corinna Vinschen wrote:
> >>On Oct 30 16:25, Marco Atzeri wrote:
> >>>Hi Corinna,
> >>>
> >
> >>>Any help will be really appreciated.
> >>
> >>Well, it's a stack probe.  It's typically called when trying to allocate
> >>big datastructures on the stack, e.g. with alloca.  Did you try to raise
> >>the default stacksize in the executable header (see peflags -x and -X
> >>options).  There's not much else to work with...
> >>
> 
> 
> For the archive, I found the culprit in the test code.

I'm happy to read that.

> Using "%lu" to print int is not a good idea on cygwin 64 bit.
> 
> 
> -       bbprintf0(stmt,"%ssize_t %s_countset[%lu] = {",
> +       bbprintf0(stmt,"%ssize_t %s_countset[%u] = {",
>                         indented(1),
>                         cname(vsym),
>                         rank);

...and you wouldn't even have noticed it on Linux, because it uses the
SystemV ABI which passes the first 6 arguments in registers, in contrast
to the MS ABI which only passes the first 4 arguments in regs.

Thus on Linux you'd have silenty get the benefit of the CPU clearing the
upper 32 bits of a register when moving a 32 bit value into it, which
doesn't happen when moving a 32 bit argument to the stack.

That's one of the interesting side effects of porting an application.
Maybe it would make sense to mention this problem in
https://cygwin.com/faq/faq.html#faq.programming.64bitporting...

> as it could produce
> 
>     size_t br_startset[25769803777] = {0} ;
>     size_t br_countset[25769803777] = {2};

Ouch.

> instead of
>    size_t br_startset[1] = {0} ;
>    size_t br_countset[1] = {2};
> 
> 
> as 25769803777 = 0x00060001

I guess you mean 0x600000001 :)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]