Subject: Re: bug#11236: 24.1.50; Maximum buffer size exceeded

From: Peter Dyballa <[email-masked]>
Date: Mon, 16 Apr 2012 22:12:43 +0200

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.