Re: Access violation from palloc, Visual Studio 2005, C-language function

From: "Kevin Flanagan" <kevin-f(at)linkprior(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Access violation from palloc, Visual Studio 2005, C-language function
Date: 2010-03-10 20:15:30
Message-ID: 008a01cac08e$6edd3400$4c979c00$@com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aha. I'd read that the build process for the contrib modules involved
generating a .DEF file for the necessary exports. I had the impression that
defining BUILDING_DLL was an alternative, addressing (part) of the issue
(that is, PG_FUNCTION_INFO_V1 declares functions as 'extern PGDLLIMPORT',
and if you define BUILDING_DLL, then PGDLLIMPORT is defined as ' __declspec
(dllexport)'). But you're quite right, if I take out the BUILDING_DLL
definition, and put the __declspec (dllexport) stuff in piecemeal, the
access violation goes away. Thank goodness.

Thanks, that really helped me out.

Kevin.

-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: 10 March 2010 18:51
To: Kevin Flanagan
Cc: 'PostgreSQL-development'
Subject: Re: [HACKERS] Access violation from palloc, Visual Studio 2005,
C-language function

"Kevin Flanagan" <kevin-f(at)linkprior(dot)com> writes:
>>> Hard to tell without seeing the actual code and a stack trace, but I'd
>>> bet that you haven't fully resolved the build process problems you
>>> mentioned earlier.

> I've attached a zip of the (tiny) project, and a text file with the
contents
> of the module containing the C-language functions. The only difference
from
> sample code is that (as pointed out by Takahiro Itagaki in his post here
of
> 8th March) the function implementations need decorating with
> __declspec(dllexport).

Mph. I don't actually believe that, nor do I believe the #define
BUILDING_DLL you put in, because neither of those are needed in any of
our contrib modules. What I suspect at this point is that the reference
to CurrentMemoryContext in the palloc() macro is being bollixed by
having the wrong value for BUILDING_DLL. However, not having a Windows
build environment to experiment with, I'll have to defer to somebody
with more experience in that.

(I wonder BTW if we should rename BUILDING_DLL, because it seems a bit
misnamed. AIUI it's supposed to be set while building the core backend,
not while building loadable modules.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-03-10 20:36:32 Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4
Previous Message Josh Berkus 2010-03-10 18:59:50 Re: Re: Hot Standby query cancellation and Streaming Replication integration