> 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
On 31 January 2012 19:01, Andres Freund wrote:
>> 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 dest
On Tuesday, January 31, 2012 07:52:52 PM Peter Geoghegan wrote:
> On 30 January 2012 23:04, Soules, Craig wrote:
> > When there are no errors everything works flawlessly, however, we noticed
> > that even throwing an exception in the C++ layer was causing an
> > immediate segmentation fault. Even
On 30 January 2012 23:04, Soules, Craig wrote:
> When there are no errors everything works flawlessly, however, we noticed
> that even throwing an exception in the C++ layer was causing an immediate
> segmentation fault. Even when encapsulated in a try { } catch(...) { } block.
>
> If anyone ha
On Mon, Jan 30, 2012 at 6:04 PM, Soules, Craig wrote:
> When there are no errors everything works flawlessly, however, we noticed
> that even throwing an exception in the C++ layer was causing an immediate
> segmentation fault. Even when encapsulated in a try { } catch(...) { } block.
Stack ba
Hello,
I've run into a very odd issue calling C++ code that uses exceptions from
within our PostgreSQL FDW. Specifically, we have broken our FDW into two
components, a C layer that looks quite similar to the FDW for text files and a
C++ layer that is called into by the C layer to interface wit
