|
From: Howard C. <hy...@sy...> - 2010-06-20 19:20:38
|
The BerkeleyDB library uses blocks of persistent shared memory to store its environment state, which includes arrays of interprocess shared mutexes. Running an app that uses BDB under valgrind/drd gives a ton of "The object at address 0xXXXXXXX is not a mutex." apparently because drd didn't see the mutex_init call. (And it won't see it, because the environment and those mutexes were initialized by some process other than the one being tested.) Is there a way to tell DRD that these mutexes are actually valid, and stop complaining about them? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |
|
From: Howard C. <hy...@sy...> - 2010-06-20 19:31:03
|
Howard Chu wrote: > The BerkeleyDB library uses blocks of persistent shared memory to store its > environment state, which includes arrays of interprocess shared mutexes. > Running an app that uses BDB under valgrind/drd gives a ton of "The object at > address 0xXXXXXXX is not a mutex." apparently because drd didn't see the > mutex_init call. (And it won't see it, because the environment and those > mutexes were initialized by some process other than the one being tested.) Is > there a way to tell DRD that these mutexes are actually valid, and stop > complaining about them? I changed my test so that the environment initialization occurs in the same process as the main test, but valgrind 3.4.1 still gave a bunch of "not a mutex" errors. Upgrading to 3.5.0 seems to have fixed that though, so this seems to be a solved problem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |
|
From: Bart V. A. <bva...@ac...> - 2010-06-21 17:06:54
|
On Sun, Jun 20, 2010 at 9:30 PM, Howard Chu <hy...@sy...> wrote: > Howard Chu wrote: >> The BerkeleyDB library uses blocks of persistent shared memory to store its >> environment state, which includes arrays of interprocess shared mutexes. >> Running an app that uses BDB under valgrind/drd gives a ton of "The object at >> address 0xXXXXXXX is not a mutex." apparently because drd didn't see the >> mutex_init call. (And it won't see it, because the environment and those >> mutexes were initialized by some process other than the one being tested.) Is >> there a way to tell DRD that these mutexes are actually valid, and stop >> complaining about them? > > I changed my test so that the environment initialization occurs in the same > process as the main test, but valgrind 3.4.1 still gave a bunch of "not a > mutex" errors. Upgrading to 3.5.0 seems to have fixed that though, so this > seems to be a solved problem. You need indeed Valgrind 3.5.0 for proper support of process-shared mutexes in DRD. More details about the 3.5.0 release can be found in the Valgrind release notes (http://valgrind.org/docs/manual/dist.news.html). Note: if you are using Boost, it's better to use the trunk instead of version 3.5.0. Bart. |