Thread: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

[BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
mr@marcelruff.info
Date:
The following bug has been logged on the website:

Bug reference:      14490
Logged by:          Marcel Ruff
Email address:      mr@marcelruff.info
PostgreSQL version: 9.6.1
Operating system:   Debian GNU/Linux 8 (jessie) 3.18.44 x86_64
Description:

psql --version
psql (PostgreSQL) 9.6.1

psql 
Speicherzugriffsfehler

ldd /usr/local/pgsql/bin/psql
        linux-vdso.so.1 (0x00007ffeaf3ba000)
        libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x00007f0d74ba8000)
        libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
(0x00007f0d74958000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0d74650000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0d742a0000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f0d74080000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007f0d73e50000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0d74dd8000)

strace pqsl
...
connect(3, {sa_family=AF_LOCAL, sun_path="/tmp/.s.PGSQL.5432"}, 110) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
poll([{fd=3, events=POLLOUT|POLLERR}], 1, 4294967295) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, "\0\0\0R\0\3\0\0user\0watchee\0database\0wa"..., 82, MSG_NOSIGNAL,
NULL, 0) = 82
poll([{fd=3, events=POLLIN|POLLERR}], 1, 4294967295) = 1 ([{fd=3,
revents=POLLIN}])
recvfrom(3, "R\0\0\0\10\0\0\0\0E\0\0\0\\SFATAL\0VFATAL\0C3D0"..., 16384, 0,
NULL, NULL) = 102
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++


createdb xxxx 
crashes with SIGSEGV as well


Compiled with
./configure  --with-pam --with-libxml --with-libxslt

Thank you
Marcel

Note: The server has no DNS setup


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Michael Paquier
Date:
On Wed, Jan 11, 2017 at 5:29 AM,  <mr@marcelruff.info> wrote:
> Bug reference:      14490
> Logged by:          Marcel Ruff
> Email address:      mr@marcelruff.info
> PostgreSQL version: 9.6.1
> Operating system:   Debian GNU/Linux 8 (jessie) 3.18.44 x86_64
> Description:
>
> psql --version
> psql (PostgreSQL) 9.6.1
>
> strace pqsl
> ...
> connect(3, {sa_family=AF_LOCAL, sun_path="/tmp/.s.PGSQL.5432"}, 110) = 0
> getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
> poll([{fd=3, events=POLLOUT|POLLERR}], 1, 4294967295) = 1 ([{fd=3,
> revents=POLLOUT}])
> sendto(3, "\0\0\0R\0\3\0\0user\0watchee\0database\0wa"..., 82, MSG_NOSIGNAL,
> NULL, 0) = 82
> poll([{fd=3, events=POLLIN|POLLERR}], 1, 4294967295) = 1 ([{fd=3,
> revents=POLLIN}])
> recvfrom(3, "R\0\0\0\10\0\0\0\0E\0\0\0\\SFATAL\0VFATAL\0C3D0"..., 16384, 0,
> NULL, NULL) = 102
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
> +++ killed by SIGSEGV +++
>
> createdb xxxx
> crashes with SIGSEGV as well

This is strange. No buildfarm machines complain about a similar
behavior... Nor do my dev environments say something.
-- 
Michael


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Alvaro Herrera
Date:
Michael Paquier wrote:
> On Wed, Jan 11, 2017 at 5:29 AM,  <mr@marcelruff.info> wrote:
> > Bug reference:      14490
> > Logged by:          Marcel Ruff
> > Email address:      mr@marcelruff.info
> > PostgreSQL version: 9.6.1
> > Operating system:   Debian GNU/Linux 8 (jessie) 3.18.44 x86_64
> > Description:
> >
> > psql --version
> > psql (PostgreSQL) 9.6.1
> >
> > strace pqsl

> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
> > +++ killed by SIGSEGV +++
> >
> > createdb xxxx
> > crashes with SIGSEGV as well
> 
> This is strange. No buildfarm machines complain about a similar
> behavior... Nor do my dev environments say something.

We need to see a stack trace to be able to say anything.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Marcel Ruff
Date:
Does this help?

valgrind psql
==977== Memcheck, a memory error detector
==977== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==977== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==977== Command: psql
==977==
==977== Invalid write of size 1
==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
==977==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==977==
==977==
==977== Process terminating with default action of signal 11 (SIGSEGV)
==977==  Access not within mapped region at address 0x0
==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
==977==  If you believe this happened as a result of a stack
==977==  overflow in your program's main thread (unlikely but
==977==  possible), you can try to increase the size of the
==977==  main thread stack using the --main-stacksize= flag.
==977==  The main thread stack size used in this run was 8388608.
==977==
==977== HEAP SUMMARY:
==977==     in use at exit: 38,140 bytes in 71 blocks
==977==   total heap usage: 185 allocs, 114 frees, 53,697 bytes allocated
==977==
==977== LEAK SUMMARY:
==977==    definitely lost: 34 bytes in 1 blocks
==977==    indirectly lost: 0 bytes in 0 blocks
==977==      possibly lost: 0 bytes in 0 blocks
==977==    still reachable: 38,106 bytes in 70 blocks
==977==         suppressed: 0 bytes in 0 blocks
==977== Rerun with --leak-check=full to see details of leaked memory
==977==
==977== For counts of detected and suppressed errors, rerun with: -v
==977== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler


I will now recompile everything,

thank you
Marcel


