Re: [exim-dev] test suite - new quota error

Góra strony
Delete this message
Reply to this message
Autor: John Jetmore
Data:  
Dla: exim-dev
Temat: Re: [exim-dev] test suite - new quota error
On Tue, Jun 8, 2010 at 8:52 PM, Phil Pennock <exim-dev@???> wrote:
> On 2010-06-08 at 09:43 -0400, John Jetmore wrote:
>> I have another new error in the test suite.  I looked at the checkins
>> for appendfile.c and didn't see an obvious culprit, but having not
>> done the work and having done it last night when I was sleepy, I may
>> have missed the obvious.
>>
>> Test 5007
>>
>> paniclog (which is suppoed to be empty):
>> 2010-06-08 08:34:56 1OLyxE-00007l-Gt == userx@??? R=r1 T=t1 defer
>> (-1): quota value 3221225472 is too large (overflow) in t1 transport
>>
>> mainlog (note that the diff is opposite of what I would expect, the
>> "-" lines are the actual output, the "+" lines are the expected
>> output):
>> --- test-mainlog-munged 2010-06-08 08:41:27.000000000 -0500
>> +++ log/5007    2006-02-10 10:29:20.000000000 -0600
>> @@ -1,2 +1,3 @@
>>  1999-03-02 09:44:33 10HmaX-0005vi-00 <= CALLER@??? U=CALLER P=local S=sss
>> -1999-03-02 09:44:33 10HmaX-0005vi-00 == userx@??? R=r1 T=t1 defer
>> (-1): quota value 3221225472 is too large (overflow) in t1 transport
>> +1999-03-02 09:44:33 10HmaX-0005vi-00 => userx <userx@???> R=r1 T=t1
>> +1999-03-02 09:44:33 10HmaX-0005vi-00 Completed
>>
>> Phil, does this leap out at you from any changes?
>
> No.
>
> So, the problem appears to be that a 3G quota is exceeding the quota
> size limit for Exim.  So, unexpectedly: sizeof(off_t) <= 4
>
> What does { exim -bV } report as the size of off_t in the test
> environment?
>
> Per ChangeLog for 4.61, PH/21 & PH/22, the panic is expected and the
> tests should not be invoked unless off_t is reported to be large enough.
>
> The closest I've come to touching this is cleanup in the format strings
> for reporting the sizes, in buildconfig.c.  I haven't done anything that
> would affect the system off_t size, which is what is explicitly being
> used in src/transports/appendfile.c.
>
> Something strange in $PATH where the version of Exim being asked for its
> size isn't the version invoked for the test?  Sorry, I really don't know
> the test suite.


I'm really confused by this. I've done some more looking, I'm hoping
you'll look at what I've found and that will lead closer to the heart
of the problem.

First, I think that your commit 1.17 for buildconfig broke some stuff.
Here's my exim -bV output for versions surrounding that quota error
showing up:

Believed last to work
Exim version 4.72 #1 built 03-Jun-2010 12:02:00
Size of off_t: 4

First Failure:
Exim version 4.72 #1 built 07-Jun-2010 21:47:01
Size of off_t: 28752091627388932

Now, I'm still not exactly sure why that relates to the quota stuff
(as you said, it's doing direct sizeof() tests), but it does appear
that the SIZE_T_FMT stuff you added somehow broke the -bV output. On
my test system, building from HEAD, here are the FMT's that are built
into config.h by buildconfig.c:

    #ifndef OFF_T_FMT
    #define OFF_T_FMT  "%ld"
    #define LONGLONG_T long int
    #endif


    #ifndef TIME_T_FMT
    #define TIME_T_FMT  "%ld"
    #endif


    #define SIZE_T_FMT  "%lld"


And here's the new -bV line using SIZE_T_FMT:

    fprintf(f, "Size of off_t: " SIZE_T_FMT "\n", sizeof(off_t));


And the buildconfig.c code for defining SIZE_T_FMT:

/* And for sizeof() results, size_t, which should with C99 be just %zu, deal
with C99 not being ubiquitous yet. Unfortunately. */

    #if __STDC_VERSION__ >= 199901L
    fprintf(new, "#define SIZE_T_FMT  \"%%zu\"\n");
    #else
    # ifdef PRIdMAX
    fprintf(new, "#define SIZE_T_FMT  \"%%" PRIdMAX "\"\n");
    # else
    if (sizeof(test_size_t) > sizeof (test_ulong_t))
      fprintf(new, "#define SIZE_T_FMT  \"%%llu\"\n");
    else
      fprintf(new, "#define SIZE_T_FMT  \"%%lu\"\n");
    # endif
    #endif


I think by process of elimination that means that lld is coming from
PRIdMAX (and the quick test I wrote confirms that PRIdMAX is lld).

So, I'm still not sure what's going on here, but could you revisit
your logic for building SIZE_T_FMT?

Thanks
--John