Re: Custom C function - is palloc broken?

Dan "Heron" Myers wrote:
> Craig Ringer wrote:
> > Can you send me a complete, compileable example that illustrates the
> > problem, along with instructions on how to reproduce it? If possible,
> > send a compiled binary and any dependencies too. I'm curious to see if
> > this is in fact shared library issues.
>

> Then I used the following SELECT statement:
>
> SELECT copytext(colname) FROM tablename;
>
> where "colname" is a text column in table "tablename". This statement
> crashes the database server.

I'm certainly seeing a server crash with your DLL.

I've built the example with Visual C++ 9 (I had a to make a couple of
changes, such as defining BUILDING_DLL and exporting the `copytext'
function with PGDLLIMPORT) and I get a backend crash with that too. Of
course, that's also using a different runtime, and it's far from
impossible that I'm doing something wrong in the build process.

I'm having some trouble getting the example building under Visual Studio
Express 2005 ( I had to install it to test, and it's *much* uglier than
2008 ) so I haven't been able to test it properly with a matching runtime.

Looking at Pg's headers, though, I'm going to say that my first guess
about mismatched runtimes is probably wrong. That's often the cause of
plugin/extension problems on win32, but I'm not sure I see what would be
causing a mismatched runtime related failure here. Not with memory
handling, anyway. palloc() is a macro, but it's implemented using
exported functions from the backend, so allocations are actually being
performed with the backend's runtime. No memory appears to be being
freed in the example code, only being handed over to the backend to be
released later.

I'll see if it works when built with VC++ Express 2005 if I can get it
to behave (ie if/when I figure out what stupid thing I've done). I'm not
too sure that'll actually be the issue though.

> Your theory could very well be true - especially if the issue is with a
> different version of gettext. MinGW's website's snapshot is from 2006
> or something, so it wouldn't surprise me if Postgres uses a newer version.

I assume you needed gettext because PostgreSQL's headers expose Pg's use
of libintl to users of the Pg headers, so you needed libintl.h?

As the standard win32 build of Pg is built with gettext, but does not
ship the headers for the version of gettext used, it's a bit tricky to
build external C functions etc. It'd be nice to bundle those headers or
avoid including libintl.h and friends from Pg headers that're likely to
be needed for external C functions.

Ideally only .c sources would include libintl.h where required (but I
know how practical *that* sometimes turns out to be -
*cough*Freetype*cough*).

--
Craig Ringer