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
Re: [HACKERS] Access violation from palloc, Visual Studio 2005, C-language function
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
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
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
