Re: Access violation from palloc, Visual Studio 2005, C-language function
От | Kevin Flanagan |
---|---|
Тема | Re: Access violation from palloc, Visual Studio 2005, C-language function |
Дата | |
Msg-id | 008a01cac08e$6edd3400$4c979c00$@com обсуждение исходный текст |
Ответ на | Re: Access violation from palloc, Visual Studio 2005, C-language function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Access violation from palloc, Visual Studio 2005, C-language function
|
Список | 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@postgresql.org [mailto:pgsql-hackers-owner@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" <kevin-f@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
В списке pgsql-hackers по дате отправления: