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

2010-03-10 Thread Tom Lane
Kevin Flanagan kevi...@linkprior.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2010-03-10 Thread Kevin Flanagan
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-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.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 kevi...@linkprior.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Access violation from palloc, Visual Studio 2005, C-language function

2010-03-09 Thread Kevin Flanagan
Environment: Windows Vista, PostgreSQL 8.4 (1-click installer), Visual
Studio 2005 sp1.

I have a bare-bones DLL built as per the above, compiling the 'add_one' and
'copytext' samples found at
http://www.postgresql.org/docs/8.4/interactive/xfunc-c.html (version 1
calling convention), compiled as 'C'. I can use 'add_one' just fine from
within SQL, but if I use 'copytext', an access violation occurs as soon as
palloc() is called.

Could anyone suggest what the problem might be?

Failing that, are there any other (creative?) ways to return strings from a
C-language function without using palloc?

Thanks in advance for any leads

Kevin.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2010-03-09 Thread Tom Lane
Kevin Flanagan kevi...@linkprior.com writes:
 Environment: Windows Vista, PostgreSQL 8.4 (1-click installer), Visual
 Studio 2005 sp1.

 I have a bare-bones DLL built as per the above, compiling the 'add_one' and
 'copytext' samples found at
 http://www.postgresql.org/docs/8.4/interactive/xfunc-c.html (version 1
 calling convention), compiled as 'C'. I can use 'add_one' just fine from
 within SQL, but if I use 'copytext', an access violation occurs as soon as
 palloc() is called.

 Could anyone suggest what the problem might be?

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'm thinking this may be a symptom of linkage
failure, since palloc is probably the first place in the above-described
sequence where your DLL is going to call back into the core backend.

Another possibility is that you mistranscribed the example somehow.
Maybe you forgot the PG_FUNCTION_INFO_V1(copytext) macro?

 Failing that, are there any other (creative?) ways to return strings from a
 C-language function without using palloc?

If you can't make those examples work, you have fundamental problems you
need to fix, not find a creative workaround.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers