Segfault during fontification of rgrep buffers [HELP NEEDED]

[Herwig Hochleitner]

Hi,

I've been hunting a segfault during usage of rgrep for some time, now I've managed to catch it in gdb. From the looks of it, BEGV_ADDR is changed during a single run of search_buffer, which leaves a stale pointer in a local variable. I don't know enough about emacs to tell whether this is expected, or how to fix it. Here is some info from my gdb session, please tell me anything you might need to further investigate this. I'm also willing to hand out my core file individually:

(gdb) dir /tmp/emacs-25.1/src/
Source directories searched: /tmp/emacs-25.1/src:$cdir:$cwd

(gdb) bt
#0  re_search_2 (address@hidden <searchbufs+5792>, address@hidden <error: Cannot access memory at address 0x6154ca8>, address@hidden,
    address@hidden <error: Cannot access memory at address 0x62d1fec>, address@hidden, startpos=1556280, range=136, regs=0xb9c3f0 <search_regs>, stop=1556416) at regex.c:4464
#1  0x00000000005395ef in search_buffer (address@hidden, pos=<optimized out>, pos_byte=<optimized out>, address@hidden, address@hidden, n=1, RE=1, trt=0, inverse_trt=0,
    posix=false) at search.c:1265
#2  0x0000000000539f52 in search_command (string=48209668, bound=<optimized out>, noerror=44832, count=<optimized out>, address@hidden, address@hidden, posix=false) at search.c:1058
#3  0x000000000053a167 in Fre_search_forward (regexp=<optimized out>, bound=<optimized out>, noerror=<optimized out>, count=<optimized out>) at search.c:2264
#4  0x00000000005686af in Ffuncall (nargs=4, address@hidden) at eval.c:2704
#5  0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, address@hidden, address@hidden, args=<optimized out>,
    address@hidden) at bytecode.c:880
#6  0x00000000005680cd in funcall_lambda (fun=10112541, address@hidden, address@hidden) at eval.c:2921
#7  0x00000000005684cb in Ffuncall (nargs=4, address@hidden) at eval.c:2754
#8  0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, address@hidden, address@hidden, args=<optimized out>,
    address@hidden) at bytecode.c:880
#9  0x00000000005680cd in funcall_lambda (fun=10107237, address@hidden, address@hidden) at eval.c:2921
#10 0x00000000005684cb in Ffuncall (nargs=4, address@hidden) at eval.c:2754
#11 0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, address@hidden, address@hidden, args=<optimized out>,
    address@hidden) at bytecode.c:880
#12 0x00000000005680cd in funcall_lambda (fun=10104949, address@hidden, address@hidden) at eval.c:2921
#13 0x00000000005684cb in Ffuncall (nargs=3, address@hidden) at eval.c:2754
#14 0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, address@hidden, args=<optimized out>,
    address@hidden <pure+1343396>) at bytecode.c:880
#15 0x000000000056820b in funcall_lambda (fun=140721133517472, nargs=11260497, address@hidden, arg_vector=0x9a8684 <pure+1343396>, address@hidden) at eval.c:2855
#16 0x00000000005684cb in Ffuncall (nargs=2, address@hidden) at eval.c:2754
#17 0x000000000056877c in run_hook_wrapped_funcall (nargs=<optimized out>, args=0x7ffc312cf9e0) at eval.c:2428
#18 0x0000000000566f1d in run_hook_with_args (nargs=2, args=0x7ffc312cf9e0, funcall=0x568760 <run_hook_wrapped_funcall>) at eval.c:2509
#19 0x00000000005685e1 in Ffuncall (nargs=3, address@hidden) at eval.c:2673
#20 0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, address@hidden, args=<optimized out>,
    address@hidden <pure+1343268>) at bytecode.c:880
#21 0x000000000056820b in funcall_lambda (fun=140721133518064, nargs=11260594, address@hidden, arg_vector=0x9a8604 <pure+1343268>, address@hidden) at eval.c:2855
#22 0x00000000005684cb in Ffuncall (nargs=3, address@hidden) at eval.c:2754
#23 0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, address@hidden, args=<optimized out>,
    address@hidden <pure+1343564>) at bytecode.c:880
#24 0x000000000056820b in funcall_lambda (fun=140721133518544, nargs=11260309, address@hidden, arg_vector=0x9a872c <pure+1343564>, address@hidden) at eval.c:2855
#25 0x00000000005684cb in Ffuncall (nargs=3, address@hidden) at eval.c:2754
#26 0x00000000005a1803 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, address@hidden, args=<optimized out>,
    address@hidden <pure+1342940>) at bytecode.c:880
#27 0x000000000056820b in funcall_lambda (fun=0, nargs=11260666, address@hidden, arg_vector=0x9a84bc <pure+1342940>, address@hidden) at eval.c:2855
#28 0x00000000005684cb in Ffuncall (address@hidden, address@hidden) at eval.c:2754
#29 0x0000000000566e80 in internal_condition_case_n (bfun=0x5682c0 <Ffuncall>, address@hidden, address@hidden, address@hidden, address@hidden <safe_eval_handler>)
    at eval.c:1389
