Re: Bug in ecpg lib ?

leif(at)crysberg(dot)dk wrote:
> I have now generate a rather small example where I
> experience the problem, attached. It is linked with the
> mudflapth library using the commands below. You may have to
> change the DBNAME and DBUSER. The delay just before the
> pthread_cancel(), i.e. sleep(10), is rather critical for the
> problem to appear and you might have to change it to
> something less. On some very slow machines I wasn't able to
> produce the problem.
>
[...]
>
> And this is the output from running the program:
>
> leif$ LD_LIBRARY_PATH=/usr/local/Packages/gcc-4.4.0/lib/ ./crashex
> Couldn't open somename(at)localhost:5432
> 2+2=0.
> *** glibc detected *** /home/leif/tmp/crashex: free():
> invalid pointer: 0x081f3958 ***
[...]
> Aborted (core dumped)
>
>
> leif$ gdb ~/tmp/crashex core.30920
[...]
> #0 0xffffe405 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xffffe405 in __kernel_vsyscall ()
> #1 0xf7bef335 in raise () from /lib32/libc.so.6
> #2 0xf7bf0cb1 in abort () from /lib32/libc.so.6
> #3 0xf7c286ec in ?? () from /lib32/libc.so.6
> #4 0xf7c30615 in ?? () from /lib32/libc.so.6
> #5 0xf7c34080 in free () from /lib32/libc.so.6
> #6 0xf7d39061 in free (buf=0x81f3958) at
> ../../../libmudflap/mf-hooks1.c:241
> #7 0xf7e3fb5c in ecpg_sqlca_key_destructor () from
> /lib32/libecpg.so.6
> #8 0xf7d1bbb0 in __nptl_deallocate_tsd () from /lib32/libpthread.so.0
> #9 0xf7d1c509 in start_thread () from /lib32/libpthread.so.0
> #10 0xf7c9d08e in clone () from /lib32/libc.so.6
> (gdb)

I ran your sample with gdb against PostgreSQL 8.4, and
ecpg_sqlca_key_destructor() was called only once, for a valid pointer,
one that was previously allocated with malloc().
Could you check if ecpg_sqlca_key_destructor() is called more than once if
you run the sample?

Are you aware that in your sample run the connection attempt failed?
It does not matter, ecpg should do the right thing anyway.

What I notice about your program is that you connect to the database
in the main thread, then start a new thread and use the connection in that
new thread.

I don't know, but I'd expect that since ecpg keeps a thread-specific
sqlca, this could cause problems. Indeed I find with the debugger that in
your sample sqlca is allocated and initialized twice, once when the
catabase connection is attempted, and once when the SQL statement is run.

I think that the "good" way to do it would be:
- start a thread
- connect to the database
- do work
- disconnect from the database
- terminate the thread

Maybe somebody who knows more about ecpg can say if what you are doing
should work or not.

Yours,
Laurenz Albe