|
From: Jeff W. (B. R. ) <Jef...@ch...> - 2005-02-09 19:17:37
|
I am having trouble getting valgrind to work with an application which uses the Berkeley DB library. The error I am getting is: [8305] ERROR: db_env->open: Function not implemented (main.c:1788) [8305] ERROR: Abnormal exit status (from main.c:1789): 1 ==8305== ==8305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 59 from 1) ==8305== malloc/free: in use at exit: 264271 bytes in 651 blocks. ==8305== malloc/free: 722 allocs, 71 frees, 267037 bytes allocated. ==8305== For a detailed leak analysis, rerun with: --leak-check=yes ==8305== For counts of detected errors, rerun with: -v Note that the lines prefixed by the PID in brackets are generated by my application. The error is not within valgrind itself (it is being returned from a dbenv->open() call in the Berkeley DB library), but valgrind does seem to be triggering this error. The application will run normally outside of valgrind, but fails consistently at this point when run under valgrind. I will trim down my application to a bare minimum of code to reprodcuce this problem and post it here if necessary. I found this report from more than a year ago which is nearly identical to the problem I'm having: http://sourceforge.net/mailarchive/forum.php?forum_id=32038&style=flat&viewday=15&viewmonth=200311 I tried applying the patch, but the structure of the vg_malloc_replace.c file is completely different than what is described in the patch. There is no reference to __posix_memalign() to be found, and there is no line 375. Being a year old, I'm sure that this patch has made its way into the source if it was the solution to the problem described. I am currently using the valgrind package provided by my distribution (SuSE 9.2 professional, valgrind = 2.2.0-3). I have tried building from the sources on valgrind.kde.org, but the build fails at: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I../include -I./x86 -DVG_LIBDIR="\"/usr/local/valgrind/lib/valgrind"\" -DKICKSTART_BASE=0xb0000000 -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -DELFSZ=32 -MT vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" -c -ovg_syscalls.o vg_syscalls.c; \ then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f ".deps/vg_syscalls.Tpo"; exit 1; fi In file included from /usr/include/linux/msg.h:5, from vg_unsafe.h:56, from vg_syscalls.c:35: /usr/include/linux/list.h:699:2: warning: #warning "don't include kernel headers in userspace" In file included from /usr/include/linux/mii.h:12, from vg_unsafe.h:76, from vg_syscalls.c:35: /usr/include/linux/if.h:95: error: redefinition of `struct ifmap' /usr/include/linux/if.h:131: error: redefinition of `struct ifreq' /usr/include/linux/if.h:181: error: redefinition of `struct ifconf' make[4]: *** [vg_syscalls.o] Error 1 |
|
From: t. s. u. <sc...@ap...> - 2005-02-10 06:09:13
|
On Wed, 2005-02-09 at 14:17 -0500, Jeff Woods (Boca Raton ) wrote: > I am having trouble getting valgrind to work with an application which > uses the Berkeley DB library. The error I am getting is: > > [8305] ERROR: db_env->open: Function not implemented (main.c:1788) > [8305] ERROR: Abnormal exit status (from main.c:1789): 1 > ==8305== > ==8305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 59 from 1) > ==8305== malloc/free: in use at exit: 264271 bytes in 651 blocks. > ==8305== malloc/free: 722 allocs, 71 frees, 267037 bytes allocated. > ==8305== For a detailed leak analysis, rerun with: --leak-check=yes > ==8305== For counts of detected errors, rerun with: -v > > Note that the lines prefixed by the PID in brackets are generated by my > application. The error is not within valgrind itself (it is being > returned from a dbenv->open() call in the Berkeley DB library), but > valgrind does seem to be triggering this error. The application will > run normally outside of valgrind, but fails consistently at this point > when run under valgrind. I will trim down my application to a bare > minimum of code to reprodcuce this problem and post it here if necessary. I've seen the same thing, environment open hangs in valgrind, but not with all version of linux we test on. I found this post: http://groups-beta.google.com/group/comp.databases.berkeley- db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8? q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup% 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow% 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8 which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'. This worked for me, though I'm less than satisfied with this work around: I'd rather test with the production builds of the libraries. -- t. scott urban <sc...@ap...> |
|
From: Igmar P. <mai...@jd...> - 2005-02-10 14:30:43
|
> I've seen the same thing, environment open hangs in valgrind, but not > with all version of linux we test on. > > I found this post: > > http://groups-beta.google.com/group/comp.databases.berkeley- > db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8? > q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup% > 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow% > 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8 > > which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'. > This worked for me, though I'm less than satisfied with this work > around: I'd rather test with the production builds of the libraries. The error is probably due to the kernel lacking support for futexes. Usually an export LD_ASSUME_KERNEL=2.4.0 fixes this. Valgrind should support native pthreads in the CVS version, no idea if it supports futexes. Igmar |
|
From: Tom H. <to...@co...> - 2005-02-10 14:44:01
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>> I've seen the same thing, environment open hangs in valgrind, but not
>> with all version of linux we test on.
>>
>> I found this post:
>>
>> http://groups-beta.google.com/group/comp.databases.berkeley-
>> db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8?
>> q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup%
>> 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow%
>> 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8
>>
>> which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'.
>> This worked for me, though I'm less than satisfied with this work
>> around: I'd rather test with the production builds of the libraries.
>
> The error is probably due to the kernel lacking support for futexes.
> Usually an export LD_ASSUME_KERNEL=2.4.0 fixes this. Valgrind should
> support native pthreads in the CVS version, no idea if it supports
> futexes.
It supports futexes just fine. So does 2.2.0 in fact, it's just that
our libpthread didn't use them so unless you used then directly you
would never see them.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeff W. (B. R. ) <Jef...@ch...> - 2005-02-10 14:48:09
|
No luck with the LD_ASSUME_KERNEL suggestion - it produces the same error as before. I'll try rebuilding the DB library with the flags suggested below later this afternoon. Tom Hughes wrote: > In message <Pin...@jd...> > Igmar Palsenberg <mai...@jd...> wrote: > > >>>I've seen the same thing, environment open hangs in valgrind, but not >>>with all version of linux we test on. >>> >>>I found this post: >>> >>>http://groups-beta.google.com/group/comp.databases.berkeley- >>>db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8? >>>q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup% >>>3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow% >>>3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8 >>> >>>which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'. >>>This worked for me, though I'm less than satisfied with this work >>>around: I'd rather test with the production builds of the libraries. >> >>The error is probably due to the kernel lacking support for futexes. >>Usually an export LD_ASSUME_KERNEL=2.4.0 fixes this. Valgrind should >>support native pthreads in the CVS version, no idea if it supports >>futexes. > > > It supports futexes just fine. So does 2.2.0 in fact, it's just that > our libpthread didn't use them so unless you used then directly you > would never see them. > > Tom > |