------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1362
--- Comment #2 from Carsten Klein <cklein05@???> 2013-06-03 08:25:47 ---
Hi Zoltan,
that's good news. Thank you for implementing that. However, please allow me to
add one more note.
I have had a lot of 'fun' with releasing any JIT compiled pattern and
subsequently recompiling one again. The second JIT compiler invocation
constantly failed with a GPF. OK, it was completely my fault. I have used
pcre16_study to compile and called pcre_free_study (missing the 16!) to release
it. Since I am coding an ActiveX/COM object model around PCRE (which uses
Windows Unicode and so basically relies on the 16 bit library), calling the
wrong free function was not too obvious at first glance. So, actually, my
memory was freed by the 8 bit library, but the memory allocator of the 16 bit
library was still thinking that it has some blocks available in free_blocks.
Actually, the global variables free_blocks, allocated_size and total_size are
static and thus, are global in their *.c file. Since the whole sljit stuff is
just included into pcre_jit_compile.c, which is also compiled as
pcre16_jit_compile.c and pcre32_jit_compile.c as well. So, actually these
globals are global to either the 8, 16 or 32 bit library. This may lead to some
confusion if one shared object or DLL contains several libraries (still my
fault, of course).
This is just something to think about... (as you are just implementing the gc
like free-memory function):
Is it really intended NOT to have a really global memory allocator? For
instance, isn't is worth thinking about putting these globals to pcre_global.c?
Of course, the idea is not to mix PCRE and the sljit in a spaghetti like manner
(since sljit seems to be an independent library). But, maybe you could add a
separate global allocator pcre_jit_allocator.c to PCRE and use this in sljit
(through #define SLJIT_MALLOC_EXEC and #define SLJIT_FREE_EXEC accordingly, for
example)? Of course, actually the new PCRE specific allocator is exactly the
same as that in sljitExecAllocator.c.
After all, that is not a big improvement, but may help to make the library
more safe/stable/tolerant.
Carsten
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
