Re: gpsmon crashes in ncurses code

[Thomas Dickey]

On Mon, Apr 20, 2020 at 02:36:10PM +0200, SZIGETVÁRI János wrote:
> Hi Thomas,
> 
> Thomas Dickey <address@hidden> ezt írta (időpont: 2020. ápr. 18., Szo,
> 22:22):
> 
> > What I can see looks normal, but the problem is the "text" pointer,
> > which is null.
> >
> > _line is a pointer to an array of line data
> > (which is where "line" comes from, above):
> >
> > In gdb, you should be able to do
> >
> >         print win->_line[0]
> >         print win->_line[1]
> >         print win->_line[2]     <---- the one that's bad
> >         print win->_line[3]
> >
> > Perhaps the whole array has some problem.  I'd look at that first,
> > and try to see if it was actually initialized.
> >
> 
> It looks more-or-less okay. Only the third line seems off with its
> null-pointer:
> 
> (gdb) define chtype_print
> Type commands for definition of "chtype_print".
> End with a line saying just "end".
> >echo "
> >set $c = (unsigned int *)$arg0
> >set $d = (char) ( (*$c) & (A_CHARTEXT) )
> >while ( $d )
>  >  if ( $d > 0x7f )
>   >    printf "[%x]", $d
>   >  else
>   >    printf "%c", $d
>   >  end
>  >  set $c++
>  >  set $d = (char) ( (*$c) & (A_CHARTEXT) )
>  >end
> >echo "\n
> >end
> ...
> (gdb) chtype_print  (win->_line[0]->text)
> "lqqqqqqqqqqqqqqqqqqqqqqqqqqk
>      "
> (gdb) chtype_print  (win->_line[1]->text)
> "xCh PRN  Az  El S/N Flag U x
>      "
> (gdb) chtype_print  (win->_line[2]->text)
> "Cannot access memory at address 0x0
> (gdb) chtype_print  (win->_line[3]->text)
> "x                          x
>      "
> (gdb) print win->_line[0]
> $22 = {text = 0x211bf8, firstchar = 0, lastchar = 27, oldindex = 0}
> (gdb) print win->_line[1]
> $23 = {text = 0x211d40, firstchar = 0, lastchar = 27, oldindex = 0}
> (gdb) print win->_line[2]
> $24 = {text = 0x0, firstchar = 0, lastchar = 27, oldindex = 0}
> (gdb) print win->_line[3]
> $25 = {text = 0x2127f8, firstchar = 0, lastchar = 27, oldindex = 0}
> 
> ...and if you configured using "--with-trace", you could turn on the
> > trace feature, e.g.,
> >
> >         rm -f trace
> >         NCURSES_TRACE=0x220 gpsmon
> >
> 
> I have recompiled ncurses with your latest patches and the --with-trace
> flag enabled.
> I have produced a traces as you requested, and fed it to tracemunch too.
> Please find the output attached.

The trace looks odd because the line with wprintw

        called {wprintw(window1,"Unknown device")

is indented by 16384 (which happens to be 2^14).  Each of those "+ "
levels is supposed to be corresponding to a call/return level.

In a quick check with one of ncurses test-programs (testcurs),
just in case I broke something.., I don't see any comparable oddness
in the trace around calls to wprintw.

So it seems that the odd trace might be in your build of ncurses.
(Or possibly since gpsmon does something with multiple threads,
it _could_ be calling some curses function without locking).

The level used by _tracef is in the data _nc_globals, i.e.,
_nc_globals.trace_level

The "Unknown device" message comes from gpsmon.c in refresh_statwin().
Unlike some other places in gpsmon.c, there's no report_lock() /
report_unlock() around the calls to this function, e.g., as
used in select_packet_monitor().  You might get better results with
the trace if the curses calls were consistently locked (whether
or not it seems "necessary").

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature