bugXlog - Bugs: bug #27628, Many QSOs apparently never written...

 
 

bug #27628: Many QSOs apparently never written to disk. Happened twice

Submitted by:  None
Submitted on:  Thu 08 Oct 2009 08:16:49 AM UTC  
 
Category: GeneralSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: ClosedRelease: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 08 Oct 2009 08:18:35 AM UTC, comment #1:

Woops. Forgot to sign. I'm LA4RT Jon Kåre Hellan. email at qrz.com

Anonymous
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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pa4tu (Updated the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 04 Nov 2012 10:16:45 AM UTCpa4tuOpen/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1