https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #36 from Nish Aravamudan <nish.aravamudan@???> ---
(In reply to Zoltan Herczeg from comment #33)
> > I grabbed a lot of gdb output just now, trying to narrow down when
> > size_offsets location gets trashed to 0. I noticed that offsetcount does,
> > inside one of the jit functions, get set to 2, but it's back to 3 in the
> > caller, until it returns to the PHP code. At which point size_offsets has
> > been set to 0... I'm going to put a watchpoint on the address of
> > size_offsets to see if I can see what actually is writing to it.
>
> Thank you, I check it.
>
> What I still don't get, if size_offsets is zero, and count is zero
>
> if (count == 0) {
> php_error_docref(NULL,E_NOTICE, "Matched, but too many substrings");
> count = size_offsets/3;
> }
>
> then count should be still zero after this point, how could this be true:
>
> if (count > 0 && (offsets[1] - offsets[0] >= 0))
>
> Perhaps GCC is (too) clever here, and realized that size_offsets must be >=
> 3 since it is computed in the following way:
>
> size_offsets = (pce->capture_count + 1) * 3;
>
> and optimized out the count > 0 part. I saw such things before...
For reference, here is the disassembly around the count > 0 if-statement:
0x0000555555679831 <php_pcre_split_impl+497>: test %eax,%eax
0x0000555555679833 <php_pcre_split_impl+499>: mov %eax,%r9d
0x0000555555679836 <php_pcre_split_impl+502>: pop %r12
0x0000555555679838 <php_pcre_split_impl+504>: pop %r14
0x000055555567983a <php_pcre_split_impl+506>: je 0x55555567a07d
<php_pcre_split_impl+2621>
=> 0x0000555555679840 <php_pcre_split_impl+512>: test %r9d,%r9d
0x0000555555679843 <php_pcre_split_impl+515>: jle 0x555555679b70
<php_pcre_split_impl+1328>
0x0000555555679849 <php_pcre_split_impl+521>: movslq (%r15),%r12
0x000055555567984c <php_pcre_split_impl+524>: mov 0x4(%r15),%eax
0x0000555555679850 <php_pcre_split_impl+528>: cmp %r12d,%eax
0x0000555555679853 <php_pcre_split_impl+531>: js 0x555555679f28
<php_pcre_split_impl+2280>
with count in %eax initially, I believe.(In reply to Zoltan Herczeg from
comment #33)
> > I grabbed a lot of gdb output just now, trying to narrow down when
> > size_offsets location gets trashed to 0. I noticed that offsetcount does,
> > inside one of the jit functions, get set to 2, but it's back to 3 in the
> > caller, until it returns to the PHP code. At which point size_offsets has
> > been set to 0... I'm going to put a watchpoint on the address of
> > size_offsets to see if I can see what actually is writing to it.
>
> Thank you, I check it.
>
> What I still don't get, if size_offsets is zero, and count is zero
>
> if (count == 0) {
> php_error_docref(NULL,E_NOTICE, "Matched, but too many substrings");
> count = size_offsets/3;
> }
>
> then count should be still zero after this point, how could this be true:
>
> if (count > 0 && (offsets[1] - offsets[0] >= 0))
>
> Perhaps GCC is (too) clever here, and realized that size_offsets must be >=
> 3 since it is computed in the following way:
>
> size_offsets = (pce->capture_count + 1) * 3;
>
> and optimized out the count > 0 part. I saw such things before...
Maybe I am missing something, but that second conditional doesn't get entered
if count == 0.
Breakpoint 6, php_pcre_split_impl (pce=pce@entry=0x555555d333f0,
subject=0x7fffed40b1a8 "\303\251\303\204\303\237\343\201\224a",
subject_len=10, return_value=return_value@entry=0x7ffff381b240,
limit_val=-1, flags=<optimized out>)
at /build/php7.0-WHFaJZ/php7.0-7.0.3/ext/pcre/php_pcre.c:1800
1800 if (count > 0 && (offsets[1] - offsets[0] >= 0)) {
3: size_offsets = 3
(gdb) print $eax
$59 = -1
(gdb) step
1835 } else if (count == PCRE_ERROR_NOMATCH) {
3: size_offsets = 3
(gdb) step
1840 if (g_notempty != 0 && start_offset < subject_len) {
3: size_offsets = 3
(gdb) step
1841 if (pce->compile_options & PCRE_UTF8) {
3: size_offsets = 3
(gdb) c
Continuing.
Breakpoint 1, php_pcre_split_impl (pce=pce@entry=0x555555d333f0,
subject=0x7fffed40b1a8 "\303\251\303\204\303\237\343\201\224a",
subject_len=10, return_value=return_value@entry=0x7ffff381b240,
limit_val=-1, flags=<optimized out>)
at /build/php7.0-WHFaJZ/php7.0-7.0.3/ext/pcre/php_pcre.c:1794
1794 if (count == 0) {
3: size_offsets = 0
(gdb) print eax
No symbol "eax" in current context.
(gdb) print $eax
$60 = 0
(gdb) step
1786 count = pcre_exec(pce->re, extra, subject,
3: size_offsets = 0
which is when we've popped back up to the top of the loop?
--
You are receiving this mail because:
You are on the CC list for the bug.
