bug#11236: 24.1.50; Maximum buffer size exceeded

[Peter Dyballa]

Am 16.04.2012 um 18:54 schrieb Eli Zaretskii:

> > I decided to perform something I understand: I modified the function
> > buffer_overflow () to report where it was called. It happens in src/
> > fileio.c on line #3424, so buf_growth_max < likely_growth is true.
>
> Can you show all the other variables involved in the calculations
> leading to line 3424 of fileio.c?


The GUD documentation mentions a few key bindings – C-x C-a C-p can  
(cleverly) print values!

        (gdb) pr buf_growth_max
        The history is empty.
        buf_growth_max < likely_growth = $1 = 1
        buf_growth_max = $2 = 2147483646
        likely_growth = $3 = 5425793530331136
        likely_end = $4 = 5425793530331136
        beg_offset = $5 = 0
        BUF_BYTES_MAX = No symbol "BUF_BYTES_MAX" in current context.
        buf_bytes = $6 = 1
        not_regular = $7 = 0
        end_offset = $8 = 5425793530331136
        st.st_size = $9 = 5425793530331136

The values of likely_growth, likely_end, end_offset, and st.st_size  
are the same, ≈ 5·10^15 – this is an unlikely value for a 50 GB  
partition on an 80 GB disk...

I configured --with-wide-int. When GDB hits the breakpoint it prints  
out:

	Breakpoint 2, Finsert_file_contents (filename=-9223372036828660272,  
visit=4611686018452566072, beg=4611686018452566072,  
end=4611686018452566072, replace=4611686018452566072) at fileio.c:3424

It seems to me that the variables visit, beg, end, and replace, all  
equal, are byte positions in the file – but almost 5·10^18 cannot be  
correct. These values come partially from the struct st, which has:

  st_dev = 234881028,
  st_mode = 33188,
  st_nlink = 1,
  st_ino = 43973072,
  st_uid = 501,
  st_gid = 80,
  st_rdev = 0,

  st_size = 5425793530331136,
  st_blocks = 10617159159808,

Ls delivers:

        gls -lin lisp/loaddefs.el
        43973072 -rw-r--r-- 1 501 80 1263291 16. Apr 10:40 lisp/loaddefs.el

So some values are OK. And it's obvious that the error seems to happen  
earlier, I think, when the file is opened – the DEFUN ("insert-file- 
contents", ...) is not opening the file. The variable  
Sinsert_file_contents, one of the DEFUN's arguments, has:

  size = 4611686018427404288,

I can dig further... with some help.

--
Greetings

  Pete

Theory and practice are the same, in theory, but, in practice, they  
are different.