|
From: Stefan N. <st...@ma...> - 2003-09-15 19:20:00
|
Hi, I'm using Valgrind on a multithreaded application, and after all =
threads are created and set off, I get the following assert:
assert(mx->__m_count > 0)
It is extremely strange, because if I change some stuff in default.supp, =
I do not get it. I have added the following to default.supp:
{
Use_of_uninitialized_variables
Memcheck:Cond
obj:/lib/libc-2.2.5.so
}
{
Illegal_memory_access_of_2_bytes
Memcheck:Addr2
obj:/lib/libc-2.2.5.so
fun:_mcount
}
{
Illegal_memory_access_of_4_bytes
Memcheck:Addr4
obj:/lib/libc-2.2.5.so
fun:_mcount
}
Which takes care of a few bugs I apparently have on my system. If I =
comment out the Addr4 or the Addr2, Valgrind works, but if I have them =
both, it asserts. It may sometimes also work if I do minor changes to =
the code. It seems very irrational. I have a signal handler in my =
application, but I have commented it out without success. Im using a =
Debian system and Valgrind ver 20030725.
Any suggestions?
Regards
Stefan Nilsson, Sweden |
|
From: Nicholas N. <nj...@ca...> - 2003-09-16 07:47:43
|
On Mon, 15 Sep 2003, Stefan Nilsson wrote:
> Hi, I'm using Valgrind on a multithreaded application, and after all
> threads are created and set off, I get the following assert:
>
> assert(mx->__m_count > 0)
There are three such assertions in coregrind/vg_scheduler.c. I assume
you're failing on the third one, since it is accompanied by this comment:
(2) has been seen to fail sometimes. I don't know why.
Possibly to do with signals. */
So you're not the first to hit this. I don't know much about all that
stuff, so I can't help you, I'm afraid.
N
|
|
From: Jeremy F. <je...@go...> - 2003-09-24 14:31:15
|
On Mon, 2003-09-15 at 21:19, Stefan Nilsson wrote: > Hi, I'm using Valgrind on a multithreaded application, and after all > threads are created and set off, I get the following assert: > > assert(mx->__m_count > 0) This is pretty much a bogus assertion. "mx" is the pointer to the client's mutex structure, and Valgrind can't really assert anything about it, since it could be being merrily trashed by the client. I think it's a bit fragile for Valgrind to be relying on mutex state stored within the mutex itself. Helgrind uses shadow mutex structures for this reason. J |