Re: BUG #2246: Bad malloc interactions: ecpg, openssl - Mailing list pgsql-bugs

On Mon, 13 Feb 2006, Stephen Frost wrote:

> Hmm, alright, well, this is at least not the fault of the patch of mine
> which was included in Debian's 8.1.2-2 Postgres release. :)  You might
> try compiling some debs with debugging enabled.  This is (reasonably)
> straight-forward:
>
> (as root:)
> aptitude install build-essential debhelper cdbs bison perl libperl-dev \
>     tk8.4-dev flex libreadline5-dev libssl-dev zlib1g-dev \
>     libpam0g-dev libxml2-dev libkrb5-dev libxslt1-dev python-dev \
>     gettext bzip2 fakeroot
> (as user:)
> apt-get source postgresql-8.1
> cd postgresql-8.1-8.1.0
> export DEB_BUILD_OPTIONS="nostrip"
> dpkg-buildpackage -uc -us -rfakeroot
>
> Should produce .debs in the parent directory which have debugging
> information.  Another useful build option is "noopt", ie:
> export DEB_BUILD_OPTIONS="nostrip noopt", though that could make the
> error go disappear.  It'd be terribly nice if you could do this and
> provide a gdb backtrace with debugging... :)
>
>     Thanks,
>
>         Stephen

Alright, I have built a system with the symbols left into the binaries.

It still crashes with the "corrupted double-linked list" error.

Running with ElectricFence the backtrace I get is:

  Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.

ElectricFence Aborting: Allocating 0 bytes, probably a bug.

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16384 (LWP 1895)]
0x401c4851 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x401c4851 in kill () from /lib/libc.so.6
#1  0x40037dd5 in EF_Abort () from /usr/lib/libefence.so.0
#2  0x40037823 in memalign () from /usr/lib/libefence.so.0
#3  0x400379ad in malloc () from /usr/lib/libefence.so.0
#4  0x40037a10 in calloc () from /usr/lib/libefence.so.0
#5  0x404a282f in krb5_set_default_tgs_ktypes () from /usr/lib/libkrb5.so.3
#6  0x402c9b26 in pg_krb5_init (PQerrormsg=0x0) at fe-auth.c:119
#7  0x402ca304 in pg_fe_getauthname (PQerrormsg=0xbffff29c "l\031")
    at fe-auth.c:176
#8  0x402cc861 in conninfo_parse (conninfo=<value optimized out>,
    errorMessage=0x4057afe8) at fe-connect.c:2719
#9  0x402cc983 in connectOptions1 (conn=0x4057acdc, conninfo=0x0)
    at fe-connect.c:362
#10 0x402cda11 in PQsetdbLogin (pghost=0x40574ffc "nc3", pgport=0x0,
    pgoptions=0x0, pgtty=0x0, dbName=0x40576ff8 "andrew5",
    login=0xbffffc31 "andrew5", pwd=0xbffffc3c "testbed") at fe-connect.c:568
#11 0x40030fe7 in ECPGconnect (lineno=191, c=0, name=0xbffffc22 "andrew5@nc3",
    user=0xbffffc31 "andrew5", passwd=0x0,
    connection_name=0xbffff8b0 "CorrectnessCheck", autocommit=0)
    at connect.c:452
#12 0x08049ecb in DBConnect (arg_connection=0xbffff964 "CorrectnessCheck")
    at client_test.pgcc:191
#13 0x0804a14f in DoCorrectnessChecks () at client_test.pgcc:231
#14 0x0804aa08 in main (argc=9, argv=0xbffffa74) at client_test.pgcc:526

Again, it is showing a bad malloc in what appears to be some code using
kerberos.  But there's nothing in my setup that I can think of right now
that should induce a connection to be set up using kerberos.

--Andrew J. Klosterman
andrew5@ece.cmu.edu