|
From: Thomas E. <Tho...@gm...> - 2003-08-30 08:01:13
|
Hi, I want to verify my KDE-3 application (kwave.sf.net) with valgrind, but as soon as the main window appears the program exits and I see a bunch of messages like these: ==18449== valgrind's libpthread.so: KLUDGED call to: sem_destroy What is going wrong, does that mean that there is a bug in my application or is there a problem with valgrind and/or glibc/libpthread? The application works fine without valgrind. my system is a SuSE-8.2 with KDE-3.1.3, Qt-3.1.2-54, glibc-2.3.2-5, gcc-3.3-23 I use valgrind-1.9.6-20030725-0 and also tried the CVS version - no difference. It also doesn't matter which skin I use, I tried memcheck, addrcheck, the cache profiler and so on, they all fail. Thomas. -- ________________________________________________________________________ Thomas Eschenbacher <Tho...@gm...> |
|
From: Nicholas N. <nj...@ca...> - 2003-08-30 15:01:01
|
On Sat, 30 Aug 2003, Thomas Eschenbacher wrote: > I want to verify my KDE-3 application (kwave.sf.net) with valgrind, but > as soon as the main window appears the program exits and I see a bunch > of messages like these: > > ==18449== valgrind's libpthread.so: KLUDGED call to: sem_destroy > > What is going wrong, does that mean that there is a bug in my > application or is there a problem with valgrind and/or glibc/libpthread? Valgrind's libpthread implementation is incomplete; for some functions it pretends to implement them but just does a cheap imitation (a "kludge" -- maybe we should not use this word as it's meaning doesn't seem to be widely known), in the hope that this is enough; often it is. Unfortunately, it seems that for your application it's not enough. If you are keen, you could try hacking coregrind/vg_libpthread.c to implement sem_destroy() and any other "kludged" functions to a sufficient level for things to work. N |
|
From: Thomas E. <Tho...@gm...> - 2003-09-01 19:48:25
|
Nicholas Nethercote wrote:
> [...]
>>==18449== valgrind's libpthread.so: KLUDGED call to: sem_destroy
>>
>>What is going wrong, does that mean that there is a bug in my
>>application or is there a problem with valgrind and/or glibc/libpthread?
>
> Valgrind's libpthread implementation is incomplete; for some functions it
> pretends to implement them but just does a cheap imitation (a "kludge" --
> maybe we should not use this word as it's meaning doesn't seem to be
> widely known), in the hope that this is enough; often it is.
> Unfortunately, it seems that for your application it's not enough. If you
> are keen, you could try hacking coregrind/vg_libpthread.c to implement
> sem_destroy() and any other "kludged" functions to a sufficient level for
> things to work.
Hi Nicholas,
thanks for your quick response. I now know what was going wrong, it was
a double-bug im my application. The first one was that I had a call to
"delete this" in the C++ part. The second one was that the concerning
object itself was on the stack and has not been created with "new". I
only wonder why memcheck did not point me directly to this...
The kludged pthread functions seem not to be a problem, things work
quite fine with them :)
Today I learned: if valgrind complains, then there really is a problem
or a bug - but it does not necessarily have to be at exactly the
position that it shows.
thanks,
Thomas
|