Re: Failing to read new mail

[Chong Yidong]

Richard Stallman <address@hidden> writes:

>     Could it be the 256Mb buffer size limit?  Even with an 88 Mb RMAIL
>     file, maybe something like multi-byte encoding or the decompression of
>     an attachment could push it over the limit.  Maybe (point) in
>
>      (rmail-decode-region start (point) mime-charset)
>
> What would happen, in such a case, is an error from whichever
> primitive tries to make the buffer too big.  If some bug failed to
> detect that, (point) would return a small number; it has no code to
> detect overflow.

I just noticed something else.  The reported error message,

  rmail-decode-region: Wrong type argument: number-or-marker-p, nil

refers to number-or-marker-p, not integer-or-marker-p.  This means
that there is a primitive inside rmail-decode-region calling
CHECK_NUMBER_OR_FLOAT_COERCE_MARKER on Qnil.  There are only 10
functions in Emacs that use CHECK_NUMBER_OR_FLOAT_COERCE_MARKER:

- Fbytecode in bytecode.c:1116

        case Beqlsign:
          {
            Lisp_Object v1, v2;
            BEFORE_POTENTIAL_GC ();
            v2 = POP; v1 = TOP;
            CHECK_NUMBER_OR_FLOAT_COERCE_MARKER (v1);
            CHECK_NUMBER_OR_FLOAT_COERCE_MARKER (v2);

- arithcompare in data.c:2236

  Lisp_Object
  arithcompare (num1, num2, comparison)
       Lisp_Object num1, num2;
       enum comparison comparison;
  {
    double f1 = 0, f2 = 0;
    int floatp = 0;

    CHECK_NUMBER_OR_FLOAT_COERCE_MARKER (num1);
    CHECK_NUMBER_OR_FLOAT_COERCE_MARKER (num2);

- arith_driver in data.c:2543
- float_arith_driver in data.c:2612
- Fmod in data.c:2761
- 1+ in data.c:2890
- 1- in data.c:2905

There is only one primitive in rmail-decode-region that could
plausibly be calling these functions: decode-coding-region.  So
somewhere inside this function must be a call to one of the above C
functions.