assertion failed: store_dir_diskd.c:839: "rb->flags.need_to_validate"

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Fri, 6 Jul 2001 19:07:00 +0200

 I'd log a bugreport for others to look into it also. I'm somewhat at loss.

 In short, 2.4 and latest HEAD fails to rebuild from CLEAN swaplogs when
 using diskd, and on Solaris. Seems that on Linux same compile works,
 although this seems very strange.

 Looking into code makes me think that this condition can only occur if
 during cleanlog write during earlier shutdown squid managed to write
 out bad cleanlog.

 Or, while reading cleanlog during startup, that log is appended with
 new objects.

 I'm not sure which one it is (I tend to think the latter), and how to
 fix it.

2001/07/06 16:28:05| Store rebuilding is 28.3% complete
2001/07/06 16:28:20| Store rebuilding is 31.4% complete
2001/07/06 16:28:35| Store rebuilding is 34.2% complete
2001/07/06 16:28:50| Store rebuilding is 37.3% complete
2001/07/06 16:29:05| Store rebuilding is 40.7% complete
2001/07/06 16:29:06| CACHEMGR: <unknown>@194.106.96.7 requesting 'info'
2001/07/06 16:29:08| CACHEMGR: <unknown>@194.106.96.7 requesting 'info'
2001/07/06 16:29:11| CACHEMGR: <unknown>@194.106.96.7 requesting 'info'
2001/07/06 16:29:12| WARNING: newer swaplog entry for dirno 1, fileno 000B21D4
2001/07/06 16:29:12| assertion failed: store_dir_diskd.c:839: "rb->flags.need_to_validate"
2001/07/06 16:29:34| Starting Squid Cache version 2.5.DEVEL for i386-pc-solaris2.8...

 Relevant part in fs/diskd/store_dir_diskd.c:

        e = storeGet(s.key);
        used = storeDiskdDirMapBitTest(SD, s.swap_filen);
        /* If this URL already exists in the cache, does the swap log
         * appear to have a newer entry? Compare 'lastref' from the
         * swap log to e->lastref. */
        disk_entry_newer = e ? (s.lastref > e->lastref ? 1 : 0) : 0;
        if (used && !disk_entry_newer) {
            /* log entry is old, ignore it */
            rb->counts.clashcount++;
            continue;
        } else if (used && e && e->swap_filen == s.swap_filen && e->swap_dirn == SD->index) {
            /* swapfile taken, same URL, newer, update meta */
            if (e->store_status == STORE_OK) {
                e->lastref = s.timestamp;
                e->timestamp = s.timestamp;
                e->expires = s.expires;
                e->lastmod = s.lastmod;
                e->flags = s.flags;
                e->refcount += s.refcount;
                storeDiskdDirUnrefObj(SD, e);
            } else {
                debug_trap("storeDiskdDirRebuildFromSwapLog: bad condition");
                debug(20, 1) ("\tSee %s:%d\n", __FILE__, __LINE__);
            }
            continue;
        } else if (used) {
            /* swapfile in use, not by this URL, log entry is newer */
            /* This is sorta bad: the log entry should NOT be newer at this
             * point. If the log is dirty, the filesize check should have
             * caught this. If the log is clean, there should never be a
             * newer entry. */
            debug(20, 1) ("WARNING: newer swaplog entry for dirno %d, fileno %08X\n",
                SD->index, s.swap_filen);
            /* I'm tempted to remove the swapfile here just to be safe,
             * but there is a bad race condition in the NOVM version if
             * the swapfile has recently been opened for writing, but
             * not yet opened for reading. Because we can't map
             * swapfiles back to StoreEntrys, we don't know the state
             * of the entry using that file. */
            /* We'll assume the existing entry is valid, probably because
             * were in a slow rebuild and the the swap file number got taken
             * and the validation procedure hasn't run. */
>> assert(rb->flags.need_to_validate);
            rb->counts.clashcount++;
            continue;
        } else if (e && !disk_entry_newer) {

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri Jul 06 2001 - 11:12:40 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:06 MST