[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-postgresql-public] Bug#704802: plperl crashes immediately on kfreebsd



As suggested by dam, I'll add perl@packages.debian.org to the CC list.

Re: To 704802@bugs.debian.org 2013-05-21 <[🔎] 20130521194112.GA24292@msgid.df7cb.de>
> Re: Peter Eisentraut 2013-04-05 <20130406030939.14051.80312.reportbug@vanquo.pezone.net>
> > Creating a plperl function on kfreebsd (amd64) immediately crashes the
> > PostgreSQL server in the plperl.so module.  You can see this either by
> > running the built-in regression tests (should probably be done during
> > the build anyway) or by running the tests from
> > t/020_create_sql_remove.t in the postgresql-common package.
> > 
> > Everything else works, including all the other procedural languages
> > (Python, Tcl).
> > 
> > I can also reproduce this problem with PostgreSQL Git master, so it's
> > not specific to the packaging.  The actual problem might be somewhere
> > down the stack (libperl etc.).
> 
> I've forwarded this to the pgsql-hackers list.
> 
> Christoph
> -- 
> cb@df7cb.de | http://www.df7cb.de/

> Date: Tue, 14 May 2013 23:42:02 -0700
> From: Christoph Berg <cb@df7cb.de>
> To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
> Subject: [HACKERS] plperl segfault in plperl_trusted_init() on kfreebsd
> 
> The newly activated "make check-world" on Debian (I haven't found the
> time yet to follow up on the other threads I opened for that, sorry)
> actually found something: plperl and plperlu segfault on the
> kfreebsd-amd64 and kfreebsd-i386 architectures. These are FreeBSD 9
> kernels with a GNU/Debian userland.
> 
> libperl 5.14.2-21
> gcc (Debian 4.7.2-5) 4.7.2
> libc0.1 2.13-38
> 
> Here's what I did:
> 
> ./configure
> cd src && make
> cd pl/plperl && make clean && make CFLAGS="-g"
> make check
> 
> ../../../src/test/regress/pg_regress --inputdir=. --temp-install=./tmp_check --top-builddir=../../..   --dbname=pl_regression --load-extension=plperl  --load-extension=plperlu plperl plperl_lc plperl_trigger plperl_shared plperl_elog plperl_util plperl_init plperlu plperl_array plperl_plperlu
> ============== creating temporary installation        ==============
> ============== initializing database system           ==============
> ============== starting postmaster                    ==============
> running on port 57532 with PID 29715
> ============== creating database "pl_regression"      ==============
> CREATE DATABASE
> ALTER DATABASE
> ============== installing plperl                      ==============
> CREATE EXTENSION
> ============== installing plperlu                     ==============
> CREATE EXTENSION
> ============== running regression test queries        ==============
> test plperl                   ... FAILED (test process exited with exit code 2)
> test plperl_lc                ... FAILED (test process exited with exit code 2)
> test plperl_trigger           ... FAILED (test process exited with exit code 2)
> test plperl_shared            ... FAILED (test process exited with exit code 2)
> test plperl_elog              ... FAILED (test process exited with exit code 2)
> test plperl_util              ... FAILED (test process exited with exit code 2)
> test plperl_init              ... FAILED (test process exited with exit code 2)
> test plperlu                  ... FAILED (test process exited with exit code 2)
> test plperl_array             ... FAILED (test process exited with exit code 2)
> test plperl_plperlu           ... FAILED (test process exited with exit code 2)
> ============== shutting down postmaster               ==============
> 
> ========================
>  10 of 10 tests failed. 
> ========================
> 
> myon@debian-kfreebsd-amd64:~/postgresql-9.3/src/pl/plperl $ gdb tmp_check/install/usr/local/pgsql/bin/postgres tmp_check/data/postgres.core 
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-kfreebsd-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/myon/postgresql/postgresql-9.3/src/pl/plperl/tmp_check/install/usr/local/pgsql/bin/postgres...(no debugging symbols found)...done.
> [New process 100072]
> Core was generated by `postgres'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x000000080a6e964e in plperl_trusted_init () at plperl.c:937
> 937		if (SvTRUE(ERRSV))
> (gdb) bt
> #0  0x000000080a6e964e in plperl_trusted_init () at plperl.c:937
> #1  0x000000080a6e85dd in select_perl_context (trusted=1 '\001') at plperl.c:600
> #2  0x000000080a6f133e in compile_plperl_function (fn_oid=49152, is_trigger=0 '\000') at plperl.c:2661
> #3  0x000000080a6edc55 in plperl_validator (fcinfo=0x7fffffffbde0) at plperl.c:1900
> #4  0x00000000007200d6 in OidFunctionCall1Coll ()
> #5  0x00000000004ec30e in ProcedureCreate ()
> #6  0x000000000054c44e in CreateFunction ()
> #7  0x00000000006588af in ProcessUtilitySlow.isra.2 ()
> #8  0x0000000000657b5c in standard_ProcessUtility ()
> #9  0x0000000000655477 in PortalRunUtility ()
> #10 0x0000000000656065 in PortalRunMulti ()
> #11 0x0000000000656b52 in PortalRun ()
> #12 0x0000000000653f03 in PostgresMain ()
> #13 0x0000000000464411 in ServerLoop ()
> #14 0x0000000000614491 in PostmasterMain ()
> #15 0x0000000000464c4b in main ()
> (gdb) l
> 932		/* use original require while we set up */
> 933		PL_ppaddr[OP_REQUIRE] = pp_require_orig;
> 934		PL_ppaddr[OP_DOFILE] = pp_require_orig;
> 935	
> 936		eval_pv(PLC_TRUSTED, FALSE);
> 937		if (SvTRUE(ERRSV))
> 938			ereport(ERROR,
> 939					(errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
> 940					 errcontext("while executing PLC_TRUSTED")));
> 941	
> 
> 
> LOG:  server process (PID 29740) was terminated by signal 11: Segmentation fault
> DETAIL:  Failed process was running: CREATE OR REPLACE FUNCTION perl_int(int) RETURNS INTEGER AS $$
>         return undef;
>         $$ LANGUAGE plperl;
> LOG:  terminating any other active server processes
> 
> I'm not an expert in libperl, so please excuse if I didn't include
> something in this report. I have the coredumps here so I can provide
> more information.
> 
> Christoph
> -- 
> cb@df7cb.de | http://www.df7cb.de/

> Date: Fri, 17 May 2013 11:06:24 -0400
> From: Andrew Dunstan <andrew@dunslane.net>
> To: Christoph Berg <cb@df7cb.de>, Stephen Frost <sfrost@snowman.net>, Tom
>  Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers
>  <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] plperl segfault in plperl_trusted_init() on kfreebsd
> 
> 
> On 05/16/2013 09:14 AM, Christoph Berg wrote:
> >Re: Stephen Frost 2013-05-16 <20130516123344.GT4361@tamriel.snowman.net>
> >>* Christoph Berg (cb@df7cb.de) wrote:
> >>>That was because the plain "./configure" version (for a minimal way to
> >>>reproduce) didn't built with debug symbols. The original gcc line from the
> >>>Debian build log is:
> >>It did, but Debian (and Ubuntu and friends) pull the debugging symbols
> >>out of the binaries and stick them into independent packages, allowing
> >>you to only install them if you need/want to.
> >>
> >>Try installing postgresql-9.3-dbg.  At least the postgresql-9.2-dbg
> >>package on my system also includes the plperl.so debugging symbols.
> >This wasn't the Debian build, but just plain "./configure --with-perl"
> >without any other arguments. As said in the previous mail, both this
> >and the Debian build segfault here. (Which means there is no -dbg
> >package because the build fails.)
> >
> >I don't think this makes a difference anyway - I can pull more
> >information out from that core, but that needs someone saying which
> >info, because that's the place where I'm lost at.
> >
> >(I'll be away until monday.)
> >
> >
> 
> 
> I have reproduced this. It happens with both the distro perl and a
> home-built perl 5.14. AFAICT this is a Perl bug. Any reference at
> all to ERRSV at the point this occurs causes a core dump, even just
> assigning it to a local SV * variable. Maybe you should take this up
> with the Perl people. It certainly seems mysterious that this should
> only occur on this platform.
> 
> cheers
> 
> andrew
> 

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/


Reply to: