Re: [pcre-dev] Win32 JIT Access Violation - bisect results

Top Page

Reply to this message
Author: Zoltán Herczeg
Date:  
To: pcre-dev@exim.org, Ralf Junker
New-Topics: Re: [pcre-dev] Win32 JIT Access Violation - fix confirmed
Subject: Re: [pcre-dev] Win32 JIT Access Violation - bisect results
Hi Ralf,

thank you for the report. I believe I fixed the issue in r1187:
https://lists.exim.org/lurker/message/20191119.122533.752fb165.en.html

I removed a line that I shouldn't. Let me know if the issue still persists.

Regards,
Zoltan
 
-------- Eredeti levél --------
Feladó: Ralf Junker < ralfjunker@??? (Link -> mailto:ralfjunker@gmx.de) >
Dátum: 2019 november 19 11:21:09
Tárgy: Re: [pcre-dev] Win32 JIT Access Violation - bisect results
Címzett: pcre-dev@??? < pcre-dev@??? (Link -> mailto:pcre-dev@exim.org) >
Here is the result of the bisect:
SVN 1137 fail
SVN 1136 compiler error, fixed in 1137
SVN 1135 pass
config.h changes required, as outlined in my previous message:
#define SUPPORT_JIT 1
#define NEWLINE_DEFAULT 3
Command line:
pcre2test.exe -jit -q -8 test.txt
At SVN 1137, the AV triggers in sljitExecAllocator.c line 348:
while (free_block) {<!-- -->
next_free_block = free_block->next;
if (!free_block->header.prev_size && /* <-- AV here! */
AS_BLOCK_HEADER(free_block, free_block->size)->size == 1) {<!-- -->
total_size -= free_block->size;
sljit_remove_free_block(free_block);
free_chunk(free_block, free_block->size + sizeof(struct
block_header));
}
free_block = next_free_block;
}
Call Stack:
:00423078 sljit_free_unused_memory_exec()
:0044E565 pcre2_jit_free_unused_memory_8(gcontext=:01F54730)
:00473EF3 main(argc=2, argv=:01F8A680)
:004812e7 ; __startup
I realize this is not the same AV as originally reported, but I think it
is related. It feels like uninitialized memory access or buffer overrun.
I hope you can make use of this information. Feel free to ask fore more.
Many thanks,
Ralf
PS: Please release whenever you and Philip feel is the right time.
On 19.11.2019 08:48, Zoltán Herczeg wrote:
> I suspect something is wrong with code generation. Maybe the total size
> of the buffer is incorrect. The four bytes after addr=:001DFFFE affects
> two pages, and I suspect something is wrong with the page starting from
> 001E0000 (not allocated or not writable).
>
> Anyway I suspect Philip wants to release PCRE2 as soon as possible, so
> if you don't mind we could track this down after the release.