Re: [Cygwin-ports-general] Ncview

Re: [Cygwin-ports-general] Ncview

[Marco Atzeri]

On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:
> Hi,
>
> is it possible to include ncview
> (http://meteora.ucsd.edu/~pierce/ncview_home_page.html) in the software
> distribution?

Hi Vasileios,

1) wrong mailing lists, the right one is cygwin (at) cygwin (dot) com
please follow up there.

>
> For me the installation was only a ./configure && make && make install

2) the 64 bit crashes inside X libs.
    I never succeeded to identify the root cause

>
> thank you very much.
>
> --
> Dr. Vasileios Anagnostopoulos (MSc,PhD)

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: [Cygwin-ports-general] Ncview

[Yaakov Selkowitz]

On Mon, 2015-09-28 at 17:33 +0200, Marco Atzeri wrote:
> On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:
> > is it possible to include ncview
> > (http://meteora.ucsd.edu/~pierce/ncview_home_page.html) in the software
> > distribution?
> 
> 1) wrong mailing lists, the right one is cygwin (at) cygwin (dot) com
> please follow up there.
> 
> >
> > For me the installation was only a ./configure && make && make install
> 
> 2) the 64 bit crashes inside X libs.
>     I never succeeded to identify the root cause

Confirmed.  Often 64-bit-only issues come down to one or more of the
following:

* implicit function declarations.  Per the C standard, argument types
are assumed to match whatever is given (which may be wrong if e.g. 0 is
used instead of 0L or (PointerType)0 or NULL etc.) and the return type
is assumed to be int (which will truncate the actual return value when
it is actually a long/pointer).

* vararg types.  Because these types aren't declared, the compiler can't
automatically cast values to the correct type, so literal values and
symbolic constants must be explicitly cast if they are not meant to be
an int and are not obviously a long/pointer.

In the case of ncview, I strongly suspect the latter should anyone be
interested in fixing this.

--
Yaakov



--
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-ports-general] Ncview

[Marco Atzeri]

On 01/10/2015 19:35, Yaakov Selkowitz wrote:
> On Mon, 2015-09-28 at 17:33 +0200, Marco Atzeri wrote:
>> On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:

>>
>> 2) the 64 bit crashes inside X libs.
>>      I never succeeded to identify the root cause
>
> Confirmed.  Often 64-bit-only issues come down to one or more of the
> following:
>
> * implicit function declarations.  Per the C standard, argument types
> are assumed to match whatever is given (which may be wrong if e.g. 0 is
> used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> is assumed to be int (which will truncate the actual return value when
> it is actually a long/pointer).

This is not. The only two implicit declaration are of type int
and declaring them changes noting.

>
> * vararg types.  Because these types aren't declared, the compiler can't
> automatically cast values to the correct type, so literal values and
> symbolic constants must be explicitly cast if they are not meant to be
> an int and are not obviously a long/pointer.

I don't find any case.

> In the case of ncview, I strongly suspect the latter should anyone be
> interested in fixing this.

The hard issue is that only cygwin 64 bit seems impacted,
while other 64 platform are fine,
and that the crash is well deep X libraries during the
destruction phase of graphical elements

#0  LayoutChild (w=w@entry=0x60065ef80)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:693
#1  0x00000003cabefc26 in LayoutChild (w=w@entry=0x60064e8a0)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#2  0x00000003cabefc26 in LayoutChild (w=<optimized out>)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#3  0x00000003cabf04ed in Layout (fw=0x60011a2e0, width=<optimized out>,
     height=<optimized out>, force_relayout=1)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:565
#4  0x00000003cabefb2b in XawFormChangeManaged (w=0x60011a2e0)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:1022
#5  0x00000003ca758f5c in XtUnmanageChildren (children=0x22c8d0,
     num_children=1) at /usr/src/debug/libXt-1.1.4-2/src/Manage.c:184
#6  0x00000003ca759038 in XtUnmanageChild (child=0x60065ef70,
     child@entry=0x60064e8a0) at 
/usr/src/debug/libXt-1.1.4-2/src/Manage.c:204
#7  0x00000003ca74b1db in XtPhase2Destroy (widget=0x60064e8a0)
     at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:228
#8  0x00000003ca74b4e8 in _XtDoPhase2Destroy (app=app@entry=0x60003c030,
     dispatch_level=dispatch_level@entry=1)
     at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:322
#9  0x00000003ca75018b in XtDispatchEvent (event=0x100632a80 <event>)
     at /usr/src/debug/libXt-1.1.4-2/src/Event.c:1432
#10 0x00000001004257af in x_process_user_input ()
     at /usr/src/debug/ncview-2.1.5-1/src/interface/x_interface.c:2492
#11 0x000000010041f75a in in_process_user_input ()
     at /usr/src/debug/ncview-2.1.5-1/src/interface/interface.c:149
