Обсуждение: BUG #5323: plperl and plperlu interaction segfaults
The following bug has been logged online: Bug reference: 5323 Logged by: Dave Olszewski Email address: cxreg@pobox.com PostgreSQL version: 8.3.9 Operating system: Linux Description: plperl and plperlu interaction segfaults Details: Creating the following functions reliably segfaults Postgres for me: CREATE LANGUAGE 'plperl'; CREATE LANGUAGE 'plperlu'; CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language 'plperlu'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; A possibly interesting note is that if I create "two, one, two two" it will not crash, but just 'one, two two" will.
On Thu, Feb 11, 2010 at 1:44 PM, Dave Olszewski <cxreg@pobox.com> wrote: > > The following bug has been logged online: > > Bug reference: =A0 =A0 =A05323 > Logged by: =A0 =A0 =A0 =A0 =A0Dave Olszewski > Email address: =A0 =A0 =A0cxreg@pobox.com > PostgreSQL version: 8.3.9 > Operating system: =A0 Linux > Description: =A0 =A0 =A0 =A0plperl and plperlu interaction segfaults > Details: > > Creating the following functions reliably segfaults Postgres for me: > > CREATE LANGUAGE 'plperl'; > CREATE LANGUAGE 'plperlu'; > CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language > 'plperlu'; > CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language > 'plperl'; > CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language > 'plperl'; > > A possibly interesting note is that if I create "two, one, two two" it wi= ll > not crash, but just 'one, two two" will. I think this might be the same problem previously discussed here: http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php Does that patch fix it? ...Robert
On Feb 11, 2010, at 10:02 PM, Robert Haas wrote: > On Thu, Feb 11, 2010 at 1:44 PM, Dave Olszewski <cxreg@pobox.com> wrote: >>=20 >> The following bug has been logged online: >>=20 >> Bug reference: 5323 >> Logged by: Dave Olszewski >> Email address: cxreg@pobox.com >> PostgreSQL version: 8.3.9 >> Operating system: Linux >> Description: plperl and plperlu interaction segfaults >> Details: >>=20 >> Creating the following functions reliably segfaults Postgres for me: >>=20 >> CREATE LANGUAGE 'plperl'; >> CREATE LANGUAGE 'plperlu'; >> CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language >> 'plperlu'; >> CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language >> 'plperl'; >> CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language >> 'plperl'; >>=20 >> A possibly interesting note is that if I create "two, one, two two" it w= ill >> not crash, but just 'one, two two" will. >=20 > I think this might be the same problem previously discussed here: >=20 > http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php Seems to be the same problem. Backtrace I'm getting on 8.4 is almost identi= cal to the one at the end of this post: http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php >=20 > Does that patch fix it? >=20 The problem doesn't appear on 9.0 alpha with that patch committed. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc
On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin <alexk@commandprompt.com> wrote: >> I think this might be the same problem previously discussed here: >> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php > > Seems to be the same problem. Backtrace I'm getting on 8.4 is almost identical to the one at the end of this post: > http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php > >> Does that patch fix it? > The problem doesn't appear on 9.0 alpha with that patch committed. It looks like the plperl.c change applies cleanly back to 8.2, though I haven't yet verified that it actually fixes the problem on all those branches. 8.1 does nothing at all instead of decrementing the reference count: - /* need we delete old entry? */ + hash_search(plperl_proc_hash, internal_proname, + HASH_REMOVE, NULL); + if (prodesc->reference) + SvREFCNT_dec(prodesc->reference); + free(prodesc->proname); + free(prodesc); I am not inclined to apply the additional regression tests, even on HEAD. ...Robert
On Thu, Feb 11, 2010 at 10:47 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin <alexk@commandprompt.com> wrote: >>> I think this might be the same problem previously discussed here: >>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php >> >> Seems to be the same problem. Backtrace I'm getting on 8.4 is almost identical to the one at the end of this post: >> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php >> >>> Does that patch fix it? >> The problem doesn't appear on 9.0 alpha with that patch committed. > > It looks like the plperl.c change applies cleanly back to 8.2, though > I haven't yet verified that it actually fixes the problem on all those > branches. Ah. Well. So it turns out that this patch causes any branch other than CVS HEAD to not compile, because select_perl_context() was only added to the tree on January 26th. And on CVS HEAD, the OP's test case doesn't crash. CREATE LANGUAGE 'plperl'; CREATE LANGUAGE 'plperlu'; CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language 'plperlu'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; Not sure where to go from here. The prerequisite patch ("Various small improvements and cleanups for PL/Perl") is not suitable for backpatching, so I think someone needs to prepare a cut-down patch that addresses this issue in a more surgical fashion. Also, would like to understand why the test case fails to fail on CVS HEAD. ...Robert
On Feb 12, 2010, at 6:21 AM, Robert Haas wrote: > On Thu, Feb 11, 2010 at 10:47 PM, Robert Haas <robertmhaas@gmail.com> wro= te: >> On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin <alexk@commandprompt.com= > wrote: >>>> I think this might be the same problem previously discussed here: >>>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php >>>=20 >>> Seems to be the same problem. Backtrace I'm getting on 8.4 is almost id= entical to the one at the end of this post: >>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php >>>=20 >>>> Does that patch fix it? >>> The problem doesn't appear on 9.0 alpha with that patch committed. >>=20 >> It looks like the plperl.c change applies cleanly back to 8.2, though >> I haven't yet verified that it actually fixes the problem on all those >> branches. >=20 >=20 > Not sure where to go from here. The prerequisite patch ("Various > small improvements and cleanups for PL/Perl") is not suitable for > backpatching, so I think someone needs to prepare a cut-down patch > that addresses this issue in a more surgical fashion. Also, would > like to understand why the test case fails to fail on CVS HEAD. >=20 Andrew Dunstan backpatched all versions down to 8.2 yesterday: http://archives.postgresql.org/message-id/20100212043203.08C6E7541C6@cvs.po= stgresql.org This eliminated the bug on my system (checked on 8.4). The problem appeared due to the context mismatch between the interpreter th= at created the reference to the compiled subroutine and the one that tried to decrement the referenc= e count. Setting a correct context fixed the problem. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc
On Fri, Feb 12, 2010 at 5:04 AM, Alexey Klyukin <alexk@commandprompt.com> w= rote: > > On Feb 12, 2010, at 6:21 AM, Robert Haas wrote: > >> On Thu, Feb 11, 2010 at 10:47 PM, Robert Haas <robertmhaas@gmail.com> wr= ote: >>> On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin <alexk@commandprompt.co= m> wrote: >>>>> I think this might be the same problem previously discussed here: >>>>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php >>>> >>>> Seems to be the same problem. Backtrace I'm getting on 8.4 is almost i= dentical to the one at the end of this post: >>>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php >>>> >>>>> Does that patch fix it? >>>> The problem doesn't appear on 9.0 alpha with that patch committed. >>> >>> It looks like the plperl.c change applies cleanly back to 8.2, though >>> I haven't yet verified that it actually fixes the problem on all those >>> branches. >> >> >> Not sure where to go from here. =A0The prerequisite patch ("Various >> small improvements and cleanups for PL/Perl") is not suitable for >> backpatching, so I think someone needs to prepare a cut-down patch >> that addresses this issue in a more surgical fashion. =A0Also, would >> like to understand why the test case fails to fail on CVS HEAD. >> > > Andrew Dunstan backpatched all versions down to 8.2 yesterday: > http://archives.postgresql.org/message-id/20100212043203.08C6E7541C6@cvs.= postgresql.org > > This eliminated the bug on my system (checked on 8.4). > The problem appeared due to the context mismatch between the interpreter = that created the reference > to the compiled subroutine and the one that tried to decrement the refere= nce count. Setting a correct context fixed the problem. Yeah, I saw that commit. Cool. ...Robert