------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