#30 0x000000000042ef78 in safe__call (address@hidden, address@hidden, func=<optimized out>, address@hidden) at xdisp.c:2558
#31 0x000000000043afac in safe_call (address@hidden, func=<optimized out>) at xdisp.c:2574
#32 0x000000000043afe2 in safe_call1 (fn=<optimized out>, address@hidden) at xdisp.c:2585
#33 0x000000000043b110 in handle_fontified_prop (it=0x7ffc312d6300) at xdisp.c:3805
#34 0x000000000043fdfa in handle_stop (address@hidden) at xdisp.c:3371
#35 0x00000000004449b2 in next_element_from_buffer (it=0x7ffc312d6300) at xdisp.c:8321
#36 0x0000000000442d25 in get_next_display_element (address@hidden) at xdisp.c:6921
#37 0x0000000000444f62 in move_it_in_display_line_to (address@hidden, address@hidden, address@hidden, address@hidden(MOVE_TO_X | MOVE_TO_POS)) at xdisp.c:8662
#38 0x000000000044716c in move_it_to (address@hidden, address@hidden, address@hidden, to_y=51, address@hidden, address@hidden) at xdisp.c:9231
#39 0x000000000044ce7f in pos_visible_p (address@hidden, charpos=1559034, address@hidden, address@hidden, address@hidden, address@hidden,
    rowh=0x7ffc312d9ca4, vpos=0x7ffc312d9ca8) at xdisp.c:1336
#40 0x0000000000464ba9 in redisplay_window (window=58045077, address@hidden) at xdisp.c:16626
#41 0x000000000046803b in redisplay_window_0 (address@hidden) at xdisp.c:14446
#42 0x0000000000566d6c in internal_condition_case_1 (address@hidden <redisplay_window_0>, arg=58045077, handlers=<optimized out>, address@hidden <redisplay_window_error>) at eval.c:1333
#43 0x0000000000432273 in redisplay_windows (window=58045077) at xdisp.c:14426
#44 0x0000000000432238 in redisplay_windows (window=58044589) at xdisp.c:14420
#45 0x0000000000454db9 in redisplay_internal () at xdisp.c:13986
#46 0x0000000000456ede in redisplay_preserve_echo_area (address@hidden) at xdisp.c:14279
#47 0x00000000005ad119 in wait_reading_process_output (address@hidden, address@hidden, address@hidden, address@hidden, address@hidden,
    address@hidden, just_wait_proc=0) at process.c:5074
#48 0x0000000000422d35 in sit_for (timeout=<optimized out>, address@hidden, address@hidden) at dispnew.c:5762
#49 0x00000000004fe971 in read_char (address@hidden, address@hidden, prev_event=0, address@hidden, address@hidden) at keyboard.c:2714
#50 0x00000000004ff59b in read_key_sequence (address@hidden, address@hidden, address@hidden,
    address@hidden, address@hidden, address@hidden, bufsize=30) at keyboard.c:9063
#51 0x000000000050131e in command_loop_1 () at keyboard.c:1365
#52 0x0000000000566cf6 in internal_condition_case (address@hidden <command_loop_1>, address@hidden, address@hidden <cmd_error>) at eval.c:1309
#53 0x00000000004f2744 in command_loop_2 (address@hidden) at keyboard.c:1107
#54 0x0000000000566c7b in internal_catch (address@hidden, address@hidden <command_loop_2>, address@hidden) at eval.c:1074
#55 0x00000000004f26ed in command_loop () at keyboard.c:1086
#56 0x00000000004f5913 in recursive_edit_1 () at keyboard.c:692
#57 0x00000000004f5c53 in Frecursive_edit () at keyboard.c:763
#58 0x0000000000418db4 in main (argc=2, argv=0x7ffc312de768) at emacs.c:1626

Lisp Backtrace:
"re-search-forward" (0x312cf090)
"font-lock-fontify-keywords-region" (0x312cf2c0)
"font-lock-default-fontify-region" (0x312cf4d0)
"font-lock-fontify-region" (0x312cf6e8)
0x429efa0 PVEC_COMPILED
"run-hook-wrapped" (0x312cf9e0)
"jit-lock--run-functions" (0x312cfbf0)
"jit-lock-fontify-now" (0x312cfe18)
"jit-lock-function" (0x312d0018)
"redisplay_internal (C function)" (0x0)

(gdb) up
#1  0x00000000005395ef in search_buffer (address@hidden, pos=<optimized out>, pos_byte=<optimized out>, address@hidden, address@hidden, n=1, RE=1, trt=0, inverse_trt=0,
    posix=false) at search.c:1265
1265  val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2,

(gdb) print p1
$30 = (unsigned char *) 0x6154ca8 <error: Cannot access memory at address 0x6154ca8>

(gdb) print BEGV_ADDR
$31 = (unsigned char *) 0x5e0dca8 "-*- mode: grep; default-directory: \"/tmp/alt/\" -*-\nGrep started at Wed Oct 26 17:08:00\n\nfind . -type d \\( -path \\*/SCCS -o -path \\*/RCS -o -path \\*/CVS -o -path \\*/MCVS -o -path \\*/.src -o -path \\*/.s"...

So, while BEGV_ADDR is valid, re_search_2 gets called with an invalid pointer, which is strange because p1 is initialized from BEGV_ADDR a few lines earlier and there are no locations within search_buffer, where p1 is updated. That can only mean, that BEGV_ADDR is updated somewhere within search_buffer. Is the rgrep process supposed to be able to write to (hence possibly reallocate) its buffer during a single search_buffer call? Can somebody help me with producing a test case for this for the bug report?


thanks