Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 23 Feb 2023 11:53:49 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        "Simon J. Gerraty" <sjg@juniper.net>
Cc:        Bryan Drewery <bdrewery@FreeBSD.org>, Current FreeBSD <freebsd-current@FreeBSD.org>, Peter <pmc@citylink.dinoex.sub.org>
Subject:   Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence]
Message-ID:  <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com>
In-Reply-To: <B11DA944-90E7-42D9-81A4-145686767305@yahoo.com>
References:  <B74790D9-FBC2-4818-BEAF-34E5B705C460@yahoo.com> <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <DB0C7B41-2101-4C5C-BFC8-3C95CC0B9F6F@yahoo.com> <73088.1611797582@kaos.jnpr.net> <CB7040D0-3BF4-496F-A54F-87E5378016E0@yahoo.com> <F6BF110D-7855-4A10-A53F-52B34282234F@yahoo.com> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <B11DA944-90E7-42D9-81A4-145686767305@yahoo.com>
index | next in thread | previous in thread | raw e-mail 

cached_realpath only reports its "cached_realpath:" notice
(not the purging one) when it does not find the value via
HashTable_FindValue and so does a HashTable_Set :

const char *
cached_realpath(const char *pathname, char *resolved)
{
        const char *rp;

        if (pathname == NULL || pathname[0] == '\0')
                return NULL;

        rp = HashTable_FindValue(&cached_realpaths, pathname);
        if (rp != NULL) {
                /* a hit */
                strncpy(resolved, rp, MAXPATHLEN);
                resolved[MAXPATHLEN - 1] = '\0';
                return resolved;
        }

        rp = realpath(pathname, resolved);
        if (rp != NULL) {
                HashTable_Set(&cached_realpaths, pathname, bmake_strdup(rp));
                DEBUG2(DIR, "cached_realpath: %s -> %s\n", pathname, rp);
                return resolved;
        }

        /* should we negative-cache? */
        return NULL;
}

cached_realpaths is global:

static HashTable cached_realpaths;

So with -ddM why do I see lots of "cached_realpath:"
notices for the same path? For example:

# grep "tmp/legacy/usr/sbin/ln\>" /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd64-nodbg-clang-amd64-host-2023-02-23:10:20:26 | more
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/awk/awkgram.tab.h.meta: 22: file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln' is newer than the target...
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin/ln
   Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/awk/awkgram.tab.h.meta: 22: file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln' is newer than the target...
. . .

A possible cause is something I ran into while looking around:

/* A read-only range of a character array, NOT null-terminated. */
typedef struct Substring {
        const char *start;
        const char *end;
} Substring;
. . .
MAKE_STATIC Substring
Substring_Init(const char *start, const char *end)
{
        Substring sub;

        sub.start = start;
        sub.end = end;
        return sub;
}
. . .
/* Find the entry corresponding to the key, or return NULL. */
HashEntry *
HashTable_FindEntry(HashTable *t, const char *key)
{
        const char *keyEnd;
        unsigned int h = Hash_String(key, &keyEnd);
        return HashTable_Find(t, Substring_Init(key, keyEnd), h);
}
. . .
/* A read-only range of a character array, NOT null-terminated. */
typedef struct Substring {
        const char *start;
        const char *end;
} Substring;
. . .
MAKE_STATIC Substring
Substring_Init(const char *start, const char *end)
{
        Substring sub;

        sub.start = start;
        sub.end = end;
        return sub;
}
. . .
/* Find the entry corresponding to the key, or return NULL. */
HashEntry *
HashTable_FindEntry(HashTable *t, const char *key)
{
        const char *keyEnd;
        unsigned int h = Hash_String(key, &keyEnd);
        return HashTable_Find(t, Substring_Init(key, keyEnd), h);
}
. . .
/* This hash function matches Gosling's Emacs and java.lang.String. */
static unsigned int
Hash_String(const char *key, const char **out_keyEnd)
{
        unsigned int h;
        const char *p;

        h = 0;
        for (p = key; *p != '\0'; p++)
                h = 31 * h + (unsigned char)*p;
        
        *out_keyEnd = p;
        return h;
}

But after the loop: *p=='\0' so *out_keyEnd=='\0'
and the FindEntry Substring_Init(key, keyEnd) ends
up including the '\0' byte.

But note that the h in Hash_String did not include the
'\0' byte. Call this h value h_VALUE0 for later reference.
Then look at:

/* This hash function matches Gosling's Emacs and java.lang.String. */
unsigned int
Hash_Substring(Substring key)
{
        unsigned int h;
        const char *p;
        
        h = 0;
        for (p = key.start; p != key.end; p++)
                h = 31 * h + (unsigned char)*p;
        return h;
}

This h does include the '\0' byte so h==(unsigned int)(31*h_VALUE0).

I expect the mismatched hash values explain the repeated
"cached_realpath:" notices for the same path: inserted
but never found.

===
Mark Millard
marklmi at yahoo.com
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?266ED18F-9249-46BB-BF96-1D4C5B46FCFC>