gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsmon segmentation fault


From: Gary E. Miller
Subject: Re: gpsmon segmentation fault
Date: Mon, 27 Apr 2020 10:33:41 -0700

Yo SZIGETVÁRI!

It there an action item in there for me?  I'm unclear how that relates to
the unmaintained/unleaved gpsmon.

On Mon, 27 Apr 2020 12:29:37 +0200
SZIGETVÁRI János <address@hidden> wrote:

> 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 Dickey
> Date: 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
> --
> Janos SZIGETVARI
> RHCE, License no. 150-053-692
> <https://www.redhat.com/rhtapps/verify/?certId=150-053-692>
> 
> 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
> 
> 
> SZIGETVÁRI János <address@hidden> ezt írta (időpont: 2020.
> ápr. 18., Szo, 20:44):
> 
> > Hi Gary,
> >
> > I posted my problem on the bugs-ncurses mailing list.
> > The thread can be followed here:
> > https://lists.gnu.org/archive/html/bug-ncurses/2020-04/msg00012.html
> >
> > Best Regards,
> > János
> > --
> > Janos SZIGETVARI
> > RHCE, License no. 150-053-692
> > <https://www.redhat.com/rhtapps/verify/?certId=150-053-692>
> >
> > 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
> >
> >
> > Gary E. Miller <address@hidden> ezt írta (időpont: 2020. ápr. 13.,
> > H, 4:27):
> >  
> >> Yo SZIGETVÁRI!
> >>
> >> On Sun, 12 Apr 2020 13:42:45 +0200
> >> SZIGETVÁRI János <address@hidden> wrote:
> >>  
> >> > So you are basically saying that it would make sense to contact
> >> > the ncurses devs and ask for their help in figuring out what may
> >> > be going wrong?  
> >>
> >> I'm basically saying I'm lost.  So time to spin the bottle.  Maybe
> >> the ncurses people see an obvious mistake in the code.
> >>
> >> BTW, what is your locale set to?  Can you try setting it to "C"
> >> or "en" or "en.utf8"?
> >>
> >> RGDS
> >> GARY
> >>
> >> ---------------------------------------------------------------------------
> >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR
> >> 97703 address@hidden  Tel:+1 541 382 8588
> >>
> >>             Veritas liberabit vos. -- Quid est veritas?
> >>     "If you can't measure it, you can't improve it." - Lord Kelvin
> >>  
> >  




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpq8VdiEqI2G.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]