possible bug in libXt or libXaw

possible bug in libXt or libXaw

[Marco Atzeri]

testing ncview
http://meteora.ucsd.edu/~pierce/ncview_home_page.html

I found, only on 64 bit, a segfault due to incorrect
widget (aka pointer) value.
It could be a software bug, but it looks to me
more a bug somewhere in the underlying libs

#0  LayoutChild (w=w@entry=0x60014bd50)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:693
#1  0x00000003fa40fc26 in LayoutChild (w=w@entry=0x60014dd30)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#2  0x00000003fa40fc26 in LayoutChild (w=<optimized out>)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#3  0x00000003fa4104ed in Layout (fw=0x600112640, width=<optimized out>,
     height=<optimized out>, force_relayout=1)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:565
#4  0x00000003fa40fb2b in XawFormChangeManaged (w=0x600112640)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:1022
#5  0x00000003fa228f5c in XtUnmanageChildren (children=0x22a880, 
num_children=1)
     at /usr/src/debug/libXt-1.1.4-2/src/Manage.c:184
#6  0x00000003fa229038 in XtUnmanageChild (child=0x60014bd40,
     child@entry=0x60014dd30) at 
/usr/src/debug/libXt-1.1.4-2/src/Manage.c:204
#7  0x00000003fa21b1db in XtPhase2Destroy (widget=0x60014dd30)
     at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:228
#8  0x00000003fa21b4e8 in _XtDoPhase2Destroy (app=app@entry=0x60003cf50,
     dispatch_level=dispatch_level@entry=1)
     at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:322
#9  0x00000003fa22018b in XtDispatchEvent (event=0x100632940 <event>)
     at /usr/src/debug/libXt-1.1.4-2/src/Event.c:1432
#10 0x0000000100425526 in x_process_user_input ()
     at /usr/src/debug/ncview-2.1.3-1/src/interface/x_interface.c:2492
#11 0x000000010041f52a in in_process_user_input ()
     at /usr/src/debug/ncview-2.1.3-1/src/interface/interface.c:149
#12 0x0000000100403188 in process_user_input ()
     at /usr/src/debug/ncview-2.1.3-1/src/ncview.c:715
#13 0x00000001004012e4 in main (argc=2, argv=0x22aae0)
     at /usr/src/debug/ncview-2.1.3-1/src/ncview.c:149

(gdb) frame 0
#0  LayoutChild (w=w@entry=0x60014bd50)
     at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:693
