Re: Segmentation fault before main
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
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 0x60001 :)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpHlpzO6EERE.pgp
Description: PGP signature
Re: Segmentation fault before main
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
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
Segmentation fault before main
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-debuginfo4.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 ?*/ leaq24(%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
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-debuginfo4.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 ?*/ > leaq24(%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 pgptYL5MuNVKI.pgp Description: PGP signature
Re: Segmentation fault before main
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
