Package: emacs;
Reported by: jsynacek <at> redhat.com (Jan Synáček)
Date: Wed, 8 Jun 2016 10:22:01 UTC
Severity: important
Found in version 25.0.94
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23726 in the body.
You can then email your comments to 23726 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Wed, 08 Jun 2016 10:22:01 GMT) Full text and rfc822 format available.jsynacek <at> redhat.com (Jan Synáček):bug-gnu-emacs <at> gnu.org.
(Wed, 08 Jun 2016 10:22:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: jsynacek <at> redhat.com (Jan Synáček) To: bug-gnu-emacs <at> gnu.org Subject: 25.0.94; emacs 25.0.94 crashes Date: Wed, 08 Jun 2016 12:21:30 +0200
Emacs 25.0.94 crashes on the current (Jun 8) Fedora Rawhide. The crash
is reproducible with vanilla upstream sources.
gcc-6.1.1-2.fc25.x86_64
glibc-2.23.90-19.fc25.x86_64
Steps to reproduce:
1) configure --with-x=no
2) make; make install
3) emacs (or emacs -Q)
Note that the crash doesn't always happen. I suspect something fishy
going on with emacs' memory management, as can be seen from the
following.
Valgrind output:
==1274== Memcheck, a memory error detector
==1274== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1274== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1274== Command: /usr/bin/emacs-nox
==1274==
==1274== Invalid free() / delete / delete[] / realloc()
==1274== at 0x4C2FC47: realloc (vg_replace_malloc.c:785)
==1274== by 0x5628E0: lrealloc (alloc.c:1427)
==1274== by 0x561FCC: xrealloc (alloc.c:856)
==1274== by 0x5622CB: xpalloc (alloc.c:978)
==1274== by 0x40D34E: realloc_glyph_pool (dispnew.c:1344)
==1274== by 0x40E04D: adjust_frame_glyphs_for_frame_redisplay (dispnew.c:2006)
==1274== by 0x40D87B: adjust_frame_glyphs (dispnew.c:1791)
==1274== by 0x418A89: adjust_frame_size (frame.c:587)
==1274== by 0x4161EE: change_frame_size_1 (dispnew.c:5513)
==1274== by 0x416244: change_frame_size (dispnew.c:5545)
==1274== by 0x4172FD: init_display (dispnew.c:6083)
==1274== by 0x4E76AA: main (emacs.c:1549)
==1274== Address 0xc1b020 is in a rw- mapped file /usr/bin/emacs-25.0.94-nox segment
==1274==
emacs: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs
==1274==
==1274== HEAP SUMMARY:
==1274== in use at exit: 124,222 bytes in 729 blocks
==1274== total heap usage: 1,452 allocs, 723 frees, 678,431 bytes allocated
==1274==
==1274== LEAK SUMMARY:
==1274== definitely lost: 0 bytes in 0 blocks
==1274== indirectly lost: 0 bytes in 0 blocks
==1274== possibly lost: 0 bytes in 0 blocks
==1274== still reachable: 124,222 bytes in 729 blocks
==1274== suppressed: 0 bytes in 0 blocks
==1274== Rerun with --leak-check=full to see details of leaked memory
==1274==
==1274== For counts of detected and suppressed errors, rerun with: -v
==1274== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
GDB full backtrace:
Starting program: /usr/bin/emacs-nox
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGABRT, Aborted.
0x00007ffff58378d5 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: dnf debuginfo-install alsa-lib-1.1.1-1.fc25.x86_64 dbus-libs-1.11.2-1.fc25.x86_64 gmp-6.1.0-3.fc25.x86_64 gnutls-3.4.12-1.fc25.x86_64 gpm-libs-1.20.7-9.fc24.x86_64 libacl-2.2.52-11.fc24.x86_64 libattr-2.4.47-16.fc24.x86_64 libcap-2.25-2.fc25.x86_64 libffi-3.1-9.fc24.x86_64 libgcc-6.1.1-2.fc25.x86_64 libgcrypt-1.6.4-2.fc24.x86_64 libgpg-error-1.21-3.fc25.x86_64 libidn-1.32-2.fc24.x86_64 libjpeg-turbo-1.4.90-1.fc25.x86_64 libselinux-2.5-6.fc25.x86_64 libtasn1-4.8-1.fc25.x86_64 libxml2-2.9.3-3.fc24.x86_64 lz4-r131-2.fc24.x86_64 ncurses-libs-6.0-5.20160116.fc25.x86_64 nettle-3.2-2.fc24.x86_64 p11-kit-0.23.2-2.fc24.x86_64 pcre-8.39-0.1.RC1.fc25.x86_64 systemd-libs-230-2.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64 zlib-1.2.8-10.fc24.x86_64
#0 0x00007ffff58378d5 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
resultvar = 0
pid = 1204
selftid = 1204
#1 0x00007ffff58394da in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 10, 4160432, 140737488341312, 6096828, 140737488341744, 3, 3086, 30, 114, 140737488340512,
21627284, 16, 21627281, 15, 14}}, sa_flags = -11336, sa_restorer = 0x0}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00000000005605b8 in re_match_2_internal (bufp=0xba9f18 <searchbufs+2552>, string1=0x0, size1=0, string2=0x14a30e0 "/root/scratch/.", size2=15, pos=14, regs=0x0, stop=15)
at ../../src/regex.c:6223
mcnt = 3
reg = 1
end1 = 0x0
end2 = 0x14a30ef ""
end_match_1 = 0x0
end_match_2 = 0x14a30ef ""
d = 0x14a30ef ""
dend = 0x14a30ef ""
dfail = 0x14a30ee "."
p = 0x14a0194 "\n;\002\001z\r#"
pend = 0x14a024b ""
translate = 2
multibyte = 0 '\000'
target_multibyte = 1 '\001'
fail_stack = {stack = 0x7fffffffc620, size = 20, avail = 6, frame = 6}
num_regs = 1
regstart = 0x0
regend = 0x0
best_regs_set = 0
best_regstart = 0x0
best_regend = 0x0
match_end = 0x0
sa_avail = 13184
sa_count = 5
sa_must_free = false
#3 0x0000000000559504 in re_search_2 (bufp=0xba9f18 <searchbufs+2552>, str1=0x0, size1=0, str2=0x14a30e0 "/root/scratch/.", size2=15, startpos=14, range=1, regs=0x0, stop=15)
at ../../src/regex.c:4446
val = 39840
string1 = 0x0
string2 = 0x14a30e0 "/root/scratch/."
fastmap = 0xba9f58 <searchbufs+2616> ""
translate = 2
total_size = 15
endpos = 15
anchored_start = 0 '\000'
multibyte = 1 '\001'
#4 0x0000000000558b0b in re_search (bufp=0xba9f18 <searchbufs+2552>, string=0x14a30e0 "/root/scratch/.", size=15, startpos=0, range=15, regs=0x0) at ../../src/regex.c:4228
No locals.
#5 0x00000000005453d8 in fast_string_match_internal (regexp=9839060, string=20554964, table=0) at ../../src/search.c:476
val = 140737488345072
bufp = 0xba9f18 <searchbufs+2552>
#6 0x00000000004e3be7 in fast_string_match (regexp=9839060, string=20554964) at ../../src/lisp.h:4008
No locals.
#7 0x000000000052bc85 in Ffind_file_name_handler (filename=20554964, operation=17376) at ../../src/fileio.c:292
string = 9839060
match_pos = 17376
handler = 4750192
operations = 16881011
elt = 16880035
chain = 16880019
inhibited_handlers = 0
result = 0
pos = -1
#8 0x000000000052c865 in Fexpand_file_name (name=20554964, default_directory=0) at ../../src/fileio.c:809
nm = 0xba9ae0 <searchbufs+1472> "\260\367I\001"
nmlim = 0x589b6f <push_handler_nosignal+195> "H\211\302H\213E\370H\211\220\b\001"
newdir = 0x7fffffffd910 ""
newdirlim = 0xe <error: Cannot access memory at address 0xe>
target = 0x100bd4ff0 <error: Cannot access memory at address 0x100bd4ff0>
tlen = 5806737
pw = 0x9ba0
length = 14
nbytes = 20554992
handler = 5119553
result = 0
handled_name = 11820231
multibyte = false
hdir = 21611136
sa_avail = 16384
sa_count = 5
sa_must_free = false
#9 0x00000000005899a8 in internal_condition_case_2 (bfun=0x52c7f3 <Fexpand_file_name>, arg1=20554964, arg2=0, handlers=39840, hfun=0x590563 <Fidentity>) at ../../src/eval.c:1360
val = 5119553
c = 0x149c280
#10 0x000000000053a47d in Ffile_attributes (filename=20554964, id_format=0) at ../../src/dired.c:902
encoded = 5121337
handler = 8840264
#11 0x000000000058cd30 in Ffuncall (nargs=2, args=0x7fffffffdb10) at ../../src/eval.c:2696
internal_argbuf = {20554964, 0, 12406768, 1785210630162692608, 0, 0, 10035109, 50}
fun = 8840269
original_fun = 18192
funcar = 0
numargs = 1
lisp_numargs = 6
val = 1
internal_args = 0x7fffffffda90
count = 4
#12 0x00000000005d13d7 in exec_byte_code (bytestr=10035076, vector=10035109, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffdfc0) at ../../src/bytecode.c:880
targets = {0x5d52bb <exec_byte_code+19422>, 0x5d531a <exec_byte_code+19517>, 0x5d531c <exec_byte_code+19519>, 0x5d531e <exec_byte_code+19521>, 0x5d5320 <exec_byte_code+19523>,
0x5d5320 <exec_byte_code+19523>, 0x5d5391 <exec_byte_code+19636>, 0x5d540c <exec_byte_code+19759>, 0x5d0b86 <exec_byte_code+1193>, 0x5d0b88 <exec_byte_code+1195>,
0x5d0b8a <exec_byte_code+1197>, 0x5d0b8c <exec_byte_code+1199>, 0x5d0b8e <exec_byte_code+1201>, 0x5d0b8e <exec_byte_code+1201>, 0x5d0b97 <exec_byte_code+1210>,
0x5d0b4f <exec_byte_code+1138>, 0x5d1097 <exec_byte_code+2490>, 0x5d1099 <exec_byte_code+2492>, 0x5d109b <exec_byte_code+2494>, 0x5d109d <exec_byte_code+2496>,
0x5d109f <exec_byte_code+2498>, 0x5d109f <exec_byte_code+2498>, 0x5d10dd <exec_byte_code+2560>, 0x5d10a8 <exec_byte_code+2507>, 0x5d12c2 <exec_byte_code+3045>,
0x5d12c4 <exec_byte_code+3047>, 0x5d12c6 <exec_byte_code+3049>, 0x5d12c8 <exec_byte_code+3051>, 0x5d12ca <exec_byte_code+3053>, 0x5d12ca <exec_byte_code+3053>,
0x5d1273 <exec_byte_code+2966>, 0x5d128d <exec_byte_code+2992>, 0x5d1395 <exec_byte_code+3256>, 0x5d1397 <exec_byte_code+3258>, 0x5d1399 <exec_byte_code+3260>,
0x5d139b <exec_byte_code+3262>, 0x5d139d <exec_byte_code+3264>, 0x5d139d <exec_byte_code+3264>, 0x5d1346 <exec_byte_code+3177>, 0x5d1360 <exec_byte_code+3203>,
0x5d146b <exec_byte_code+3470>, 0x5d146d <exec_byte_code+3472>, 0x5d146f <exec_byte_code+3474>, 0x5d1471 <exec_byte_code+3476>, 0x5d1473 <exec_byte_code+3478>,
0x5d1473 <exec_byte_code+3478>, 0x5d141c <exec_byte_code+3391>, 0x5d1436 <exec_byte_code+3417>, 0x5d254f <exec_byte_code+7794>, 0x5d23d7 <exec_byte_code+7418>,
0x5d23cb <exec_byte_code+7406>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>,
0x5d52bb <exec_byte_code+19422>, 0x5d27dd <exec_byte_code+8448>, 0x5d28e5 <exec_byte_code+8712>, 0x5d2954 <exec_byte_code+8823>, 0x5d29c4 <exec_byte_code+8935>,
0x5d2a38 <exec_byte_code+9051>, 0x5d0ecf <exec_byte_code+2034>, 0x5d0f5c <exec_byte_code+2175>, 0x5d2ac1 <exec_byte_code+9188>, 0x5d0e12 <exec_byte_code+1845>,
0x5d0fd9 <exec_byte_code+2300>, 0x5d2b38 <exec_byte_code+9307>, 0x5d2bb5 <exec_byte_code+9432>, 0x5d2c0c <exec_byte_code+9519>, 0x5d2c89 <exec_byte_code+9644>,
0x5d2cea <exec_byte_code+9741>, 0x5d2de2 <exec_byte_code+9989>, 0x5d2e39 <exec_byte_code+10076>, 0x5d2eb6 <exec_byte_code+10201>, 0x5d2f56 <exec_byte_code+10361>,
0x5d2fad <exec_byte_code+10448>, 0x5d3004 <exec_byte_code+10535>, 0x5d3081 <exec_byte_code+10660>, 0x5d30fe <exec_byte_code+10785>, 0x5d317b <exec_byte_code+10910>,
0x5d321b <exec_byte_code+11070>, 0x5d327c <exec_byte_code+11167>, 0x5d32dd <exec_byte_code+11264>, 0x5d33d5 <exec_byte_code+11512>, 0x5d347a <exec_byte_code+11677>,
0x5d351f <exec_byte_code+11842>, 0x5d37ae <exec_byte_code+12497>, 0x5d3830 <exec_byte_code+12627>, 0x5d38b2 <exec_byte_code+12757>, 0x5d3934 <exec_byte_code+12887>,
0x5d39b6 <exec_byte_code+13017>, 0x5d3a17 <exec_byte_code+13114>, 0x5d3ac0 <exec_byte_code+13283>, 0x5d3b21 <exec_byte_code+13380>, 0x5d3b82 <exec_byte_code+13477>,
0x5d3be3 <exec_byte_code+13574>, 0x5d3d22 <exec_byte_code+13893>, 0x5d2218 <exec_byte_code+6971>, 0x5d3d90 <exec_byte_code+14003>, 0x5d3de7 <exec_byte_code+14090>,
0x5d3ed7 <exec_byte_code+14330>, 0x5d3f45 <exec_byte_code+14440>, 0x5d3fb3 <exec_byte_code+14550>, 0x5d400a <exec_byte_code+14637>, 0x5d4067 <exec_byte_code+14730>,
0x5d40c4 <exec_byte_code+14823>, 0x5d4129 <exec_byte_code+14924>, 0x5d52bb <exec_byte_code+19422>, 0x5d4190 <exec_byte_code+15027>, 0x5d41e2 <exec_byte_code+15109>,
0x5d4234 <exec_byte_code+15191>, 0x5d4286 <exec_byte_code+15273>, 0x5d42d8 <exec_byte_code+15355>, 0x5d432a <exec_byte_code+15437>, 0x5d2218 <exec_byte_code+6971>,
0x5d52bb <exec_byte_code+19422>, 0x5d4381 <exec_byte_code+15524>, 0x5d43e2 <exec_byte_code+15621>, 0x5d4439 <exec_byte_code+15708>, 0x5d4490 <exec_byte_code+15795>,
0x5d450d <exec_byte_code+15920>, 0x5d458a <exec_byte_code+16045>, 0x5d45e1 <exec_byte_code+16132>, 0x5d46ec <exec_byte_code+16399>, 0x5d4769 <exec_byte_code+16524>,
0x5d47e6 <exec_byte_code+16649>, 0x5d4863 <exec_byte_code+16774>, 0x5d48b5 <exec_byte_code+16856>, 0x5d52bb <exec_byte_code+19422>, 0x5d2131 <exec_byte_code+6740>,
0x5d1537 <exec_byte_code+3674>, 0x5d0caa <exec_byte_code+1485>, 0x5d166c <exec_byte_code+3983>, 0x5d17d4 <exec_byte_code+4343>, 0x5d1930 <exec_byte_code+4691>,
0x5d20ae <exec_byte_code+6609>, 0x5d20f1 <exec_byte_code+6676>, 0x5d1211 <exec_byte_code+2868>, 0x5d21c9 <exec_byte_code+6892>, 0x5d2255 <exec_byte_code+7032>,
0x5d22f8 <exec_byte_code+7195>, 0x5d2347 <exec_byte_code+7274>, 0x5d2599 <exec_byte_code+7868>, 0x5d2630 <exec_byte_code+8019>, 0x5d26d0 <exec_byte_code+8179>,
0x5d2745 <exec_byte_code+8296>, 0x5d14e0 <exec_byte_code+3587>, 0x5d490c <exec_byte_code+16943>, 0x5d49ac <exec_byte_code+17103>, 0x5d4a03 <exec_byte_code+17190>,
0x5d4a5a <exec_byte_code+17277>, 0x5d4ab1 <exec_byte_code+17364>, 0x5d4b08 <exec_byte_code+17451>, 0x5d4b85 <exec_byte_code+17576>, 0x5d4c02 <exec_byte_code+17701>,
0x5d4c7f <exec_byte_code+17826>, 0x5d4cfc <exec_byte_code+17951>, 0x5d4e61 <exec_byte_code+18308>, 0x5d4ede <exec_byte_code+18433>, 0x5d4f5b <exec_byte_code+18558>,
0x5d4fb2 <exec_byte_code+18645>, 0x5d502f <exec_byte_code+18770>, 0x5d50ac <exec_byte_code+18895>, 0x5d5111 <exec_byte_code+18996>, 0x5d5176 <exec_byte_code+19097>,
0x5d3c44 <exec_byte_code+13671>, 0x5d3ca5 <exec_byte_code+13768>, 0x5d51d7 <exec_byte_code+19194>, 0x5d524b <exec_byte_code+19310>, 0x5d52bb <exec_byte_code+19422>,
0x5d1a8c <exec_byte_code+5039>, 0x5d1b94 <exec_byte_code+5303>, 0x5d1cdb <exec_byte_code+5630>, 0x5d1e22 <exec_byte_code+5957>, 0x5d1f68 <exec_byte_code+6283>,
0x5d2d4b <exec_byte_code+9838>, 0x5d333e <exec_byte_code+11361>, 0x5d3e40 <exec_byte_code+14179>, 0x5d54ae <exec_byte_code+19921>, 0x5d552c <exec_byte_code+20047>,
0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d55d1 <exec_byte_code+20212>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>,
0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>,
0x5d52bb <exec_byte_code+19422>, 0x5d52bb <exec_byte_code+19422>, 0x5d5676 <exec_byte_code+20377> <repeats 64 times>}
count = 4
op = 1
vectorp = 0x991fa8 <pure+1192200>
stack = {
pc = 0xad7d00 <pure+2526816> "\356\357\f!\360P!\232\204-\001\361\362\002P\016D\"\026D\210\016E<\203T\001\r\324=\203>\001Ղ@\001\016C\331\332\333\334\335\336\006\006!\363\"\340\341%\016E\"\026E\210\f\203_\001\364\f!\024\202d\001\365\366\367\"\210\016F\332\370\371\335\336\005!\372\"\373$\216\374 \210)\210\375\376\377\"\210\201H", byte_string = 10035076,
byte_string_start = 0xad7be7 <pure+2526535> "\b\203\b", next = 0x0}
top = 0x7fffffffdb10
result = 64288067697
type = CATCHER
#13 0x000000000058d620 in funcall_lambda (fun=10035029, nargs=0, arg_vector=0x7fffffffdfc0) at ../../src/eval.c:2855
size = 5
val = 0
syms_left = 2
next = 2
lexenv = 12406768
count = 4
i = 140737354130560
optional = false
rest = false
#14 0x000000000058d398 in apply_lambda (fun=10035029, args=0, count=3) at ../../src/eval.c:2794
args_left = 0
i = 0
numargs = 0
arg_vector = 0x7fffffffdfc0
tem = 10035029
sa_avail = 16384
sa_count = 4
sa_must_free = false
#15 0x000000000058b8dd in eval_sub (form=17290403) at ../../src/eval.c:2211
fun = 10035029
val = 17141888
original_fun = 8666816
original_args = 0
funcar = 25104
count = 3
argvals = {12645440, 12245584, 5119553, 17141888, 140737488347504, 5824004, 0, 25104}
#16 0x000000000058adca in Feval (form=17290403, lexical=0) at ../../src/eval.c:1988
count = 2
#17 0x00000000004ea3c3 in top_level_2 () at ../../src/keyboard.c:1108
No locals.
#18 0x0000000000589869 in internal_condition_case (bfun=0x4ea3a0 <top_level_2>, handlers=16560, hfun=0x4e9e3e <cmd_error>) at ../../src/eval.c:1309
val = 5119553
c = 0x149c150
#19 0x00000000004ea408 in top_level_1 (ignore=0) at ../../src/keyboard.c:1116
No locals.
#20 0x0000000000589162 in internal_catch (tag=41088, func=0x4ea3c5 <top_level_1>, arg=0) at ../../src/eval.c:1074
val = 5119553
c = 0x1489540
#21 0x00000000004ea2f2 in command_loop () at ../../src/keyboard.c:1077
No locals.
#22 0x00000000004e9a00 in recursive_edit_1 () at ../../src/keyboard.c:684
count = 1
val = 5824079
#23 0x00000000004e9b96 in Frecursive_edit () at ../../src/keyboard.c:755
count = 0
buffer = 0
#24 0x00000000004e778b in main (argc=1, argv=0x7fffffffe4e8) at ../../src/emacs.c:1606
dummy = 0
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
--
Jan Synacek
Software Engineer, Red Hat
Glenn Morris <rgm <at> gnu.org>
to control <at> debbugs.gnu.org.
(Wed, 08 Jun 2016 15:32:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Wed, 08 Jun 2016 16:50:02 GMT) Full text and rfc822 format available.Message #10 received at 23726 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: jsynacek <at> redhat.com (Jan Synáček) Cc: 23726 <at> debbugs.gnu.org Subject: Re: bug#23726: 25.0.94; emacs 25.0.94 crashes Date: Wed, 08 Jun 2016 19:49:43 +0300
> From: jsynacek <at> redhat.com (Jan Synáček)
> Date: Wed, 08 Jun 2016 12:21:30 +0200
>
> Emacs 25.0.94 crashes on the current (Jun 8) Fedora Rawhide. The crash
> is reproducible with vanilla upstream sources.
>
> gcc-6.1.1-2.fc25.x86_64
> glibc-2.23.90-19.fc25.x86_64
>
> Steps to reproduce:
> 1) configure --with-x=no
> 2) make; make install
> 3) emacs (or emacs -Q)
>
> Note that the crash doesn't always happen. I suspect something fishy
> going on with emacs' memory management, as can be seen from the
> following.
>
> Valgrind output:
>
> ==1274== Memcheck, a memory error detector
> ==1274== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==1274== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==1274== Command: /usr/bin/emacs-nox
> ==1274==
> ==1274== Invalid free() / delete / delete[] / realloc()
> ==1274== at 0x4C2FC47: realloc (vg_replace_malloc.c:785)
> ==1274== by 0x5628E0: lrealloc (alloc.c:1427)
> ==1274== by 0x561FCC: xrealloc (alloc.c:856)
> ==1274== by 0x5622CB: xpalloc (alloc.c:978)
> ==1274== by 0x40D34E: realloc_glyph_pool (dispnew.c:1344)
> ==1274== by 0x40E04D: adjust_frame_glyphs_for_frame_redisplay (dispnew.c:2006)
> ==1274== by 0x40D87B: adjust_frame_glyphs (dispnew.c:1791)
> ==1274== by 0x418A89: adjust_frame_size (frame.c:587)
> ==1274== by 0x4161EE: change_frame_size_1 (dispnew.c:5513)
> ==1274== by 0x416244: change_frame_size (dispnew.c:5545)
> ==1274== by 0x4172FD: init_display (dispnew.c:6083)
> ==1274== by 0x4E76AA: main (emacs.c:1549)
> ==1274== Address 0xc1b020 is in a rw- mapped file /usr/bin/emacs-25.0.94-nox segment
> ==1274==
> emacs: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs
> ==1274==
> ==1274== HEAP SUMMARY:
> ==1274== in use at exit: 124,222 bytes in 729 blocks
> ==1274== total heap usage: 1,452 allocs, 723 frees, 678,431 bytes allocated
> ==1274==
> ==1274== LEAK SUMMARY:
> ==1274== definitely lost: 0 bytes in 0 blocks
> ==1274== indirectly lost: 0 bytes in 0 blocks
> ==1274== possibly lost: 0 bytes in 0 blocks
> ==1274== still reachable: 124,222 bytes in 729 blocks
> ==1274== suppressed: 0 bytes in 0 blocks
> ==1274== Rerun with --leak-check=full to see details of leaked memory
> ==1274==
> ==1274== For counts of detected and suppressed errors, rerun with: -v
> ==1274== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>
>
> GDB full backtrace:
>
> Starting program: /usr/bin/emacs-nox
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff58378d5 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
> 54 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> Missing separate debuginfos, use: dnf debuginfo-install alsa-lib-1.1.1-1.fc25.x86_64 dbus-libs-1.11.2-1.fc25.x86_64 gmp-6.1.0-3.fc25.x86_64 gnutls-3.4.12-1.fc25.x86_64 gpm-libs-1.20.7-9.fc24.x86_64 libacl-2.2.52-11.fc24.x86_64 libattr-2.4.47-16.fc24.x86_64 libcap-2.25-2.fc25.x86_64 libffi-3.1-9.fc24.x86_64 libgcc-6.1.1-2.fc25.x86_64 libgcrypt-1.6.4-2.fc24.x86_64 libgpg-error-1.21-3.fc25.x86_64 libidn-1.32-2.fc24.x86_64 libjpeg-turbo-1.4.90-1.fc25.x86_64 libselinux-2.5-6.fc25.x86_64 libtasn1-4.8-1.fc25.x86_64 libxml2-2.9.3-3.fc24.x86_64 lz4-r131-2.fc24.x86_64 ncurses-libs-6.0-5.20160116.fc25.x86_64 nettle-3.2-2.fc24.x86_64 p11-kit-0.23.2-2.fc24.x86_64 pcre-8.39-0.1.RC1.fc25.x86_64 systemd-libs-230-2.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64 zlib-1.2.8-10.fc24.x86_64
> #0 0x00007ffff58378d5 in __GI_raise (sig=sig <at> entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
> resultvar = 0
> pid = 1204
> selftid = 1204
> #1 0x00007ffff58394da in __GI_abort () at abort.c:89
> save_stage = 2
> act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 10, 4160432, 140737488341312, 6096828, 140737488341744, 3, 3086, 30, 114, 140737488340512,
> 21627284, 16, 21627281, 15, 14}}, sa_flags = -11336, sa_restorer = 0x0}
> sigs = {__val = {32, 0 <repeats 15 times>}}
> #2 0x00000000005605b8 in re_match_2_internal (bufp=0xba9f18 <searchbufs+2552>, string1=0x0, size1=0, string2=0x14a30e0 "/root/scratch/.", size2=15, pos=14, regs=0x0, stop=15)
> at ../../src/regex.c:6223
Thanks for the report, but I must say I'm confused wrt what's going on
here. The backtrace is from a call to 'abort', so it cannot be a
memory problem, at least not directly. And I'm not sure how valgrind
output is related to that, but in general you need to run temacs under
valgrind, not emacs, to avoid too many false positives.
bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Wed, 08 Jun 2016 17:33:02 GMT) Full text and rfc822 format available.Message #13 received at 23726 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Jan Synáček <jsynacek <at> redhat.com> Cc: Florian Weimer <fweimer <at> redhat.com>, 23726 <at> debbugs.gnu.org Subject: Re: Bug#23726: emacs 25.0.94 crashes Date: Wed, 8 Jun 2016 10:32:06 -0700
[Message part 1 (text/plain, inline)]
Has Rawhide incorporated some of Florian Weimer's malloc patches? If so, this is almost surely causing the problem. I will CC: Florian to give him a heads-up. See: https://sourceware.org/ml/libc-alpha/2016-06/msg00211.html https://sourceware.org/bugzilla/show_bug.cgi?id=19564 I am surprised that you can use valgrind. Valgrind does not work on Emacs in Fedora 23 because it mishandles the way Emacs dumps and restores. I can use Valgrind only on temacs, not on Emacs itself. The fact that you can use Valgrind on a dumped Emacs suggests that some of the malloc patches have been installed on Rawhide. For what it's worth, when I try to use valgrind on Fedora 23, I run into what appears to be a valgrind bug that prevents Emacs from working. I just now filed it here: https://bugzilla.redhat.com/show_bug.cgi?id=1344082 I ran valgrind as follows: valgrind --log-fd=3 --suppressions=valgrind.supp ./temacs 3>/tmp/vg.log with the attached valgrind.supp file, and Emacs (emacs-25 branch, built with 'configure --with-x=no') says "Failed select: Bad address" due to the valgrind bug. How do you use valgrind on Rawhide?
[valgrind.supp (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Wed, 08 Jun 2016 18:46:02 GMT) Full text and rfc822 format available.Message #16 received at 23726 <at> debbugs.gnu.org (full text, mbox):
From: Florian Weimer <fweimer <at> redhat.com> To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček <jsynacek <at> redhat.com> Cc: 23726 <at> debbugs.gnu.org Subject: Re: Bug#23726: emacs 25.0.94 crashes Date: Wed, 8 Jun 2016 20:34:58 +0200
On 06/08/2016 07:32 PM, Paul Eggert wrote: > Has Rawhide incorporated some of Florian Weimer's malloc patches? If so, > this is almost surely causing the problem. I will CC: Florian to give > him a heads-up. See: > > https://sourceware.org/ml/libc-alpha/2016-06/msg00211.html That's not the patch, it's not even in upstream master. If that patch was in, you wouldn't see the problem anymore because Emacs' internal malloc would be used. The problem is that the realloc implementation for dumped chunks is incorrect; that bit is already in glibc master and rawhide. I think I can see what is wrong: The size computation for the old chunk size in realloc is wrong, and the trailing sizeof (size_t) bytes are not copied. Fortunately, it's not a conceptual problem with the heap rewriter. > I am surprised that you can use valgrind. The valgrind failure is typical of what you get with a dumped Emacs. valgrind intercepts realloc and returns 0 because an off-heap pointer is detected. Florian
bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Wed, 08 Jun 2016 18:53:02 GMT) Full text and rfc822 format available.Message #19 received at 23726 <at> debbugs.gnu.org (full text, mbox):
From: Florian Weimer <fweimer <at> redhat.com> To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček <jsynacek <at> redhat.com> Cc: 23726 <at> debbugs.gnu.org Subject: Re: Bug#23726: emacs 25.0.94 crashes Date: Wed, 8 Jun 2016 20:52:42 +0200
On 06/08/2016 08:34 PM, Florian Weimer wrote: > The problem is that the realloc implementation for dumped chunks is > incorrect; that bit is already in glibc master and rawhide. I think I > can see what is wrong: The size computation for the old chunk size in > realloc is wrong, and the trailing sizeof (size_t) bytes are not copied. > Fortunately, it's not a conceptual problem with the heap rewriter. glibc patch posted: https://sourceware.org/ml/libc-alpha/2016-06/msg00261.html The same dumped binary crashes before this patch is applied, and works afterwards. Jan, thanks for reporting this. Florian
Paul Eggert <eggert <at> cs.ucla.edu>:jsynacek <at> redhat.com (Jan Synáček):Message #24 received at 23726-done <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Florian Weimer <fweimer <at> redhat.com>, Jan Synáček <jsynacek <at> redhat.com> Cc: 23726-done <at> debbugs.gnu.org Subject: Re: Bug#23726: emacs 25.0.94 crashes Date: Wed, 8 Jun 2016 11:57:26 -0700
On 06/08/2016 11:52 AM, Florian Weimer wrote: > glibc patch posted: > > https://sourceware.org/ml/libc-alpha/2016-06/msg00261.html > > The same dumped binary crashes before this patch is applied, and works > afterwards. Thanks again. Closing Bug#23726, as it's a glibc bug not an Emacs bug.
bug-gnu-emacs <at> gnu.org:bug#23726; Package emacs.
(Thu, 09 Jun 2016 06:18:02 GMT) Full text and rfc822 format available.Message #27 received at 23726 <at> debbugs.gnu.org (full text, mbox):
From: Jan Synacek <jsynacek <at> redhat.com> To: Florian Weimer <fweimer <at> redhat.com> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 23726 <at> debbugs.gnu.org Subject: Re: Bug#23726: emacs 25.0.94 crashes Date: Thu, 9 Jun 2016 08:17:48 +0200
On Wed, Jun 8, 2016 at 8:52 PM, Florian Weimer <fweimer <at> redhat.com> wrote: > On 06/08/2016 08:34 PM, Florian Weimer wrote: > >> The problem is that the realloc implementation for dumped chunks is >> incorrect; that bit is already in glibc master and rawhide. I think I >> can see what is wrong: The size computation for the old chunk size in >> realloc is wrong, and the trailing sizeof (size_t) bytes are not copied. >> Fortunately, it's not a conceptual problem with the heap rewriter. > > > glibc patch posted: > > https://sourceware.org/ml/libc-alpha/2016-06/msg00261.html > > The same dumped binary crashes before this patch is applied, and works > afterwards. > > Jan, thanks for reporting this. Thanks for investigating and the quick fix! -- Jan Synacek Software Engineer, Red Hat
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Thu, 07 Jul 2016 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.