valgrind為何 報 ecpg記憶體洩露錯誤？根據我的同事的研究成果：
究其原因，全域性變數 sqlca 由malloc形成,但是釋放時是隱含的：
ecpg_sqlca_key_destructor函式呼叫 free 進行釋放。
複製**
bool
ecpgconnect(int lineno, int c, const char *name, const char *user, const char *passwd, const char *connection_name, int autocommit)
return (sqlca);
#else
return (&sqlca);
#endif }
static void
ecpg_sqlca_key_init(void)
static void
ecpg_sqlca_key_destructor(void *arg)
複製**
用gdb來除錯，也可以驗證這一點：
複製**
gnu gdb (gdb) red hat enterprise linux (7.2-50.el6)
license gplv3+: gnu gpl version 3 or later
this is free software: you are free to change and redistribute it.
there is no warranty, to the extent permitted by law. type "show copying"
and "show warranty" for details.
this gdb was configured as "i686-redhat-linux-gnu".
for bug reporting instructions, please see: .
(gdb) file memoryleak
reading symbols from /usr/local/pgsql/bin/memoryleak...done.
(gdb) break main
breakpoint 1 at 0x804875e: file memoryleak.pgc, line 51.
(gdb) run
starting program: /usr/local/pgsql/bin/memoryleak
[thread debugging using libthread_db enabled]
breakpoint 1, main (argc=1, ar**=0xbffff6f4) at memoryleak.pgc:51
51 performtask( 25 );
missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6.i686
(gdb) delete
delete all breakpoints? (y or n) y
(gdb) break ecpg_sqlca_key_destructor
breakpoint 2 at 0x1af9b2: file misc.c, line 124.
(gdb) list misc.c:124
119120 #ifdef enable_thread_safety
121 static void
122 ecpg_sqlca_key_destructor(void *arg)
123
126127 static void
128 ecpg_sqlca_key_init(void)
(gdb) break misc.c:147
breakpoint 3 at 0x1afa4e: file misc.c, line 147.
(gdb) list misc.c:134,misc.c:149
134 struct sqlca_t *
135 ecpgget_sqlca(void)
136
149 return (sqlca);
(gdb) cont
continuing.
[new thread 0xb7ff0b70 (lwp 2936)]
[switching to thread 0xb7ff0b70 (lwp 2936)]
breakpoint 3, ecpgget_sqlca () at misc.c:147
147 pthread_setspecific(sqlca_key, sqlca);
(gdb) where
#0 ecpgget_sqlca () at misc.c:147
#1 0x001aed62 in ecpgconnect (lineno=29, c=0, name=0xb7400468 "[email protected]:5432", user=0x804884b "postgres", passwd=0x804884b "postgres",
connection_name=0x8048844 "dbconn", autocommit=0) at connect.c:268
#2 0x080486bf in work () at memoryleak.pgc:29
#3 0x00117a49 in start_thread () from /lib/libpthread.so.0
#4 0x00353e1e in clone () from /lib/libc.so.6
(gdb) print sqlca
$1 = (struct sqlca_t *) 0xb7400490
(gdb) cont
continuing.
conncet ok
breakpoint 2, ecpg_sqlca_key_destructor (arg=0xb7400490) at misc.c:124
124 free(arg); /* sqlca structure allocated in ecpgget_sqlca */
missing separate debuginfos, use: debuginfo-install libgcc-4.4.6-4.el6.i686
(gdb) print arg
$2 = (void *) 0xb7400490
(gdb) cont
continuing.
[thread 0xb7ff0b70 (lwp 2936) exited]
program exited normally.
(gdb)
複製**
我的追記：後來經過確認，這還不是全部，gdb執行時加了開關才會如此。
需要加入 pthread_exit（null）執行緒終止退出函式，才會觸發。目前，仍然被認為是有記憶體洩漏的。
下面會記錄我用普通方法得到的結論。
valgrind 報告 ecpg記憶體洩露 二
真是原因到底是什麼呢？由於 exec sql connect 而導致 valgrind 報告 記憶體洩露錯誤。那麼在同乙個程式裡面，加入 exec sql disconnect 後，會如何呢？驗證的結果是，依然如此，還是會說 still reachable 220 bytes in 1 blocks...
valgrind 報告 ecpg記憶體洩露 四
我執行測試後的結論是這樣的 確實發生了記憶體洩漏。沒有 sqlca區域。因為，我修改了 src inte ces ecpg ecpglib misc.c的 後，ifdef enable thread safety static void ecpg sqlca key destructor void ...
valgrind 報告 ecpg記憶體洩露 二
真是原因到底是什麼呢？由於 exec sql connect 而導致 valgrind 報告 記憶體洩露錯誤。那麼在同乙個程式裡面，加入 exec sql disconnect 後，會如何呢？驗證的結果是，依然如此，還是會說 still reachable 220 bytes in 1 blocks...