Re: [BUGS] BUG #14490: psql and createdb crash with SIGSEGV - Mailing list pgsql-bugs

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