693             FormConstraints ref_form = 
(FormConstraints)ref->core.constraints;
(gdb) l
688         }
689
690         form->form.new_x = form->form.dx;
691         form->form.new_y = form->form.dy;
692         if ((ref = form->form.horiz_base) != NULL) {
693             FormConstraints ref_form = 
(FormConstraints)ref->core.constraints;
694
695             LayoutChild(ref);
696             form->form.new_x += ref_form->form.new_x + XtWidth(ref) +
697                                 (XtBorderWidth(ref) << 1);


this is the pointer causing the segfault

(gdb) p form->form.horiz_base
$2 = (Widget) 0x6275705f6779632f

while similar pointers have a much smaller address,

(gdb) p w
$5 = (Widget) 0x60014bd50

so it that an assignment not clearing the upper
portion of the pointer.

Unfortunately my knowledge of Xt and Xaw is very limited so
if someone have any idea how to trace the bug origin,
I will appreciate.

Program and data available at:
http://matzeri.altervista.org/x86_64/ncview/
http://matzeri.altervista.org/works/ncview/

to run the program
ncview sresa1b_ncar_ccsm3_0_run1_200001.nc

just changing the "Var" value 3 or 4 times trigger
the segfault.

Regards
Marco




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

Re: possible bug in libXt or libXaw

[Mark Geisert]

Marco Atzeri writes:
> this is the pointer causing the segfault
> 
> (gdb) p form->form.horiz_base
> $2 = (Widget) 0x6275705f6779632f
> 
> while similar pointers have a much smaller address,
> 
> (gdb) p w
> $5 = (Widget) 0x60014bd50
> 
> so it that an assignment not clearing the upper
> portion of the pointer.

$2 is not a pointer that needed partial clearing, it's a character string
"/cyg_pub".  Possibly a buffer overrun somewhere?  Hope the string fragment
points the way to somebody.

..mark


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

Re: possible bug in libXt or libXaw

[Marco Atzeri]

On 11/16/2014 7:30 AM, Mark Geisert wrote:
> Marco Atzeri writes:
>> this is the pointer causing the segfault
>>
>> (gdb) p form->form.horiz_base
>> $2 = (Widget) 0x6275705f6779632f
>>
>> while similar pointers have a much smaller address,
>>
>> (gdb) p w
>> $5 = (Widget) 0x60014bd50
>>
>> so it that an assignment not clearing the upper
>> portion of the pointer.
>
> $2 is not a pointer that needed partial clearing, it's a character string
> "/cyg_pub".  Possibly a buffer overrun somewhere?  Hope the string fragment
> points the way to somebody.
>
> ..mark
>

thanks for the hint,  "/cyg_pub" is a directory on the root

  $ ls -l / |grep pub
lrwxrwxrwx   1 marco          Administrators     19 Jun 26 19:11 pub -> 
/cygdrive/e/cyg_pub

where the data file was stored,
however moving it to "/tmp" produce as result

  p ref
$1 = (Widget) 0x635f7261636e5f62 aka c_racn_b

that is not very meaningful to me, so the pointer corruption
can be very generic.

Marco




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

Re: possible bug in libXt or libXaw

[Mark Geisert]

Marco Atzeri writes:
> On 11/16/2014 7:30 AM, Mark Geisert wrote:
> > Marco Atzeri writes:
> >> this is the pointer causing the segfault
> >>
> >> (gdb) p form->form.horiz_base
> >> $2 = (Widget) 0x6275705f6779632f
> >>
> >> while similar pointers have a much smaller address,
> >>
> >> (gdb) p w
> >> $5 = (Widget) 0x60014bd50
> >>
> >> so it that an assignment not clearing the upper
> >> portion of the pointer.
> >
> > $2 is not a pointer that needed partial clearing, it's a character string
> > "/cyg_pub".  Possibly a buffer overrun somewhere?  Hope the string fragment
> > points the way to somebody.
> >
> > ..mark
> >
> 
> thanks for the hint,  "/cyg_pub" is a directory on the root
> 
>   $ ls -l / |grep pub
> lrwxrwxrwx   1 marco          Administrators     19 Jun 26 19:11 pub -> 
> /cygdrive/e/cyg_pub
> 
> where the data file was stored,
> however moving it to "/tmp" produce as result
> 
>   p ref
> $1 = (Widget) 0x635f7261636e5f62 aka c_racn_b
> 
> that is not very meaningful to me, so the pointer corruption
> can be very generic.

One has to reverse the bytes, so it's "b_ncar_c", but that's likely still
not meaningful :-(.  You might try:
(gdb) set print pretty
(gdb) p form->form
      or
(gdb) p *form->form
and in the output, look at the struct items before horiz_base to see if one
of them is a char array that has been overrun.  If it's really hosed, all of
the items may have character string contents which means something before
(lower than) the address of form->form has been overrun.
Good Luck,

..mark



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

Re: possible bug in libXt or libXaw

[Marco Atzeri]

On 11/16/2014 10:14 AM, Mark Geisert wrote:
> Marco Atzeri writes:
>> On 11/16/2014 7:30 AM, Mark Geisert wrote:
>>> Marco Atzeri writes:
>>>> this is the pointer causing the segfault
>>>>
>>>> (gdb) p form->form.horiz_base
>>>> $2 = (Widget) 0x6275705f6779632f
>>>>
>>>> while similar pointers have a much smaller address,
>>>>
>>>> (gdb) p w
>>>> $5 = (Widget) 0x60014bd50
>>>>
>>>> so it that an assignment not clearing the upper
>>>> portion of the pointer.
>>>
>>> $2 is not a pointer that needed partial clearing, it's a character string
>>> "/cyg_pub".  Possibly a buffer overrun somewhere?  Hope the string fragment
>>> points the way to somebody.
>>>
>>> ..mark
>>>
>>
>> thanks for the hint,  "/cyg_pub" is a directory on the root
>>
>>    $ ls -l / |grep pub
>> lrwxrwxrwx   1 marco          Administrators     19 Jun 26 19:11 pub ->
>> /cygdrive/e/cyg_pub
>>
>> where the data file was stored,
>> however moving it to "/tmp" produce as result
>>
>>    p ref
>> $1 = (Widget) 0x635f7261636e5f62 aka c_racn_b
>>
>> that is not very meaningful to me, so the pointer corruption
>> can be very generic.

I was wrong. It is meaningful

(gdb) p form
$38 = (FormConstraints) 0x600000003
(gdb) x/20bs 0x600000003
0x600000003:    ""
0x600000004:    ""
0x600000005:    ""
0x600000006:    ""
0x600000007:    ""
0x600000008:    "\023\200"
0x60000000b:    ""
0x60000000c:    ""
0x60000000d:    ""
0x60000000e:    ""
0x60000000f:    ""
0x600000010:    "/tmp/sresa1b_ncar_ccsm3_0_run1_20p/es.nc"
0x600000039:    "ht_arrow"
0x600000042:    "ow"
0x600000045:    ""
0x600000046:    ""
0x600000047:    ""
0x600000048:    ""
0x600000049:    ""
0x60000004a:    ""

So it is a portion of the file name as before,
I start to feel that a pointer is not a NULL as should be...

> Good Luck,

thanks
Marco


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