gpsd-dev
[Top][All Lists]
Advanced

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

Re: gpsmon segmentation fault


From: Paul Fertser
Subject: Re: gpsmon segmentation fault
Date: Thu, 9 Apr 2020 14:48:49 +0300
User-agent: Mutt/1.10.1 (2018-07-13)

Hi,

On Thu, Apr 09, 2020 at 12:54:26PM +0200, SZIGETVÁRI János wrote:
> Luckily it produced pretty useful output:
>
> root@ntp:~# valgrind /usr/bin/gpsmon
> ==9937== Memcheck, a memory error detector
> ==9937== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==9937== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==9937== Command: /usr/bin/gpsmon
> ==9937==
> ESC[?1049hESC[22;0;0tESC[1;24rESC(BESC[mESC[4lESC[?7hESC[?1hESC===9937== 
> Invalid
> write of size 4
> ==9937==    at 0x145D4: refresh_statwin (gpsmon.c:442)
> ==9937==    by 0x149E7: curses_init (gpsmon.c:490)
> ==9937==    by 0x176D7: main (gpsmon.c:1379)
> ==9937==  Address 0x4bcfaf0 is 24 bytes before a block of size 16 in arena
> "client"
> ==9937==

That's odd. If you're sure there's no chance of you having several
different ncurses version installed (and hence some ABI mismatch) then
I'd try running it under GDB and setting a _watchpoint_ on statwin
variable. That way you'll get a chance to inspect the state each time
it is changed. And probably something even before the line we see in
valgrind is changing statwin leading to a bad write? I find it
unlikely, promptgen looks robust.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:address@hidden



reply via email to

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