emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#22310: closed (Segmentation fault in regular expre


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#22310: closed (Segmentation fault in regular expression matcher)
Date: Thu, 07 Jan 2016 16:15:01 +0000

Your message dated Thu, 07 Jan 2016 18:14:28 +0200
with message-id <address@hidden>
and subject line Re: bug#22310: Segmentation fault in regular expression matcher
has caused the debbugs.gnu.org bug report #22310,
regarding Segmentation fault in regular expression matcher
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
22310: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22310
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Segmentation fault in regular expression matcher Date: Tue, 05 Jan 2016 13:15:54 +0100 User-agent: Notmuch/0.21+24~gbceb651 (http://notmuchmail.org) Emacs/25.1.50.1 (x86_64-pc-linux-gnu)
While editing a Markdown document with markdown-mode and revision
138480a97bfc1104143b5fc10dfc962b95b78ae8 I encountered this segmentation
fault,

Program received signal SIGSEGV, Segmentation fault.
0x0000000000538ae8 in re_match_2_internal (address@hidden <searchbufs+2552>,
    address@hidden "---\ntitle: Understanding GHC Core\ndate: 2015-11-29\ntags: 
ghc,core,work-in-progress\ndescription: Everything you really need to know to 
understand GHC's Core\n---\n**This document is a work-in-progress.**"..., 
address@hidden,
    address@hidden "\n\n`cast`\n\n`Sym`\n\n`Sub`\n\n`<ty>_R` is a type 
parameter with representational role. Roughly speaking this\nmeans that given a 
type constructor `T` and types `A` and `B`, `T <A>_R` and `T\n<B>_R` are 
repres"..., address@hidden, address@hidden,
    regs=0xb8e970 <search_regs>, stop=11078) at regex.c:5556
5556              PUSH_FAILURE_REG (*p);
(gdb) bt
#0  0x0000000000538ae8 in re_match_2_internal (address@hidden <searchbufs+2552>,
    address@hidden "---\ntitle: Understanding GHC Core\ndate: 2015-11-29\ntags: 
ghc,core,work-in-progress\ndescription: Everything you really need to know to 
understand GHC's Core\n---\n**This document is a work-in-progress.**"..., 
address@hidden,
    address@hidden "\n\n`cast`\n\n`Sym`\n\n`Sub`\n\n`<ty>_R` is a type 
parameter with representational role. Roughly speaking this\nmeans that given a 
type constructor `T` and types `A` and `B`, `T <A>_R` and `T\n<B>_R` are 
repres"..., address@hidden, address@hidden,
    regs=0xb8e970 <search_regs>, stop=11078) at regex.c:5556
#1  0x000000000053dd18 in re_search_2 (address@hidden <searchbufs+2552>,
    address@hidden "---\ntitle: Understanding GHC Core\ndate: 2015-11-29\ntags: 
ghc,core,work-in-progress\ndescription: Everything you really need to know to 
understand GHC's Core\n---\n**This document is a work-in-progress.**"..., 
address@hidden,
    address@hidden "\n\n`cast`\n\n`Sym`\n\n`Sub`\n\n`<ty>_R` is a type 
parameter with representational role. Roughly speaking this\nmeans that given a 
type constructor `T` and types `A` and `B`, `T <A>_R` and `T\n<B>_R` are 
repres"..., address@hidden, startpos=4281, address@hidden,
    range=6797, regs=0xb8e970 <search_regs>, stop=11078) at regex.c:4446