#12 0x00000001004031e5 in process_user_input ()
     at /usr/src/debug/ncview-2.1.5-1/src/ncview.c:718
#13 0x00000001004012f4 in main (argc=2, argv=0x22cb30)
     at /usr/src/debug/ncview-2.1.5-1/src/ncview.c:149

as the X graphics elements are not correctly destroyed in sequence.

If someone more knowledgeable in X is interested I can provide the 
program and a test case.

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: [Cygwin-ports-general] Ncview

[Yaakov Selkowitz]

On Thu, 2015-10-01 at 23:35 +0200, Marco Atzeri wrote:
> On 01/10/2015 19:35, Yaakov Selkowitz wrote:
> > On Mon, 2015-09-28 at 17:33 +0200, Marco Atzeri wrote:
> >> On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:
> 
> >>
> >> 2) the 64 bit crashes inside X libs.
> >>      I never succeeded to identify the root cause
> >
> > Confirmed.  Often 64-bit-only issues come down to one or more of the
> > following:
> >
> > * implicit function declarations.  Per the C standard, argument types
> > are assumed to match whatever is given (which may be wrong if e.g. 0 is
> > used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> > is assumed to be int (which will truncate the actual return value when
> > it is actually a long/pointer).
> 
> This is not. The only two implicit declaration are of type int
> and declaring them changes noting.
> 
> >
> > * vararg types.  Because these types aren't declared, the compiler can't
> > automatically cast values to the correct type, so literal values and
> > symbolic constants must be explicitly cast if they are not meant to be
> > an int and are not obviously a long/pointer.
> 
> I don't find any case.

The XtVa* functions use varargs.

> > In the case of ncview, I strongly suspect the latter should anyone be
> > interested in fixing this.
> 
> The hard issue is that only cygwin 64 bit seems impacted,
> while other 64 platform are fine,
> and that the crash is well deep X libraries during the
> destruction phase of graphical elements
> as the X graphics elements are not correctly destroyed in sequence.
> 
> If someone more knowledgeable in X is interested I can provide the 
> program and a test case.

That would be great.

--
Yaakov




--
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-ports-general] Ncview

[Marco Atzeri]

On 02/10/2015 10:58, Yaakov Selkowitz wrote:
> On Thu, 2015-10-01 at 23:35 +0200, Marco Atzeri wrote:
>>
>> I don't find any case.
>
> The XtVa* functions use varargs.
>
may be.


>>> In the case of ncview, I strongly suspect the latter should anyone be
>>> interested in fixing this.
>>
>> The hard issue is that only cygwin 64 bit seems impacted,
>> while other 64 platform are fine,
>> and that the crash is well deep X libraries during the
>> destruction phase of graphical elements
>> as the X graphics elements are not correctly destroyed in sequence.
>>
>> If someone more knowledgeable in X is interested I can provide the
>> program and a test case.
>
> That would be great.
>
> --
> Yaakov
>

Hi Yaakov,

the program compiled with -O0 is here

http://matzeri.altervista.org/x86_64/ncview/

you can also install with
setup-x86_64.exe -X -O -s http://matzeri.altervista.org

It requires: libnetcdf7 libpng16 libudunits0 libX11_6 libXaw7 libXt6

On   http://matzeri.altervista.org/works/ncview/

you can find a small test database (~2Mb)
    $ ncview s.nc
to run it.

I also loaded a picture of how to replicate the crash.
Until only the first rows of "Var" is selected everything is fine,
the data are presented in other windows, while with the second row
it usually crashes at the 3rd selection.

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: [Cygwin-ports-general] Ncview

[Michael Enright]

On Thu, Oct 1, 2015 at 10:35 AM, Yaakov Selkowitz <yselkowitz@cygwin.com> wrote:
>
> Confirmed.  Often 64-bit-only issues come down to one or more of the
> following:
>
> * implicit function declarations.  Per the C standard, argument types
> are assumed to match whatever is given (which may be wrong if e.g. 0 is
> used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> is assumed to be int (which will truncate the actual return value when
> it is actually a long/pointer).
>
> * vararg types.  Because these types aren't declared, the compiler can't
> automatically cast values to the correct type, so literal values and
> symbolic constants must be explicitly cast if they are not meant to be
> an int and are not obviously a long/pointer.
>

Good list. I would also add attempting to store pointer differences in
an "int" instead of ptrdiff_t and the issue you can see from
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models,
which is that the integer types other than long long on 64-bit Windows
are 32-bits while on 64-bit Linux 'long' and 'long long' are both
64-bit. This issue means that 'long' is a good-enough hack for
ptrdiff_t on 64-bit Linux but not 64-bit Windows. Does Cygwin differ
from Windows itself on this issue? Most 32-bit-designed code is
probably more sensitive to the pointer-difference aspect of this.

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