> I suggest that you generalise from the example of PLV8. The basic > problem is that the effect of longjmp()ing over an area of the stack > with a C++ non-POD type is undefined. I don't think you can even use > structs, as they have implicit destructors in C++.
I had thought that this was only an issue if you tried to longjmp() over a section of C++ code starting from a postgres backend C function? From the PostgreSQL documentation: " If calling backend functions from C++ code, be sure that the C++ call stack contains only plain old data structures (POD). This is necessary because backend errors generate a distant longjmp() that does not properly unroll a C++ call stack with non-POD objects." But this is not what our code is doing. Our code is a C++ function that only does the following: try { throw 1; } catch (int e) { } catch (...) { } which causes an immediate segmentation fault. To answer another responders question, the stack trace looks as follows: #0 0x00002b3ce8f40fa5 in __cxa_allocate_exception () from /usr/lib64/libstdc++.so.6 #1 0x00002b3ce77b6256 in initMBSource (state=0x1ab87a80) at /data/soules/metaboxA-bugfix/Metabox/debug_build/src/lib/query/dsFdwShim.cpp:16791 #2 0x00002b3ce6c0b0aa in dsBeginForeignScan (node=0x1ab872d0, eflags=<value optimized out>) at dataseries_fdw.c:819 #3 0x000000000057606c in ExecInitForeignScan () #4 0x000000000055c715 in ExecInitNode () #5 0x000000000056874c in ExecInitAgg () #6 0x000000000055c6a5 in ExecInitNode () #7 0x000000000055b944 in standard_ExecutorStart () #8 0x0000000000621b96 in PortalStart () #9 0x000000000061edad in exec_simple_query () #10 0x000000000061f624 in PostgresMain () #11 0x00000000005e4c5c in ServerLoop () #12 0x00000000005e595c in PostmasterMain () #13 0x000000000058a77e in main () Note: #2 is the entry into our C library and #1 is the entry into our C++ library This appears to be some kind of allocation error, but the machine on which I'm running has plenty of free ram: [~]$ free total used free shared buffers cached Mem: 24682888 10505920 14176968 0 1220496 7412352 -/+ buffers/cache: 1873072 22809816 Swap: 2096472 0 2096472 I also don't understand how it could truly be an allocation issue since we new/delete plenty of memory during a successful run (as well as using plenty of C++ containers which do internal allocation). Hopefully this helps jog thoughts on my issue! Thanks again! Craig -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers