bug#23726: 25.0.94; emacs 25.0.94 crashes

bug#23726: 25.0.94; emacs 25.0.94 crashes

[Jan Synáček]

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@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@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

bug#23726: 25.0.94; emacs 25.0.94 crashes

[Eli Zaretskii]

> From: jsynacek@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@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@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#23726: emacs 25.0.94 crashes

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

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?


[-- Attachment #2: valgrind.supp --]
[-- Type: text/plain, Size: 1337 bytes --]

# valgrind suppression file
# Usage:
#    valgrind --suppressions=valgrind.supp ./temacs

# Conservative garbage collection inherently looks at uninitialized values,
# and Fgarbage_collect and its callees all depend on this.
# It's hard to separate out exactly which callees need to be listed here,
# since the C compiler can inline them.  Also, valgrind doesn't care
# about the use of uninitialized variables directly, only when their values
# are eventually used.  So just list Fgarbage_collect and its callees.
{
   Fgarbage_collect Cond - conservative garbage collection
   Memcheck:Cond
   ...
   fun:Fgarbage_collect
}
{
   Fgarbage_collect Value8 - conservative garbage collection
   Memcheck:Value8
   ...
   fun:Fgarbage_collect
}
# valgrind only looks at the last few callees on the stack, but
# mark_object can call itself recursively and deeply.  So list
# it too, in case Fgarbage_collect is a long way from the stack top.
{
   Fgarbage_collect Cond - conservative garbage collection
   Memcheck:Cond
   ...
   fun:mark_object
}
{
   Fgarbage_collect Value8 - conservative garbage collection
   Memcheck:Value8
   ...
   fun:mark_object
}

# On one circa-2011 x86-64 GNU/Linux platform, strlen is inlined to
# something that loads 4 bytes at a time.
{
   init_buffer optimized strlen
   Memcheck:Addr4
   fun:init_buffer
}

bug#23726: emacs 25.0.94 crashes

[Florian Weimer]

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#23726: emacs 25.0.94 crashes

[Florian Weimer]

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

bug#23726: emacs 25.0.94 crashes

[Paul Eggert]

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#23726: emacs 25.0.94 crashes

[Jan Synacek]

On Wed, Jun 8, 2016 at 8:52 PM, Florian Weimer <fweimer@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