Re: Custom C function - is palloc broken?

Nathan Thatcher wrote:
> First off, I am developing custom c functions for PostgreSQL 8.3 in
> Windows (sorry... not my choice). It appears that there is some
> underlying problem in the server that is causing a runtime error to
> crash the server when I use palloc.

[Assuming you're using the stock 8.3.1 binaries and MSVC++8.0 or the
Express Edition of the same]:

Are you 100% certain you are using the same compiler and version that
PostgreSQL was built with, and that you have linked to the *exact* same
runtime library that the backend was linked to? These issues seem to be
a major cause of all sorts of fun problems especially for apps that
originated in the happier, saner UNIX world.

PostgreSQL probably doesn't put in the absurd effort required to avoid
freeing memory in a different DLL to where it was allocated [*]. Having
origins in nice sane UNIX environments where everybody just uses the
same compiler and runtime library it probably does not, this is quite
understandable. However, if I'm right about that (I have not verified
it) then you MUST link to the exact same runtime library that the
backend was linked to or things WILL break. Using the same version of
the same compiler would also be a good idea.

You'll also have to use a dynamic version of the runtime. Linking to a
static version will not work properly, because each DLL will have its
own private memory allocator.

Use Dependency Walker (depends.exe, from http://dependencywalker.com/)
to examine the names and resolved paths of the linked libraries. If you
are linking to a different runtime to the backend, or to multiple
runtimes, things are highly likely to explode.

The stock 8.3.1 win32 binaries appear to be linked to a copy of
MSVCR80.DLL in the WinSxS library tree. That means that you must link
only to MSCVR80.DLL (via the import library msvcrt.lib), which is the
multi-threaded non-debug dynamic runtime for Visual C++ 8. Make sure
you're using the same copy in the same WinSxS location, not a subtly
different version (say, from a VC++8.0 beta).

If your library/extension is linked to any other runtimes, like
msvcr80d.dll or msvcm80.dll, things will probably break.

If your library links to LIBCMT.LIB or LIBCMTD.LIB (note: these may not
appear in dependency walker as they're static libraries; check your
linker command line) things will CERTAINLY break.

That goes for MinGW, too. Do not expect a shared library compiled by
MinGW to load and run happily in an executable built with MSVC++ unless
all the public interfaces are very careful about how they handle memory
allocation, ownership and deallocation. Either build Pg with MinGW too
(if that's supported or even possible) or preferably just get the Visual
C++ Express Edition 8.0 from MS and use that to build your extension.

BTW: Rather than specifying the import library for the C library
directly as a linker argument, use the /MD flag in the linker options or
set it in the project file. If you are not using VC++ 8.0 it's not as
simple as just using /MD ; you might be able to fudge it with
/NODEFAULTLIB but I really do not know.

See:
     http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
for some information on the surprising variety of runtime libraries
provided by MSVC++ 8.0 alone.


 > I also get the exact same error when I try to run either the copytext
 > or concat_text functions from the same funcs_new.c file in the
 > tutorial directory. This essentially means that I cannot write any
 > UDFs that require memory allocation or text parameters. Heron seems to
 > be experiencing the same thing. Is this a bug in 8.3? Can anyone help?

Most text handling involves memory allocations and deallocations. I
would not be at all surprised if your problem was mismatched compilers
or runtimes.



* Yes, there's more to it than just avoiding freeing memory in a
different DLL than it was allocated in. File descriptors, for example,
need similar treatment, as do all sorts of other weird little corners
that aren't worth enumerating.

--
Craig Ringer