Thu 08 Oct 2009 08:16:49 AM UTC, original submission:
On two separate occasions, I've lost a large number of QSOs logged with xlog.
The first time was IARU HF contest 2009. A couple of hundred QSOs made at the end of the contest were missing from the log after stopping and starting xlog. It happened again during SAC CW 2009, 252 QSOs from the last 6 hours turned out to be missing.
The first time, the system had been stressed, and I had had some difficulty shutting xlog down in a controlled manner. There were no stress issues the second time.
I use autosave every 5 minutes. I do not use "save with every log entry", but I very frequently save manually.
The system is a Debian sid on a 2002 vintage IBM Thinkpad T-23 with a 1.13 GHz Pentium III CPU and 384 megs of memory. xlog version is 2.0.3-1.
The way I work is to log the contest in my regular log, and export the relevant part afterwards. The first time, there were about 8000 QSOs in the log when I started. the second time, only 3245. Another log with 6048 QSOs was visible in another tab. I worked 831 QSOs. 579 survived, the final 252 were lost, bringing the size of the log to 3824.
I tried to check if it was a straight size issue, but that isn't what it looks like. I added more than 300 QSOs manually, one by one, but that wasn't enough to reproduce.
Most of the time when I'm "contesting", I only work a couple of
hundred QSOs. But I did log about 600 with xlog in SAC CW 2008, without problems. May be something changed in xlog, or in
the stack below it?
Trying to reconstruct versions from changelog.Debian.gz, it looks like xlog version was Debian 2.0.2-1 the first time, 2.0.3-1 the second time. gtk version was 2.16.4-1 the first time, 2.16.5-1 the second time. glib version was 2.20.4-1 both times.
Wild guesses are usually a bad idea. But could glib/gtk have changed underlying semantics of the mechanism xlog uses to schedules saving? Or could memory overwrites have disconnected the signal/timeout used for saving?
I did see the "dirty" asterisk flash on and off.
|