[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
pgpq8VdiEqI2G.pgp
Description: OpenPGP digital signature
- Re: gpsmon segmentation fault, (continued)
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/09
- Re: gpsmon segmentation fault, Gary E. Miller, 2020/04/09
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/11
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/11
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/11
- Re: gpsmon segmentation fault, Gary E. Miller, 2020/04/11
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/12
- Re: gpsmon segmentation fault, Gary E. Miller, 2020/04/12
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/18
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/27
- Re: gpsmon segmentation fault,
Gary E. Miller <=
- Re: gpsmon segmentation fault, Gary E. Miller, 2020/04/27
- Re: gpsmon segmentation fault, SZIGETVÁRI János, 2020/04/09