"yep, agree'ing... BTW, debugging memory leaks may be done with valgrind. Which
is our favorite approach to identify these kind of issues.
Ah so someone else uses valgrind!!
any opinion about what I ask here?
On Mon, Jan 23, 2006, fred wrote:
> If someone could take a look at some of these....
> Eg invalid read size 4 in lock....ie
> static void lock(List *list)
> gw_assert(list != NULL);
> what is wrong here? anyone? and why would valgrind report this...kannel
> seems to be working fine........
Some memory allocations are often zeroed out or have a predictable
content, it could explain why kannel works despite accessing
> for the Question here I'm more concerned about those invalid reads...to do
> with the library code....
I don't understand your question.
> ==3368== Thread 6:
> ==3368== Invalid read of size 4
> ==3368== at 0x80D2683: lock (list.c:525)
> ==3368== by 0x80D2265: gwlist_remove_producer (list.c:398)
> ==3368== by 0x8057EDA: smsboxc_run (bb_boxc.c:1196)
> ==3368== by 0x80C903F: new_thread (gwthread-pthread.c:346)
> ==3368== by 0x40B6DFB: start_thread (in /lib/tls/libpthread-0.60.so)
> ==3368== by 0x438DF29: clone (in /lib/tls/libc-2.3.2.so)
If this is the read you mention, then you should get a fresher kannel
build or remove your local changes since there's no
gwlist_remove_producer call in smsboxc_run at bb_boxc.c:1196 (in CVS).
Loïc Minier <[hidden email]>
Current Earth status: NOT DESTROYED
|Free forum by Nabble||Edit this page|