On 11.01.2017 03:06, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Wed, Jan 11, 2017 at 5:29 AM,  <mr@marcelruff.info> wrote:
>>> Bug reference:      14490
>>> Logged by:          Marcel Ruff
>>> Email address:      mr@marcelruff.info
>>> PostgreSQL version: 9.6.1
>>> Operating system:   Debian GNU/Linux 8 (jessie) 3.18.44 x86_64
>>> Description:
>>>
>>> psql --version
>>> psql (PostgreSQL) 9.6.1
>>>
>>> strace pqsl
>>> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
>>> +++ killed by SIGSEGV +++
>>>
>>> createdb xxxx
>>> crashes with SIGSEGV as well
>> This is strange. No buildfarm machines complain about a similar
>> behavior... Nor do my dev environments say something.
> We need to see a stack trace to be able to say anything.
>



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Michael Paquier
Date:
On Wed, Jan 11, 2017 at 4:59 PM, Marcel Ruff <mr@marcelruff.info> wrote:
> Does this help?
>
> valgrind psql
> ==977== Memcheck, a memory error detector
> ==977== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==977== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==977== Command: psql
> ==977==
> ==977== Invalid write of size 1
> ==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
> ==977==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==977==
> ==977==
> ==977== Process terminating with default action of signal 11 (SIGSEGV)
> ==977==  Access not within mapped region at address 0x0
> ==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
> ==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
> ==977==  If you believe this happened as a result of a stack
> ==977==  overflow in your program's main thread (unlikely but
> ==977==  possible), you can try to increase the size of the
> ==977==  main thread stack using the --main-stacksize= flag.
> ==977==  The main thread stack size used in this run was 8388608.
> ==977==
> ==977== HEAP SUMMARY:
> ==977==     in use at exit: 38,140 bytes in 71 blocks
> ==977==   total heap usage: 185 allocs, 114 frees, 53,697 bytes allocated
> ==977==
> ==977== LEAK SUMMARY:
> ==977==    definitely lost: 34 bytes in 1 blocks
> ==977==    indirectly lost: 0 bytes in 0 blocks
> ==977==      possibly lost: 0 bytes in 0 blocks
> ==977==    still reachable: 38,106 bytes in 70 blocks
> ==977==         suppressed: 0 bytes in 0 blocks
> ==977== Rerun with --leak-check=full to see details of leaked memory
> ==977==
> ==977== For counts of detected and suppressed errors, rerun with: -v
> ==977== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> Speicherzugriffsfehler
>
> I will now recompile everything,

Could you take a backtrace with gdb and "bt" for example?
-- 
Michael


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Marcel Ruff
Date:
I have compiled 9.6.1 completely again and the bug is gone.

thank you  for taking care,
Marcel


On 11.01.2017 09:04, Michael Paquier wrote:
> On Wed, Jan 11, 2017 at 4:59 PM, Marcel Ruff <mr@marcelruff.info> wrote:
>> Does this help?
>>
>> valgrind psql
>> ==977== Memcheck, a memory error detector
>> ==977== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==977== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
>> ==977== Command: psql
>> ==977==
>> ==977== Invalid write of size 1
>> ==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
>> ==977==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
>> ==977==
>> ==977==
>> ==977== Process terminating with default action of signal 11 (SIGSEGV)
>> ==977==  Access not within mapped region at address 0x0
>> ==977==    at 0x4E4DF3C: resetPQExpBuffer (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E44921: pqPrepareAsyncResult (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E44B4D: PQgetResult (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E40877: PQconnectPoll (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E4110D: connectDBComplete (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x4E418EE: PQconnectdbParams (in /usr/local/pgsql/lib/libpq.so.5.9)
>> ==977==    by 0x405377: main (in /usr/local/pgsql/bin/psql)
>> ==977==  If you believe this happened as a result of a stack
>> ==977==  overflow in your program's main thread (unlikely but
>> ==977==  possible), you can try to increase the size of the
>> ==977==  main thread stack using the --main-stacksize= flag.
>> ==977==  The main thread stack size used in this run was 8388608.
>> ==977==
>> ==977== HEAP SUMMARY:
>> ==977==     in use at exit: 38,140 bytes in 71 blocks
>> ==977==   total heap usage: 185 allocs, 114 frees, 53,697 bytes allocated
>> ==977==
>> ==977== LEAK SUMMARY:
>> ==977==    definitely lost: 34 bytes in 1 blocks
>> ==977==    indirectly lost: 0 bytes in 0 blocks
>> ==977==      possibly lost: 0 bytes in 0 blocks
>> ==977==    still reachable: 38,106 bytes in 70 blocks
>> ==977==         suppressed: 0 bytes in 0 blocks
>> ==977== Rerun with --leak-check=full to see details of leaked memory
>> ==977==
>> ==977== For counts of detected and suppressed errors, rerun with: -v
>> ==977== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>> Speicherzugriffsfehler
>>
>> I will now recompile everything,
> Could you take a backtrace with gdb and "bt" for example?




-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Alvaro Herrera
Date:
Marcel Ruff wrote:
> I have compiled 9.6.1 completely again and the bug is gone.

I suppose you may have had a partial rebuild -- i.e. you built once,
then updated the source tree and rebuilt, but not all files were
correctly rebuilt.  Since you seem to be compiling from source, maybe
you are missing --enable-depend to configure.

IMO we should enable that flag by default.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV

From
Marcel Ruff
Date:
I have added  " --enable-depend" as default,
thank you
Marcel

On 11.01.2017 14:19, Alvaro Herrera wrote:
> Marcel Ruff wrote:
>> I have compiled 9.6.1 completely again and the bug is gone.
> I suppose you may have had a partial rebuild -- i.e. you built once,
> then updated the source tree and rebuilt, but not all files were
> correctly rebuilt.  Since you seem to be compiling from source, maybe
> you are missing --enable-depend to configure.
>
> IMO we should enable that flag by default.
>



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs