1 Reply Latest reply: Apr 18, 2013 6:40 AM by userBDBDMS-Oracle RSS

    Extremely minor bug in src/os_windows/os_fid.c    :   __os_fileid()

      I have berkeley db 5.3.21. The __os_fileid routine for windows contains a big if block that attempts to build some random bits into the fileid. The code looks like this:

      if (unique_okay) {
                /* Add in 32-bits of (hopefully) unique number. */
                __os_unique_id(env, &tmp);
                for (p = (u_int8_t *)&tmp, i = sizeof(u_int32_t); i > 0; --i)
                     fidp++ = p++;

                * Initialize/increment the serial number we use to help
                * avoid fileid collisions. Note we don't bother with
                * locking; it's unpleasant to do from down in here, and
                * if we race on this no real harm will be done, since the
                * finished fileid has so many other components.
                * We use the bottom 32-bits of the process ID, hoping they
                * are more random than the top 32-bits (should we be on a
                * machine with 64-bit process IDs).
                * We increment by 100000 on each call as a simple way of
                * randomizing; simply incrementing seems potentially less
                * useful if pids are also simply incremented, since this
                * is process-local and we may be one of a set of processes
                * starting up. 100000 pushes us out of pid space on most
                * 32-bit platforms, and has few interesting properties in
                * base 2.
                if (DB_GLOBAL(fid_serial) == 0) {
                     __os_id(env->dbenv, &pid, NULL);
                     DB_GLOBAL(fid_serial) = (u_int32_t)pid;
                } else
                     DB_GLOBAL(fid_serial) += 100000;

      // end of if block here. fid_serial is computed but never used.

      I added the last comment. The bits in fid_serial never make it into the file id, that I can see. This code looks a lot like a similar routine in src/os/os_fid.c, except that version does use the fid_serial result:

                for (p = (u_int8_t *)
                &DB_GLOBAL(fid_serial), i = sizeof(u_int32_t); i > 0; --i)
                     fidp++ = p++;

      It looks like this same bit copy ought to be in the windows version.

      I don't know how I will sleep tonight knowing that my new fileids don't have a few bits incrementing by 100000 on every call.


      Edited by: hhowe29 on Apr 17, 2013 6:15 PM

      Edited by: hhowe29 on Apr 17, 2013 6:16 PM