develooper Front page | perl.perl5.porters | Postings from May 2016

[perl #128225] substitution within (?{}) causes segmentation fault

Thread Next
From:
Dan Collins via RT
Date:
May 23, 2016 19:54
Subject:
[perl #128225] substitution within (?{}) causes segmentation fault
Message ID:
rt-4.0.18-24846-1464033246-693.128225-15-0@perl.org
This appears to be an overflow of the stack caused by infinite recursion, as evidenced by the following repeating stack frames:

#11330 0x00000000006e43f3 in S_regmatch (reginfo=0x7fffffee9860, startpos=0xaba170 "foo", prog=0xaa37a0) at regexec.c:6731
#11331 0x00000000006d7f00 in S_regtry (reginfo=0x7fffffee9860, startposp=0x7fffffee96c8) at regexec.c:3615
#11332 0x00000000006d7957 in Perl_regexec_flags (rx=0xab2ae0, stringarg=0xaba170 "foo", strend=0xaba173 "", strbeg=0xaba170 "foo", minend=0, sv=0xab29c0, data=0x0, flags=1) at regexec.c:3482
#11333 0x00000000005b8abd in Perl_pp_subst () at pp_hot.c:2982
#11334 0x0000000000559af3 in Perl_runops_debug () at dump.c:2239

Here is some GDB output from the very beginning of the backtrace:

Breakpoint 1, Perl_regexec_flags (rx=0xab2ae0, stringarg=0xaba170 "foo", strend=0xaba173 "", strbeg=0xaba170 "foo", minend=0, sv=0xab29c0, data=0x0, flags=1) at regexec.c:2878
2878    {
(gdb) bt
#0  Perl_regexec_flags (rx=0xab2ae0, stringarg=0xaba170 "foo", strend=0xaba173 "", strbeg=0xaba170 "foo", minend=0, sv=0xab29c0, data=0x0, flags=1) at regexec.c:2878
#1  0x00000000005b8abd in Perl_pp_subst () at pp_hot.c:2982
#2  0x0000000000559af3 in Perl_runops_debug () at dump.c:2239
#3  0x00000000006e43f3 in S_regmatch (reginfo=0x7fffffffe160, startpos=0xaba170 "foo", prog=0xaa37a0) at regexec.c:6731
#4  0x00000000006d7f00 in S_regtry (reginfo=0x7fffffffe160, startposp=0x7fffffffdfc8) at regexec.c:3615
#5  0x00000000006d7957 in Perl_regexec_flags (rx=0xab2ae0, stringarg=0xaba170 "foo", strend=0xaba173 "", strbeg=0xaba170 "foo", minend=0, sv=0xab29c0, data=0x0, flags=97) at regexec.c:3482
#6  0x00000000005afefd in Perl_pp_match () at pp_hot.c:1819
#7  0x0000000000559af3 in Perl_runops_debug () at dump.c:2239
#8  0x0000000000462138 in S_run_body (oldscope=1) at perl.c:2517
#9  0x0000000000461763 in perl_run (my_perl=0xa9c010) at perl.c:2440
#10 0x000000000041e8f0 in main (argc=4, argv=0x7fffffffe608, env=0x7fffffffe630) at perlmain.c:116
(gdb) info locals
prog = 0xab2750
s = 0xabbaf0 "н\252"
c = 0x0
startpos = 0x0
minlen = 4801052
dontbother = 11193440
utf8_target = false
multiline = 11216720
progi = 0xab2750
reginfo_buf = {prog = 0x0, strbeg = 0x3 <error: Cannot access memory at address 0x3>, strend = 0x1a <error: Cannot access memory at address 0x1a>,
  till = 0x50 <error: Cannot access memory at address 0x50>, sv = 0x0, ganch = 0x3000000003 <error: Cannot access memory at address 0x3000000003>, cutpoint = 0x0, info_aux = 0x0,
  info_aux_eval = 0x5600000000, poscache_maxiter = 11217344, poscache_iter = 0, poscache_size = 0, intuit = false, is_utf8_pat = false, is_utf8_target = false, warned = false}
reginfo = 0xa9ef00
swap = 0x0
oldsave = 0
re_debug_flags = 140737488343936
__PRETTY_FUNCTION__ = "Perl_regexec_flags"
(gdb) f 3
#3  0x00000000006e43f3 in S_regmatch (reginfo=0x7fffffffe160, startpos=0xaba170 "foo", prog=0xaa37a0) at regexec.c:6731
6731                    CALLRUNOPS(aTHX);                       /* Scalar context. */
(gdb) info locals
ocurcop = 0xabbed8
nop = 0xabc048
newcv = 0xa9e370
sp = 0xab9e30
before = 0
oop = 0xabc198
ret = 0xab63f0
re_sv = 0xaa37a0
startpoint = 0x0
re = 0xaa37ac
rei = 0xffffffff
arg = 0
utf8_target = false
uniflags = 1
rex_sv = 0xab2ae0
rex = 0xabcc38
rexi = 0xaa3770
st = 0xaba318
scan = 0xaa37a0
next = 0xaa37ac
n = 0
ln = 0
locinput = 0xaba170 "foo"
pushinput = 0x200000011 <error: Cannot access memory at address 0x200000011>
nextchr = 102
result = false
depth = 0
nochange_depth = 0
max_nochange_depth = 10
yes_state = 0x0
mark_state = 0x0
cur_eval = 0x0
cur_curlyx = 0x0
state_num = 68
no_final = false
do_cutgroup = false
startpoint = 0xaba170 "foo"
popmark = 0x0
sv_commit = 0x0
sv_yes_mark = 0x0
lastopen = 0
has_cutgroup = false
oreplsv = 0xa9e160
__PRETTY_FUNCTION__ = "S_regmatch"
sw = false
minmod = false
logical = 0
last_pad = 0xa9e388
multicall_cop = 0xabbb30
multicall_oldcatch = false
gimme = 2 '\002'
caller_cv = 0xa9e370
last_pushed_cv = 0xa9e370
runops_cp = 16
maxopenparen = 0
to_complement = 0
classnum = _CC_ENUM_WORDCHAR
is_utf8_pat = false
match = false
re_debug_flags = 0
(gdb) l
6726                     * first op of the block of interest, rather than the
6727                     * first op of the sub. Also, we don't want to free
6728                     * the savestack frame */
6729                    before = (IV)(SP-PL_stack_base);
6730                    PL_op = nop;
6731                    CALLRUNOPS(aTHX);                       /* Scalar context. */
6732                    SPAGAIN;
6733                    if ((IV)(SP-PL_stack_base) == before)
6734                        ret = &PL_sv_undef;   /* protect against empty (?{}) blocks. */
6735                    else {
(gdb)

Valgrind agrees that the segfault is caused by the stack overflow:

==64578== Stack overflow in thread #1: can't grow stack to 0xffe801000
==64578==
==64578== Process terminating with default action of signal 11 (SIGSEGV)
==64578==  Access not within mapped region at address 0xFFE801FF8
==64578== Stack overflow in thread #1: can't grow stack to 0xffe801000
==64578==    at 0x56DE00: Perl_mg_find (mg.c:414)
==64578==  If you believe this happened as a result of a stack
==64578==  overflow in your program's main thread (unlikely but
==64578==  possible), you can try to increase the size of the
==64578==  main thread stack using the --main-stacksize= flag.
==64578==  The main thread stack size used in this run was 8388608.
==64578== Stack overflow in thread #1: can't grow stack to 0xffe801000
==64578==
==64578== Process terminating with default action of signal 11 (SIGSEGV)
==64578==  Access not within mapped region at address 0xFFE801FF0
==64578== Stack overflow in thread #1: can't grow stack to 0xffe801000
==64578==    at 0x4A24690: _vgnU_freeres (vg_preloaded.c:58)
==64578==  If you believe this happened as a result of a stack
==64578==  overflow in your program's main thread (unlikely but
==64578==  possible), you can try to increase the size of the
==64578==  main thread stack using the --main-stacksize= flag.
==64578==  The main thread stack size used in this run was 8388608.
==64578==
==64578== HEAP SUMMARY:
==64578==     in use at exit: 7,415,854 bytes in 11,349 blocks
==64578==   total heap usage: 11,469 allocs, 120 frees, 8,271,345 bytes allocated
==64578==
==64578== LEAK SUMMARY:
==64578==    definitely lost: 0 bytes in 0 blocks
==64578==    indirectly lost: 0 bytes in 0 blocks
==64578==      possibly lost: 0 bytes in 0 blocks
==64578==    still reachable: 7,415,854 bytes in 11,349 blocks
==64578==         suppressed: 0 bytes in 0 blocks
==64578== Rerun with --leak-check=full to see details of leaked memory
==64578==
==64578== For counts of detected and suppressed errors, rerun with: -v
==64578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault

**BISECT**

This error has been present at least since 5.8.0.

---
via perlbug:  queue: perl5 status: new
https://rt.perl.org/Ticket/Display.html?id=128225

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About