Re: BUG #14490: psql and createdb crash with SIGSEGV

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(at)marcelruff(dot)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?