Hi Laurenz,
Thanks for the suggestion. It sure wasn't easy, but I should have done that right away. It turned out not to be in
theecpg module, but somewhere in my own code (of course ;-) ). At least I haven't been able to reproduce it in a simple
exampleand I haven't figured out where in my own code yet either.
Leif
----- "Albe Laurenz" <laurenz.albe@wien.gv.at> wrote:
> leif@crysberg.dk wrote:
> > I'm using PostgreSQL in a server project that uses many
> > forks and many threads in each forked process.
> >
> > Almost everytime I do a pthread_cancel() I get a SIGSEGV.
> > I have then linked the libmudflapth into my program to catch
> > the problem sooner and now that reports either 'invalid
> > pointer' or 'double free or corruption' when a thread is
> > cancelled. Typically I have 2 database connection opened
> > before any of the threads are created. I am pretty sure that
> > I'm only using 1 connection in any 1 thread, i.e. only 2 of
> > the threads are doing database access and using each their
> > allocated connection.
> >
> > After the main thread has done a pthread_cancel() I get a
> > "mudflapth dump" with the following trace back (the abort
> > comes from the mudflapth lib when detecting the bad pointer):
> >
> > #0 0xffffe405 in __kernel_vsyscall ()
> > #1 0xf7ca2335 in raise () from /lib32/libc.so.6
> > #2 0xf7ca3cb1 in abort () from /lib32/libc.so.6
> > #3 0xf7cdb6ec in ?? () from /lib32/libc.so.6
> > #4 0xf7ce71ab in free () from /lib32/libc.so.6
> > #5 0xf7dec061 in free (buf=0x87ed138) at
> ../../../libmudflap/mf-hooks1.c:241
> > #6 0xf7ef2b5c in ecpg_sqlca_key_destructor () from
> /lib32/libecpg.so.6
> > #7 0xf7dcebb0 in __nptl_deallocate_tsd () from
> /lib32/libpthread.so.0
> > #8 0xf7dcf509 in start_thread () from /lib32/libpthread.so.0
> > #9 0xf7d5008e in clone () from /lib32/libc.so.6
> >
> > Looking in the ecpg_sqlca_key_destructor(), it seems to me
> > that the sqlca can be deallocated several times !? (I'm not
> > too much into the Postgres code including ecpg, so that is a
> > novice point of view.)
> >
> > I have tried both pgsql-8.3.5 and pgsql-8.4rc1, with
> > exactly the same result and and on many different Linux
> > systems, mainly Slackware 10.2 and Ubuntu 7. I have on all
> > systems configured and compiled Postgres with this configure line:
> >
> > ./configure --prefix=/usr/local/Packages/pgsql-8.3.5
> > --with-openssl --enable-thread-safety
>
> Could you create a small sample program that reproduces the bug?
>
> That would make it easier for me or somebody else to do something
> about it.
>
> Yours,
> Laurenz Albe