#2  0x00000000005337c2 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
#3  0x000000000053412c in search_command (string=131546964, bound=<optimized 
out>, noerror=44256, count=<optimized out>, address@hidden, address@hidden, 
posix=false) at search.c:1058
#4  0x0000000000534317 in Fre_search_forward (regexp=<optimized out>, 
bound=<optimized out>, noerror=<optimized out>, count=<optimized out>) at 
search.c:2243
#5  0x00000000005618bb in Ffuncall (nargs=4, address@hidden) at eval.c:2661
#6  0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=77647541, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#7  0x0000000000561434 in funcall_lambda (fun=140737488338080, address@hidden, 
arg_vector=0x3cfea84, address@hidden) at eval.c:2810
#8  0x00000000005616eb in Ffuncall (nargs=7, address@hidden) at eval.c:2711
#9  0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=77647797, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#10 0x0000000000561434 in funcall_lambda (fun=140737488338528, address@hidden, 
arg_vector=0x4433454, address@hidden) at eval.c:2810
#11 0x00000000005616eb in Ffuncall (nargs=4, address@hidden) at eval.c:2711
#12 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=72559893, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#13 0x0000000000561434 in funcall_lambda (fun=140737488339296, address@hidden, 
arg_vector=0x44337f4, address@hidden) at eval.c:2810
#14 0x00000000005616eb in Ffuncall (address@hidden, args=0x7fffffffbf70) at 
eval.c:2711
#15 0x0000000000562ab0 in Fapply (nargs=<optimized out>, args=0x7fffffffc0d8) 
at eval.c:2278
#16 0x00000000005617f1 in Ffuncall (nargs=3, address@hidden) at eval.c:2630
#17 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62636509, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#18 0x0000000000561434 in funcall_lambda (fun=140737488339840, address@hidden, 
arg_vector=0x3bc24f4, address@hidden) at eval.c:2810
#19 0x00000000005616eb in Ffuncall (nargs=3, address@hidden) at eval.c:2711
#20 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62667277, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#21 0x0000000000561434 in funcall_lambda (fun=140737488340336, address@hidden, 
arg_vector=0x3bcc884, address@hidden) at eval.c:2810
#22 0x00000000005616eb in Ffuncall (nargs=2, address@hidden) at eval.c:2711
#23 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62667053, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#24 0x0000000000561434 in funcall_lambda (fun=140737488340768, address@hidden, 
arg_vector=0x3bcc634, address@hidden) at eval.c:2810
#25 0x00000000005616eb in Ffuncall (nargs=2, address@hidden) at eval.c:2711
#26 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62721789, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#27 0x0000000000561434 in funcall_lambda (fun=140737488341168, address@hidden, 
arg_vector=0x3bd2254, address@hidden) at eval.c:2810
#28 0x00000000005616eb in Ffuncall (nargs=1, address@hidden) at eval.c:2711
#29 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62722053, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#30 0x0000000000561434 in funcall_lambda (fun=140737488341584, address@hidden, 
arg_vector=0x3bd2aa4, address@hidden) at eval.c:2810
#31 0x00000000005616eb in Ffuncall (nargs=1, address@hidden) at eval.c:2711
#32 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62668853, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#33 0x0000000000561434 in funcall_lambda (fun=140737488342016, address@hidden, 
arg_vector=0x3bd0044, address@hidden) at eval.c:2810
#34 0x00000000005616eb in Ffuncall (nargs=1, address@hidden) at eval.c:2711
#35 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=62668741, maxdepth=<optimized out>, args_template=<optimized out>, 
address@hidden, args=<optimized out>, address@hidden) at bytecode.c:880
#36 0x0000000000561434 in funcall_lambda (fun=140737488342800, address@hidden, 
arg_vector=0x3bcfe54, address@hidden) at eval.c:2810
#37 0x00000000005616eb in Ffuncall (address@hidden, args=0x7fffffffcd10) at 
eval.c:2711
#38 0x0000000000562ab0 in Fapply (nargs=<optimized out>, args=0x7fffffffce80) 
at eval.c:2278
#39 0x00000000005617f1 in Ffuncall (nargs=3, address@hidden) at eval.c:2630
#40 0x00000000005960f3 in exec_byte_code (bytestr=<optimized out>, 
vector=10135853, maxdepth=<optimized out>, address@hidden, address@hidden, 
args=<optimized out>, address@hidden) at bytecode.c:880
#41 0x000000000056130f in funcall_lambda (fun=10135773, address@hidden, 
address@hidden) at eval.c:2876
#42 0x00000000005616eb in Ffuncall (address@hidden, address@hidden) at 
eval.c:2711
#43 0x00000000005619ea in call1 (address@hidden, address@hidden) at eval.c:2509
#44 0x00000000004f3e98 in timer_check_2 (idle_timers=<optimized out>, 
timers=<optimized out>) at keyboard.c:4400
#45 timer_check () at keyboard.c:4462
#46 0x00000000004f4279 in readable_events (address@hidden) at keyboard.c:3304
#47 0x00000000004f5a48 in get_input_pending (address@hidden) at keyboard.c:6690
#48 0x00000000004f8198 in detect_input_pending_run_timers (address@hidden) at 
keyboard.c:9821
#49 0x00000000005a15c8 in wait_reading_process_output (address@hidden, 
address@hidden, address@hidden, address@hidden, address@hidden, address@hidden, 
just_wait_proc=0) at process.c:4963
#50 0x0000000000422da2 in sit_for (timeout=<optimized out>, address@hidden, 
address@hidden) at dispnew.c:5751
#51 0x00000000004fa96e in read_char (address@hidden, address@hidden, 
prev_event=0, address@hidden, address@hidden) at keyboard.c:2694
#52 0x00000000004fb2c4 in read_key_sequence (address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden, address@hidden,
    bufsize=30) at keyboard.c:9022
#53 0x00000000004fce2e in command_loop_1 () at keyboard.c:1343
#54 0x000000000055fe97 in internal_condition_case (address@hidden 
<command_loop_1>, address@hidden, address@hidden <cmd_error>) at eval.c:1309
#55 0x00000000004eea8c in command_loop_2 (address@hidden) at keyboard.c:1086
#56 0x000000000055fd8b in internal_catch (address@hidden, address@hidden 
<command_loop_2>, address@hidden) at eval.c:1073
#57 0x00000000004eea49 in command_loop () at keyboard.c:1065
#58 0x00000000004f313b in recursive_edit_1 () at keyboard.c:671
#59 0x00000000004f3488 in Frecursive_edit () at keyboard.c:742
#60 0x0000000000418dce in main (argc=1, argv=0x7fffffffe198) at emacs.c:1652
(gdb) print regs[0]
$3 = {num_regs = 30, start = 0xfdf650, end = 0xfdf750}

Unfortunately this is about all I was able to scrape out of the
procedure's local state, knowing little about the internals of the
matcher.

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- Subject: Re: bug#22310: Segmentation fault in regular expression matcher Date: Thu, 07 Jan 2016 18:14:28 +0200
> From: Ben Gamari <address@hidden>
> Date: Thu, 07 Jan 2016 15:26:37 +0100
> 
> Ben Gamari <address@hidden> writes:
> 
> > While editing a Markdown document with markdown-mode and revision
> > 138480a97bfc1104143b5fc10dfc962b95b78ae8 I encountered this segmentation
> > fault,
> >
> Indeed this appears to be fixed as of 
> 61e83e902b388490b609677a76f3d49740439f24.

Great, thanks for testing.  I'm therefore closing this bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]