Hi Gary,
Over at bug-ncurses I followed the instructions of the ncurses maintainer Thomas Dickey, and recompiled ncurses with the ability to generate a trace about the ncurses operations that are used by the applications that use the ncurses library.
Also we debugged the problem a little more, and it seems that the problem is that the third line passed to ncurses is a null pointer for some reason.
Please see the results, and Thomas' response below:
---------- Forwarded message ---------
Sender:
Thomas DickeyDate: 2020. ápr. 25., Szo, 21:22
Subject: Re: gpsmon crashes in ncurses code
To: SZIGETVÁRI János
Cc: <
address@hidden>
On Mon, Apr 20, 2020 at 02:36:10PM +0200, SZIGETVÁRI János wrote:
> 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) 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").
---------- End of forwarded message ---------
Could you please try implementing Thomas' recommendations on a separate branch that I could then clone and compile to see whether that helps anything?
Thanks!
Best Regards,
János
--
LinkedIn: linkedin.com/in/janosszigetvari__@__˚V˚
Make the switch to open (source) applications, protocols, formats now:
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp