[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11236: 24.1.50; Maximum buffer size exceeded
From: |
Peter Dyballa |
Subject: |
bug#11236: 24.1.50; Maximum buffer size exceeded |
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.
- bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/13
- bug#11236: 24.1.50; Maximum buffer size exceeded, Eli Zaretskii, 2012/04/13
- bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/14
- bug#11236: 24.1.50; Maximum buffer size exceeded, Eli Zaretskii, 2012/04/14
- bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/16
- bug#11236: 24.1.50; Maximum buffer size exceeded, Eli Zaretskii, 2012/04/16
- bug#11236: 24.1.50; Maximum buffer size exceeded,
Peter Dyballa <=
- bug#11236: 24.1.50; Maximum buffer size exceeded, Andreas Schwab, 2012/04/16
- bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/16
bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/14
bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/15
bug#11236: 24.1.50; Maximum buffer size exceeded, Peter Dyballa, 2012/04/15
bug#11236: 24.1.50; Maximum buffer size exceeded, Glenn Morris, 2012/04/16