[Xastir-dev] Bug 1698474 Re: [Xastir] Stable release timing?

[Tom Russo]

On Mon, Apr 16, 2007 at 08:56:15AM -0700, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> 
> I also mentioned that Tom Russo had found a bug that he or I will
> try to solve soon, hopefully before we put out the next stable
> release.  Right now that's what I'm waiting for.
> 

I had a few minutes to kill, so added a little more debugging code to see
if I could see what's happening with the object-deletion-screws-sorted-list
issue.

It appears that the code in db.c's data_add function allows the possibilty of 
changing the  timestamp on a record without resorting the list.  This is 
very bad, I think.  But there are comments that indicate that there are
reasons *not* to move a station record around in the list (which sorta
makes no sense, either the list is kept sorted, or it can't be called a sorted
list!).  See, for example, db.c around line 11479, in which it is stated that
it is necessary not to move any of our own object data around in the sorted 
list.  The code in data_add is very convoluted and I'm not sure how one would
go about correcting this without breaking something else.

The debugging output I just created shows this in action.  I created an 
object "Bug1" and then deleted it.  Here's the output:

TIME-SORTED LIST SANITY CHECK FAILED!
 At least one station left after expire with time older than 1176746701
   Station name: KE5CUW
   Last heard time 1176746694
   Seconds ago: 607
   Seconds older than expire time: 7
--------
        Time-sorted list dump 
         Call Sign:     sec_heard       date/time
        KM5VY-6 0       12/31 17:00:00
        Bug1    1176747288      04/16 12:14:48
        07105500        1176746293      04/16 11:58:13
        07105530        1176746294      04/16 11:58:14
        CO025   1176746302      04/16 11:58:22
        CO026   1176746302      04/16 11:58:22
        CO027   1176746302      04/16 11:58:22
        CO028   1176746303      04/16 11:58:23
        CO030   1176746303      04/16 11:58:23
        CO031   1176746304      04/16 11:58:24
        09165000        1176746316      04/16 11:58:36
        CO093   1176746316      04/16 11:58:36
        09359500        1176746316      04/16 11:58:36
        KC5EVE-14       1176746318      04/16 11:58:38
        WM5Z-2  1176746318      04/16 11:58:38
        CO100   1176746318      04/16 11:58:38
        CO103   1176746319      04/16 11:58:39
        CO104   1176746320      04/16 11:58:40
        07154500        1176746320      04/16 11:58:40
 [...]

Note that Bug1 is shown as being very recent, but is at the very OLDEST slot
(other than my own station) in the sorted list ahead of much
older entries, meaning that no stations will ever be expired as long as this 
element is there.

This debugging output might help pin down other sources of problems such as
Curt's firenet session with t/oint filter.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick