[pcre-dev] [Bug 1209] Calling pcre_free from C# causes a mem…

Góra strony
Delete this message
Autor: Philip Hazel
Data:  
Dla: pcre-dev
Temat: [pcre-dev] [Bug 1209] Calling pcre_free from C# causes a memory access violation
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1209




--- Comment #5 from Philip Hazel <ph10@???> 2012-02-29 18:51:04 ---
On Tue, 28 Feb 2012, Rhodri Jenkins wrote:

> Yes I did resolve this in a fashion. What I did was add a new function
> which I exported from the pcre3.dll. This was void pcre_free_regex (void *
> ptr) which call free internally.
>
> This function just calls free internally on the pointer to the regex
> structure I got from pcre_compile. The reason why I need to do this I
> believe is that I am calling pcre from C#. There were not way I could find
> to call pcre_free successfully because its is a function pointer and I
> could not free up the structure pointer because it is allocated on the
> unmanaged memory space. The simple exported function pcre_free_regex
> worked just fine.


It occurs to me that, as you are obviously not changing the default
value of pcre_malloc (which just points to malloc), nor the value of
pcre_free (which just points to free), you could free the pcre block by
calling the system function free() directly, if that is possible from
your C# environment.

> The other problem I encountered in the windows build files supplied fro
> MSVC 2008 do not contain the necessary link and manifest settings to
> generate a manifest file.


I'm afraid I know nothing about Windows (even less about MSVC). I don't
know much about CMake either, but I do know that several Windows users
of PCRE use it, and I understand it can generate a number of different
build-system's files - I don't know if this includes MSVC on Windows.

When you say "windows build files supplied", exactly which files are you
referring to? Any windows-specific files in the distribution have been
contributed by users, and they never get updated in any other way.

> If you are interest in these changes I can supply the amended code with
> some instructions. There is basically one extra c file with a three line
> function pcre_free_regex.. A function prototype for this function in
> pcre.h and migrated solution and project files.


If my suggestion above works for you, then I think we need not bother
with this. The addition of pcre_free_regex is, however, something to
think about anyway, now that we have invented pcre_free_study (which did
not exist till recently). There is in any case a long-term issue with
the way the current pcre_malloc etc work that impacts on multithreaded
programs and on libraries that call PCRE. One of these days there might
have to be a complete API re-design, and at that stage there should
certainly be something like pcre_free_regex.

As far as the solution and project files go, I'm afraid I don't even
understand what they are, but they are presumably related to one
particular build system. As PCRE already supports two fairly widely used
build systems ("configure", well-known in the Unix/Linux world, and
"CMake", which works across several platforms including Unix/Linux and
Windows) I don't want to take on the maintenance burden of any more.
PCRE already takes up enough of my (retired) time!

However, if you are just talking about updating files that are already
in the distribution, that makes sense. 2008 is a while ago now.

Regards,
Philip


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email