On 9/14/12 4:26 PM, Tom Lane wrote:
So that explains why including perl.h is relevant. Would you like to
try modifying your copy of pthread.h to confirm it's the same situation
on Ubuntu?
Yup, that fixes it.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
Marko Tiikkaja writes:
> On 9/13/12 11:58 PM, Tom Lane wrote:
>> And on still further investigation, the patch I just applied to HEAD
>> seems to make it go away too. Bizarre as can be. If that holds up for
>> you, I think back-patching that change is less ugly than making the
>> variable non-st
On 9/13/12 11:58 PM, Tom Lane wrote:
I wrote:
A probably less costly solution than marking current_call_data volatile
is just to make it not-static.
And on still further investigation, the patch I just applied to HEAD
seems to make it go away too. Bizarre as can be. If that holds up for
you,
I wrote:
> A probably less costly solution than marking current_call_data volatile
> is just to make it not-static.
And on still further investigation, the patch I just applied to HEAD
seems to make it go away too. Bizarre as can be. If that holds up for
you, I think back-patching that change is
I wrote:
> Apparently the reasoning is that current_call_data is a static and
> therefore the compiler can see everything that can happen to it and
> therefore this store into current_call_data is dead code, since the
> store six lines below will replace it. Sigh. I shall file a bug,
> but I've f
Marko Tiikkaja writes:
> On 13/09/2012 19:48, Tom Lane wrote:
>> Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
> We've reproduced it on both 5.14.2 and 5.16.1.
Meh. I've managed to reproduce it on the fifth system I tried. I don't
think it's got anything to do with
On 13/09/2012 19:48, Tom Lane wrote:
Marko Tiikkaja writes:
On 9/12/12 1:50 AM, Tom Lane wrote:
Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
We've reproduced it on both 5.14.2 and 5.16.1.
What happens is that free_plperl_function() for some reason gets called
w
Marko Tiikkaja writes:
> On 9/12/12 1:50 AM, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> Joel Jacobson managed to narrow it down to this test case, which crashes
>>> consistently on Ubuntu 12.04 both with and without your patch. I,
>>> however, wasn't able to reproduce the problem on my OS X M
On 9/12/12 1:50 AM, Tom Lane wrote:
Marko Tiikkaja writes:
Joel Jacobson managed to narrow it down to this test case, which crashes
consistently on Ubuntu 12.04 both with and without your patch. I,
however, wasn't able to reproduce the problem on my OS X Mountain Lion.
Doesn't reproduce for
Marko Tiikkaja writes:
> Joel Jacobson managed to narrow it down to this test case, which crashes
> consistently on Ubuntu 12.04 both with and without your patch. I,
> however, wasn't able to reproduce the problem on my OS X Mountain Lion.
Doesn't reproduce for me either ...
On 10/09/2012 00:37, Tom Lane wrote:
The attached patch fixes the problem I'm seeing. I am not sure whether
it fixes what you saw; the crash you showed is in the right place, but
unless there was a recursive call to a pl/perl function, I don't see
how the existing code could have freed the prode
I wrote:
> Hm. Well, I can definitely reproduce a segfault using this example:
> CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
>spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS
> INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
>spi_exec
Marko Tiikkaja writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> Hm. Is it possible that the prepared statement recursively called the
>> *same* plperl function? And that somebody did a CREATE OR REPLACE on
>> that function meanwhile?
> No, that doesn't seem possible in this case. The function
I wrote:
> Another thing that seems a bit risky is that plperl_func_handler sets up
> current_call_data as a pointer to a mostly-zeroed struct and then does
> assorted things that could throw error. That would leave a dangling
> value of current_call_data ...
Meh, scratch that --- I missed that t
Marko Tiikkaja writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> This might be the wrong theory. You seem to have debug symbols for that
>> core dump --- can you tell which of the dereferences in line 3373
>> caused the crash?
> The current_call_data->prodesc->fn_readonly one.
> Please let me kn
Hi,
On 03/09/2012 18:06, Tom Lane wrote:
pgm...@joh.to writes:
We had a segmentation fault in PostgreSQL 9.1.5 with PL/PerlU.
...
It seems to have happened when a PL/PerlU executed a prepared statement
which calls another PL/PerlU function.
Hm. Is it possible that the prepared statement recu
pgm...@joh.to writes:
> We had a segmentation fault in PostgreSQL 9.1.5 with PL/PerlU.
> ...
> It seems to have happened when a PL/PerlU executed a prepared statement
> which calls another PL/PerlU function.
Hm. Is it possible that the prepared statement recursively called the
*same* plperl funct
17 matches
Mail list logo
