On Tue, 14 Feb 2006, Jens-Wolfhard Schicke wrote:
> --On Montag, Februar 13, 2006 21:25:30 -0500 Stephen Frost
> <sfrost@snowman.net> wrote:
>
> > * Andrew Klosterman (andrew5@ece.cmu.edu) wrote:
> >> > Seems kind of unlikely... What exact (.deb) versions of libpq and
> >> > Postgres are you using? You originally posted w/ 8.1.0 but perhaps on
> >> > the client you had something more recent?
> > 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
> You might want to add valgrind to this list. It analyzes code on assembler
> basis and does a lot of memory checking / undefined variables checking
> while the program runs. Fixed all SIGSEGV I ever encoutered which were not
> infinite recursions.
>
> Mit freundlichem Gruß
> Jens Schicke
I tried valgrind this morning. It detected problems in the depths of the
code behind ECPGconnect() down through SSL_read() and inflate(). Also,
there was trouble reported behind ECPGconnect() -> PQsetdbLogin() ->
pqGetpwuid() -> getpwuid_r() -> _dl_open() -> into the depths of
/lib/ld-2.3.5.so. Valgrind got so upset at the number of errors it found
that it gave up. Nothing bad seemed to show up in the code that I wrote.
But, while running under valgrind, the original program that manifests the
error condition runs just fine and to completion (maybe the errors are
just ignored in valgrind's replacement version of malloc as they are
with the MALLOC_CHECK_ environment variable set).
I'm moving on to try building the binaries without removing the symbols.
Hopefully that will give more useful information...
--Andrew J. Klosterman
andrew5@ece.cmu.edu
