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

From Tom Lane
Subject Re: BUG #2246: Bad malloc interactions: ecpg, openssl
Date
Msg-id 4050.1139861765@sss.pgh.pa.us
Whole thread Raw
In response to BUG #2246: Bad malloc interactions: ecpg, openssl  ("Andy Klosterman" <andrew5@ece.cmu.edu>)
Responses Re: BUG #2246: Bad malloc interactions: ecpg, openssl
Re: BUG #2246: Bad malloc interactions: ecpg, openssl
List pgsql-bugs
Andrew Klosterman <andrew5@ece.cmu.edu> writes:
> I threw in a pthread mutex around the code making the database connections
> for each of my threads.  The problem is still there ("corrupted
> double-linked list").

> Even tuning things down and instructing my code to only run a single
> pthread manifests the problem over an SSL connection.

Hmm.  Based on that, the problem is starting to smell more like a
garden-variety memory clobber, for instance malloc'ing a chunk smaller
than the data that's later stuffed into it.  It might be worth running
the program under something like ElectricFence, which will catch the
offender on-the-spot rather than only later when corruption of malloc's
private data structures is detected.

Looking back at your original message, I wonder if it could be the
combination of ecpg and SSL that triggers it?  I'd have thought that
libpq/SSL alone would be pretty well wrung out, but ecpg is not so
widely used.

BTW, you did say this was i386 right?  If it were a 64-bit architecture,
I'd be about ready to bet money on the wrong-malloc-size-calculation
theory.

> Tracking down exactly what's tickling the problem in this case could be
> tricky...

Yeah :-(.  If you aren't able to narrow it further by yourself, please
try to put together a self-contained test case.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "James Gray"
Date:
Subject: BUG #2258: debug_print_plan doesn't work for cursors
Next
From: Tom Lane
Date:
Subject: Re: BUG #2246: Bad malloc interactions: ecpg, openssl