[Top][All Lists]

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

Re: gpxlogger (x: ✘3.23 is near. Please test!)

From: Fred Wright
Subject: Re: gpxlogger (x: ✘3.23 is near. Please test!)
Date: Sun, 1 Aug 2021 16:13:34 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

On Sun, 1 Aug 2021, Gary E. Miller wrote:
On Sat, 31 Jul 2021 21:37:28 -0700 (PDT)
Fred Wright <> wrote:

Previously, quit_handler() was doing things which were technically
illegal but worked, including a gps_close() which terminated the
gps_mainloop(). The new code seems to assume that gps_mainloop()
returns frequently, which it doesn't, since it's designed to
iterate internally, and the only reason for the outer loop was for
reconnecting.  Adding the sig_flag check there doesn't help,
because it's never reached.

Agreed.  So I put the exit in the mainloo callback.  Then added an
atexit() to send the gpx footer.

That works in the common case, but not in the case where the daemon
isn't sending anything.  I don't see any way to fix that without some
change to the API, putting back the ugly gps_close() in the signal
handler, or directly exiting from the signal handler (which is what
it did way back when).

It should fall out the mainloop() on timeout from the daemon.  Did you
test that case?

It hung for over half an hour, with a ^C about 10 minutes in.

BTW, it doesn't get an error if run with no gpsd running at all - it just hangs waiting for data from the nonexistent daemon. *That* bug isn't new, so it's not a regression, but it was at least a quittable hang before. The good news is that it makes the no-data case really easy to test. :-)

It does not matter how it exits, the atexit() will handle the footer and
the gps_close() on exit.

Yes, but only if the exit actually happens.

Needs more work, but after release.

Fixing it properly can wait, but I verified that the 3.22 version
does handle this correctly, so it's indeed a regression as is.

No, 3.22 has several CWE, which I would hate to get escalated to a CVE.

Sure, but introducing a serious operational bug affecting ordinary use, just to fix a theoretical bug that's EXTREMELY difficult to trigger in practice, and in a nonprivileged program at that, hardly seems like progress.

Fred Wright

reply via email to

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