I thought I would post here before filing a formal bug report in case
this is a known issue and/or workaround available. Today I did a dist-upgrade on a Sid system in shack and neither XDX nor XLog would
start afterwards. Seg faults on both. Installed XLog on my non-shack Sid system and got same result.
I know this problem is happening on the Sid tree, but still. Installs
without any complaint and then simply will not run due to a seg fault? Shouldn't this have been caught in experimental?
Re: Ed Lawson
I thought I would post here before filing a formal bug report in case
this is a known issue and/or workaround available. Today I did a dist-upgrade on a Sid system in shack and neither XDX nor XLog would
start afterwards. Seg faults on both. Installed XLog on my non-shack Sid system and got same result.
This isn't a known problem, can you report a bug?
I know this problem is happening on the Sid tree, but still. Installs without any complaint and then simply will not run due to a seg fault? Shouldn't this have been caught in experimental?
Experimental is only used for new/experimental/beta releases. This is
a package that has already been around forever.
Unfortunately, GUI apps are hard to test or else autopkgtest could
have detected it.
Tony:
Thank you for filing the bugreport. It seems xdx is also failing to
open due to a seg fault for other reasons, and I have filed a bugreport
for it.
For xlog the cause seems to a failure to load a module for acessibility.
In that case, there might be multiple bugs. I was also seeing a
segfault on startup, but it was consistently due to an insufficiently
sized buffer while reading cty.dat. Increasing the buffer size
(doubling it) resolved the issue for me, although it's not very
satisfying. First, I haven't identified exactly why this started
happening - perhaps the recent updates to glib2.0 [1]?
If xlog 2.0.24-3 still segfaults for you, please do open another bug.
It's working for me locally now.
Re: tony mancill
In that case, there might be multiple bugs. I was also seeing a
segfault on startup, but it was consistently due to an insufficiently
sized buffer while reading cty.dat. Increasing the buffer size
(doubling it) resolved the issue for me, although it's not very
satisfying. First, I haven't identified exactly why this started
happening - perhaps the recent updates to glib2.0 [1]?
Perhaps the new cty.dat from hamradio-files has more data in it - some countries have very long lists of callsigns.
Thank you for helping me make the connection. (That makes a lot more
sense than the complicated scenarios I was imagining... :) I was thrown
off the trail by the data/dxx/cty.dat in the xlog source package and
had assumed that it was what was being read (and knew that it hadn't changed).
Re: tony mancill
Thank you for helping me make the connection. (That makes a lot more
sense than the complicated scenarios I was imagining... :) I was thrown off the trail by the data/dxx/cty.dat in the xlog source package and
had assumed that it was what was being read (and knew that it hadn't changed).
There are two versions of the country files, a small one with just a
few callsign exceptions, and the "bigcty" one with the long list that
we are using now. xdx had assumed the file is smaller (while still
having the bigcty version in mind, I think):
/* Buffer size for reading in a single cty.dat record. Currently the
* entire cty.dat file is just under 80k bytes, so any single record should
* be much less than this value, but with additions of callsign exceptions
* record sizes will undoubtedly continue to grow.
*/
#define MAX_RECORD_SIZE 65536
-rw-r--r-- 1 myon myon 288472 25. Nov 03:38 bigcty/cty.csv
-rw-r--r-- 1 myon myon 325766 25. Nov 03:38 bigcty/cty.dat
I'm adding a check to hamradio-files to see if our new assumption of
not exceeding 128kB holds:
https://salsa.debian.org/debian-hamradio-team/hamradio-files/-/commit/8af7facd536485e56d86bac10d214108f2e0c075
For those curious about the longest lines...
$ cat hamradio-files-20221125/bigcty/cty.csv | awk '{ print length, $0 }' | cut -d',' -f1-2 | sort -rn -s | head -10
67780 K,United States
43579 UA9,Asiatic Russia
27662 BY,China
24590 LU,Argentina
18650 UA,European Russia
7790 GM,Scotland
6818 GW,Wales
5564 KL,Alaska
5208 KH6,Hawaii
3776 VE,Canada
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:06:06 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,370 |