Principal DB Size

[Jeffrey Hutzelman]

On Friday, June 18, 2004 15:46:16 -0400 Ken Raeburn <raeburn at mit.edu> wrote:

> On Jun 17, 2004, at 20:26, Brian Sathianathan wrote:
>
>> I tried pointing the kerberos database to a different  db ( Berkely Db
>> 4.2) during the ./configure stage didn't help I still hit that limit.
>> I also went through the database related source code functions
>> (krb5_db2_db_put_principal.krb5_db2_db_get_principal )  looking for
>> some integer that might overflow( because 4.2G sounded like an integer
>> limit) didn't find any type limitation there . The type limitations
>> that you mentioned are they in the database code or the interface code
>> , if they are in the database code it self , Can you give me some
>> functions or module names you suspect the limitation might be in
>
> My first guess was "anything computing an offset to pass to lseek".  I
> checked our db2 code and found a couple places where nonzero offsets were
> being computed, and found it was multiplying pagesize*pagenum without
> checking for overflow.  I don't know if that's actually the problem (I'll
> have to free up a few gigabytes to run the tests), and the new db code,
> if it's got large file support, really should take care of such issues.
>
> Without such a check, corruption seems likely; with a check, it ought to
> result in an error when storing the new record, but no corruption of the
> on-disk database.  With large file support, like I said, it just
> shouldn't be a problem, but apparently that's not the case...

If the values you are multiplying do not have 64-bit type, then the result 
will not have 64-bit type, even if you are passing it to a function which 
takes a 64-bit parameter -- the type of an expression does not depend on 
what you are doing with its value.  Casting pagesize to the type of the 
argument (loff_t or some such?) may make the problem go away.

-- Jeff