You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(7) |
3
(4) |
4
(6) |
5
(6) |
6
(4) |
|
7
|
8
(6) |
9
|
10
|
11
(10) |
12
(5) |
13
(2) |
|
14
(3) |
15
(3) |
16
(14) |
17
(7) |
18
(7) |
19
(5) |
20
(4) |
|
21
(5) |
22
(5) |
23
(3) |
24
(11) |
25
(5) |
26
(9) |
27
(5) |
|
28
(2) |
29
(7) |
30
(3) |
31
(2) |
|
|
|
|
From: Doug R. <df...@nl...> - 2004-03-17 16:44:10
|
On Wed, 2004-03-17 at 16:19, Jeremy Fitzhardinge wrote: > On Wed, 2004-03-17 at 02:16, Doug Rabson wrote: > > I have a tester with a similar problem (their application is apache + a > > large number of custom C++ modules). I ended up hacking together a > > 'replacement' for vg_symtab2.c which moved the symbol table storage and > > lookups into another process. We are still testing the results but it > > looks good so far. > > Hm, interesting idea. > > I put together a much simpler patch which just adds a > --detailed-types=no CLO to ignore all the extra info in the debug > output. It will make some error messages a bit less precise, but it > should use a lot less memory in cases like these. We tried something like that (mainly just stubbing out the stab type parser) but valgrind still wanted to use a lot of memory. Increasing valgrind's available virtual space wasn't feasable either because the application needed gobs of VM for its own massive shared memory requirements. > I think the ultimate fix, at least for Linux, is to implement a proper > DWARF2 reader which takes advantage of all the incremental loading stuff > DWARF2 provides. This will minimise memory overhead while still > providing full detail. This would be good for people with modern toolchains but still doesn't help those who are stuck with ancient stabs toolchains, including all FreeBSD 4.x systems. |
|
From: Jeremy F. <je...@go...> - 2004-03-17 16:19:12
|
On Wed, 2004-03-17 at 02:16, Doug Rabson wrote: > I have a tester with a similar problem (their application is apache + a > large number of custom C++ modules). I ended up hacking together a > 'replacement' for vg_symtab2.c which moved the symbol table storage and > lookups into another process. We are still testing the results but it > looks good so far. Hm, interesting idea. I put together a much simpler patch which just adds a --detailed-types=no CLO to ignore all the extra info in the debug output. It will make some error messages a bit less precise, but it should use a lot less memory in cases like these. I think the ultimate fix, at least for Linux, is to implement a proper DWARF2 reader which takes advantage of all the incremental loading stuff DWARF2 provides. This will minimise memory overhead while still providing full detail. J |
|
From: Ian S. <ian...@st...> - 2004-03-17 12:08:05
|
Hi, We have many valgrind warnings in our test programs that I want to suppress. The one below will suffice as an example. A system call that writes a file is being passed some uninitialised bytes. The complete stack trace is 20 items long. The uniquely identifying part of this trace comes at levels 11-14, where I believe libtiff is dumping some random bytes in at the end of an image raster, in order to fix some alignment. Since the bytes are just filler in an image file, this do not represent a real error. Valgrind appears to ignore function names beyond the first 4 in a suppression. We do not want to suppress all uninitialised file writes, just ones coming though the tiff library. Is there a way to have valgrind pay attention to as many function names as are specified in a suppression? We have plenty of other examples of similar problems. Because we have coders on lots of platforms, some of whom never use valgrind directly and can't maintain such code, we can't put valgrind hooks into the source code. Ian. ==22263== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==22263== at 0x4088C324: __libc_write (in /lib/libc.so.6) ==22263== by 0x40830DF8: new_do_write (in /lib/libc.so.6) ==22263== by 0x40830D52: _IO_do_write@@GLIBC_2.1 (in /lib/libc.so.6) ==22263== by 0x4083118D: _IO_file_sync@@GLIBC_2.1 (in /lib/libc.so.6) ==22263== by 0x40827C75: _IO_fflush (in /lib/libc.so.6) ==22263== by 0x4076D160: std::__basic_file<char>::sync() (basic_file.cc:186) ==22263== by 0x407222A7: std::basic_filebuf<char, std::char_traits<char> >::_M_really_overflow(int) (/home/andrew/sw/gcc-3.2.2/objdir/i686-pc-linux-gnu/libstdc++-v3/include/bit s/fstream.tcc:350) ==22263== by 0x4072282A: std::basic_filebuf<char, std::char_traits<char> >::sync() (/home/andrew/sw/gcc-3.2.2/objdir/i686-pc-linux-gnu/libstdc++-v3/include/bit s/char_traits.h:168) ==22263== by 0x40752938: std::ostream::flush() (/home/andrew/sw/gcc-3.2.2/objdir/i686-pc-linux-gnu/libstdc++-v3/include/str eambuf:277) ==22263== by 0x4031440E: vil_stream_fstream::write(void const*, long) (/home/ian/code/src/core/vil/vil_stream_fstream.cxx:79) ==22263== by 0x402989D5: vil_tiff_writeproc(void*, void*, long) (/home/ian/code/src/core/vil/file_formats/vil_tiff.cxx:177) ==22263== by 0x40490D48: (within /usr/lib/libtiff.so.3.5.7) ==22263== by 0x404903F3: TIFFWriteEncodedStrip (in /usr/lib/libtiff.so.3.5.7) ==22263== by 0x4029AA70: vil_tiff_image::put_view(vil_image_view_base const&, unsigned, unsigned) (/home/ian/code/src/core/vil/file_formats/vil_tiff.cxx:818) ==22263== by 0x40306574: vil_save(vil_image_view_base const&, char const*, char const*) (/home/ian/code/src/core/vil/vil_save.cxx:66) ==22263== by 0x80B48D8: void vil_test_image_type<bool>(char const*, vil_image_view<bool> const&, bool, bool) (/home/ian/code/src/core/vil/tests/test_save_load_image.cxx:264) ==22263== by 0x80B3EDC: test_save_load_image() (/home/ian/code/src/core/vil/tests/test_save_load_image.cxx:500) ==22263== by 0x80B4056: test_save_load_image_main(int, char**) (/home/ian/code/src/core/vil/tests/test_save_load_image.cxx:554) ==22263== by 0x4042AFB9: testlib_main(int, char**) (/home/ian/code/src/core/testlib/testlib_main.cxx:116) ==22263== by 0x80708BE: main (/home/ian/code/src/core/vil/tests/test_driver.cxx:51) ==22263== Address 0x4044801F is not stack'd, malloc'd or free'd |
|
From: Doug R. <df...@nl...> - 2004-03-17 10:17:21
|
On Tuesday 16 March 2004 23:21, Jeremy Fitzhardinge wrote: > On Tue, 2004-03-16 at 15:15, John Roberts wrote: > > I upped that limit as you said and got the same failure. > > > > So then I upped VALGRIND_HEAPSIZE to 512M, same failure. > > > > Since I was there, I thought I'd see what else I could raise... :) > > > > I also tried upping VALGRIND_MAPSIZE to 512M, same failure. > > That shouldn't matter; that just limits the size of a particular > shared library (Valgrind maps in a shared library to read its symbol > table, but then unmaps it, so there's only ever one at a time > mapped). > > > I also tried upping CLIENT_SIZE_MULTIPLE to 128M, same failure. > > This just means that the client address space is made to be a > multiple of this, mostly to keep things pretty. > > > By the same failure, I mean the same source code lines in > > Valgrind failing in the reported stack traces. > > > > You got me interested in estimating the number of symbols > > in my code. I did nm over the shared libraries it uses > > (my server is composed of 43 shared libraries, plus itself). > > > > This yielded 264,645 symbols (didn't try to uniq them :). > > Just foe interest's sake, and to confirm the theory, can you strip > the libraries and try again? If it still happens, then we need to > look elsewhere. I have a tester with a similar problem (their application is apache + a large number of custom C++ modules). I ended up hacking together a 'replacement' for vg_symtab2.c which moved the symbol table storage and lookups into another process. We are still testing the results but it looks good so far. |
|
From: John R. <joh...@cr...> - 2004-03-16 23:39:39
|
>Just foe interest's sake, and to confirm the theory, can you strip the >libraries and try again? If it still happens, then we need to look >elsewhere. Well, if I run the optimized (non "-g" version) that is a monolithic executable 38M in size (and nm reports 101997) symbols, then memcheck does look like its working! So you're onto something here. It might be of interest that the unmodified vg_main.c distro also works on my non-debug, optimized server. I've appended the "good" trace, in case its of interest. thanks, John Roberts Credence Systems Corporation 133 mexia(2.4.21-4.0.1.EL):jroberts:server> /export/jroberts/tmp/bin/valgrind --tool=memcheck -v .vserver ==29951== Memcheck, a memory error detector for x86-linux. ==29951== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==29951== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==29951== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==29951== Valgrind library directory: /export/jroberts/tmp/lib/valgrind ==29951== Command line ==29951== .vserver ==29951== Startup, with flags: ==29951== --tool=memcheck ==29951== -v ==29951== Reading syms from /export/jroberts/c/ServerApps/src/server/.vserver (0x8048000) ==29951== Reading syms from /lib/ld-2.3.2.so (0x30000000) ==29951== object doesn't have any debug info ==29951== Reading syms from /lib/ld-2.3.2.so (0xB0000000) ==29951== object doesn't have any debug info ==29951== Reading syms from /export/jroberts/tmp/lib/valgrind/vgskin_memcheck.so (0xB728D000) ==29951== Reading syms from /lib/tls/libc-2.3.2.so (0xB74B5000) ==29951== object doesn't have any debug info ==29951== Reading syms from /lib/libdl-2.3.2.so (0xB75ED000) ==29951== object doesn't have any debug info ==29951== Reading syms from /export/jroberts/tmp/lib/valgrind/stage2 (0xB8000000) ==29951== Reading suppressions file: /export/jroberts/tmp/lib/valgrind/default.supp ==29951== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==29951== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==29951== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==29951== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==29951== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==29951== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==29951== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==29951== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==29951== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==29951== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==29951== ==29951== Reading syms from /export/jroberts/tmp/lib/valgrind/vg_inject.so (0x30019000) ==29951== Reading syms from /export/jroberts/tmp/lib/valgrind/vgpreload_memcheck.so (0x3001C000) ==29951== TRANSLATE: 0x30011E90 redirected to 0x3001DA00 ==29951== Reading syms from /export/jroberts/tmp/lib/valgrind/libpthread.so (0x30022000) ==29951== Reading syms from /lib/libdl-2.3.2.so (0x30064000) ==29951== object doesn't have any debug info ==29951== Reading syms from /lib/libnsl-2.3.2.so (0x30068000) ==29951== object doesn't have any debug info ==29951== Reading syms from /lib/tls/libm-2.3.2.so (0x3007E000) ==29951== object doesn't have any debug info ==29951== Reading syms from /lib/tls/libc-2.3.2.so (0x300A3000) ==29951== object doesn't have any debug info ==29951== TRANSLATE: 0x3011C6F0 redirected to 0x3001DFFC ==29951== TRANSLATE: 0x3011ADB0 redirected to 0x3001DBC0 ==29951== warning: Valgrind's pthread_attr_destroy does nothing ==29951== your program may misbehave as a result ==29951== warning: Valgrind's pthread_attr_destroy does nothing ==29951== your program may misbehave as a result ==29951== warning: Valgrind's pthread_attr_destroy does nothing ==29951== your program may misbehave as a result Inst file: /ims/cobalt/release/linux/cfg/inst_1_0_Build_17.cfg Config file: /ims/cobalt/release/linux/cfg/config_1_0_Build_17.cfg Project file: /ims/cobalt/release/linux/cfg/project_1_0_Build_17.cfg Defaults file: /ims/cobalt/release/linux/cfg/defaults_1_0_Build_17.cfg Protocol file: /ims/cobalt/release/linux/cfg/protocol_1_0_Build_17.cfg Timing: 1 Data: 33 Pmu: 1 Power: 11 ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C87E2: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C5D79: ImsSetupCollection_Server::ImsSetupCollection_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x884AF11: ImsTestStation_Server::ImsTestStation_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C8827: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C5D79: ImsSetupCollection_Server::ImsSetupCollection_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x884AF11: ImsTestStation_Server::ImsTestStation_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x94C5E53: SsiServerState::setServerStateFlags(unsigned long, bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x94C2CB4: SsiInterface::setServerStateFlags(unsigned long, bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x8854ABF: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C8827: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x8854A88: ImsTestStation_Server::setChanged() (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91E2479: ImsSetupCollection_Server::moveCurrent(ImsSetupTypeEnum, _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91186AF: ImsFixture_Server::makeCurrent() (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== Reading syms from /ims/cobalt/release/linux/subp/Lite/1_0_Build_17/src/libLiteS.so (0x31526000) Emulator Server: Version Cobalt 1.0 Build 17, "mexia:jroberts" ...Booted... [then I typed control-C to terminate my server:] Caught signal 2, SIGINT (interrupt) ==29951== ==29951== ERROR SUMMARY: 13 errors from 4 contexts (suppressed: 21 from 1) ==29951== ==29951== 1 errors in context 1 of 4: ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x8854A88: ImsTestStation_Server::setChanged() (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91E2479: ImsSetupCollection_Server::moveCurrent(ImsSetupTypeEnum, _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> > const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91186AF: ImsFixture_Server::makeCurrent() (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== 4 errors in context 2 of 4: ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x94C5E53: SsiServerState::setServerStateFlags(unsigned long, bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x94C2CB4: SsiInterface::setServerStateFlags(unsigned long, bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x8854ABF: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C8827: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== 4 errors in context 3 of 4: ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C8827: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C5D79: ImsSetupCollection_Server::ImsSetupCollection_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x884AF11: ImsTestStation_Server::ImsTestStation_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== ==29951== 4 errors in context 4 of 4: ==29951== Conditional jump or move depends on uninitialised value(s) ==29951== at 0x8854AA5: ImsTestStation_Server::setSaveNeeded(bool) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C87E2: ImsSetupCollection_Server::createItem(ImsSaveableCollectionSelector const&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x91C5D79: ImsSetupCollection_Server::ImsSetupCollection_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) ==29951== by 0x884AF11: ImsTestStation_Server::ImsTestStation_Server(ImsServerDatabase*, Vtr&) (in /export/jroberts/c/ServerApps/src/server/.vserver) --29951-- --29951-- supp: 21 Ugly strchr error in /lib/ld-2.3.2.so ==29951== ==29951== IN SUMMARY: 13 errors from 4 contexts (suppressed: 21 from 1) ==29951== ==29951== malloc/free: in use at exit: 8916908 bytes in 3594 blocks. ==29951== malloc/free: 2722823 allocs, 2719229 frees, 115162604 bytes allocated. ==29951== --29951-- TT/TC: 0 tc sectors discarded. --29951-- 43139 chainings, 2 unchainings. --29951-- translate: new 91274 (3674776 -> 31269553; ratio 85:10) --29951-- discard 1 (23 -> 320; ratio 139:10). --29951-- dispatch: 429500000 jumps (bb entries), of which 91749180 (21%) were unchained. --29951-- 12177/17977640 major/minor sched events. 156039 tt_fast misses. --29951-- reg-alloc: 16679 t-req-spill, 5304475+122891 orig+spill uis, 434637 total-reg-r. --29951-- sanity: 11694 cheap, 468 expensive checks. --29951-- ccalls: 693889 C calls, 50% saves+restores avoided (2048494 bytes) --29951-- 1146214 args, avg 0.78 setup instrs each (481646 bytes) --29951-- 0% clear the stack (2080986 bytes) --29951-- 147690 retvals, 38% of reg-reg movs avoided (110892 bytes) |
|
From: Jeremy F. <je...@go...> - 2004-03-16 23:22:52
|
On Tue, 2004-03-16 at 15:15, John Roberts wrote: > I upped that limit as you said and got the same failure. > > So then I upped VALGRIND_HEAPSIZE to 512M, same failure. > > Since I was there, I thought I'd see what else I could raise... :) > > I also tried upping VALGRIND_MAPSIZE to 512M, same failure. That shouldn't matter; that just limits the size of a particular shared library (Valgrind maps in a shared library to read its symbol table, but then unmaps it, so there's only ever one at a time mapped). > I also tried upping CLIENT_SIZE_MULTIPLE to 128M, same failure. This just means that the client address space is made to be a multiple of this, mostly to keep things pretty. > By the same failure, I mean the same source code lines in > Valgrind failing in the reported stack traces. > > You got me interested in estimating the number of symbols > in my code. I did nm over the shared libraries it uses > (my server is composed of 43 shared libraries, plus itself). > > This yielded 264,645 symbols (didn't try to uniq them :). Just foe interest's sake, and to confirm the theory, can you strip the libraries and try again? If it still happens, then we need to look elsewhere. J |
|
From: John R. <joh...@cr...> - 2004-03-16 23:15:50
|
Yes, its a _big_ server comprised of about 1.5 million lines C++ compiled with debug on. :) I upped that limit as you said and got the same failure. So then I upped VALGRIND_HEAPSIZE to 512M, same failure. Since I was there, I thought I'd see what else I could raise... :) I also tried upping VALGRIND_MAPSIZE to 512M, same failure. I also tried upping CLIENT_SIZE_MULTIPLE to 128M, same failure. By the same failure, I mean the same source code lines in Valgrind failing in the reported stack traces. You got me interested in estimating the number of symbols in my code. I did nm over the shared libraries it uses (my server is composed of 43 shared libraries, plus itself). This yielded 264,645 symbols (didn't try to uniq them :). John Roberts Credence Systems Corporation >Subject: Re: [Valgrind-users] memcheck in 2.1.1 gives INTERNAL ERROR >From: Jeremy Fitzhardinge <je...@go...> >To: John Roberts <joh...@cr...> >Cc: Valgrind users <val...@li...> >Mime-Version: 1.0 >Date: Tue, 16 Mar 2004 14:24:53 -0800 >Content-Transfer-Encoding: 7bit >X-BigFish: pcvs-47(z60di17eK60eHz98dIQ1432W1805M122eHzzzzz) > >On Tue, 2004-03-16 at 13:06, John Roberts wrote: >> Memcheck in Valgrind 2.1.1 doesn't work on my >> program, while the 2.1.0 distro did. >> >> I'm running the 2.4.21 kernel on Redhat Enterprise >> Linux 3. I made two "tweaks" to valgrind that might >> of affected this. :) >> I upped two values in coregrind/vg_include.h: >> >> #define M_PROCMAP_BUF 500000 >> (was 50000) >> >> #define VG_N_SEMAPHORES 250 >> (was 50) >> >> I upped those values because I ran into these limits >> in some earlier version of Valgrind. >> >> The gory details are appended... > >Hm, looks like its running out of heap. Is that a large number of .so >files of C++ code compiled with -g? > >Try increasing the heap size by changing VALGRIND_HEAPSIZE in vg_main.c >- try 256M or something. > > J > |
|
From: Jeremy F. <je...@go...> - 2004-03-16 22:26:31
|
On Tue, 2004-03-16 at 13:06, John Roberts wrote: > Memcheck in Valgrind 2.1.1 doesn't work on my > program, while the 2.1.0 distro did. > > I'm running the 2.4.21 kernel on Redhat Enterprise > Linux 3. I made two "tweaks" to valgrind that might > of affected this. :) > I upped two values in coregrind/vg_include.h: > > #define M_PROCMAP_BUF 500000 > (was 50000) > > #define VG_N_SEMAPHORES 250 > (was 50) > > I upped those values because I ran into these limits > in some earlier version of Valgrind. > > The gory details are appended... Hm, looks like its running out of heap. Is that a large number of .so files of C++ code compiled with -g? Try increasing the heap size by changing VALGRIND_HEAPSIZE in vg_main.c - try 256M or something. J |
|
From: Jeremy F. <je...@go...> - 2004-03-16 22:24:26
|
On Tue, 2004-03-16 at 11:15, Tom Hughes wrote: > I would have though it was fairly clear. Athlon 64 is not currently > support by valgrind - only 32 bit x86 platforms are supported. Well, it should be possible to build and run 32-bit Valgrind on an x86-64 machine. I don't think it does currently, but it shouldn't take too much to get it working. J |
|
From: John R. <joh...@cr...> - 2004-03-16 21:55:09
|
I tried this on the standard distro, without
my mods to coregrind/vg_include.h and I
still get the same error.
John Roberts
Credence Systems Corporation
------------- Begin Forwarded Message -------------
Date: Tue, 16 Mar 2004 13:06:34 -0800 (PST)
From: "John Roberts" <joh...@cr...>
Subject: memcheck in 2.1.1 gives INTERNAL ERROR
To: val...@li...
Cc: joh...@cr...
MIME-Version: 1.0
Content-MD5: N8LG+CB6I3QOlLCa6icrEA==
Memcheck in Valgrind 2.1.1 doesn't work on my
program, while the 2.1.0 distro did.
I'm running the 2.4.21 kernel on Redhat Enterprise
Linux 3. I made two "tweaks" to valgrind that might
of affected this. :)
I upped two values in coregrind/vg_include.h:
#define M_PROCMAP_BUF 500000
(was 50000)
#define VG_N_SEMAPHORES 250
(was 50)
I upped those values because I ran into these limits
in some earlier version of Valgrind.
The gory details are appended...
John Roberts
Credence Systems Corporation
95 mexia(2.4.21-4.0.1.EL):jroberts:server>
/export/jroberts/valgrind/latest/bin/valgrind --tool=memcheck -v .vserver_g
==4641== Memcheck, a memory error detector for x86-linux.
==4641== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==4641== Using valgrind-2.1.1, a program supervision framework for x86-linux.
==4641== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==4641== Valgrind library directory:
/export/jroberts/valgrind/latest/lib/valgrind
==4641== Command line
==4641== .vserver_g
==4641== Startup, with flags:
==4641== --tool=memcheck
==4641== -v
==4641== Reading syms from /export/jroberts/c/ServerApps/src/server/.vserver_g
(0x8048000)
==4641== Reading syms from /lib/ld-2.3.2.so (0x3C000000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/ld-2.3.2.so (0xB0000000)
==4641== object doesn't have any debug info
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vgskin_memcheck.so (0xB728D000)
==4641== Reading syms from /lib/tls/libc-2.3.2.so (0xB74B5000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/libdl-2.3.2.so (0xB75ED000)
==4641== object doesn't have any debug info
==4641== Reading syms from /export/jroberts/valgrind/latest/lib/valgrind/stage2
(0xB8000000)
==4641== Reading suppressions file:
/export/jroberts/valgrind/latest/lib/valgrind/default.supp
==4641== REDIRECT soname:libc.so.6(__GI___errno_location) to
soname:libpthread.so.0(__errno_location)
==4641== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==4641== REDIRECT soname:libc.so.6(__GI___h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==4641== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==4641== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==4641== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==4641== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
==4641== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen)
==4641== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==4641== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==4641==
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vg_inject.so (0x3C019000)
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vgpreload_memcheck.so (0x3C01C000)
==4641== TRANSLATE: 0x3C011E90 redirected to 0x3C01DA00
==4641== Reading syms from
/ims/cobalt/release/linux/subp/TestStation/1_0_Build_17/src/libTestStationS_g.so
(0x3C022000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/levels/libLevelsS_g.so
(0x3C2A7000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/parameter/libParametersS_g.so
(0x3C582000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/command/libCommandS_g.so
(0x3C76D000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Pattern/1_0_Build_17/src/libPatternS_g.so
(0x3C841000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/timing/libTimingS_g.so
(0x3D58B000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Sync/1_0_Build_17/src/libSyncS_g.so (0x3D9EE000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/continuity/libContinu
ityTestS_g.so (0x3DC76000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/functional/vanguard/l
ibFunctionalTestS_g.so (0x3DE52000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/pmu/libPmuTestS_g.so
(0x3DF26000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/search/libSearchTestS
_g.so (0x3E240000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/waves/vanguard/libWav
esTestS_g.so (0x3E384000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/deviceTest/libDeviceT
estS_g.so (0x3E469000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Packet/1_0_Build_17/src/libPacketS_g.so
(0x3E5E1000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/device/libDeviceS_g.so
(0x3E62B000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/setup/libCollections
SetupS_g.so (0x3EA1A000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/layout/libCollection
sLayoutS_g.so (0x3EB54000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/result/libCollection
sResultS_g.so (0x3EC13000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/foundation/libCollec
tionsFoundationS_g.so (0x3EC98000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Protocol/1_0_Build_17/src/libProtocolS_g.so
(0x3EDFD000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Vtr/1_0_Build_17/src/libVtr_g.so (0x3EE87000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/foundati
on/libTrDiagFoundationS_g.so (0x3F06C000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/timingMo
dule/libTrDiagTimingModule_g.so (0x3F0D4000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/dataModu
le/libTrDiagDataModule_g.so (0x3F136000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/cobaltMo
dules/libTrDiagCobaltModules_g.so (0x3F17D000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/calibration/vanguard/libTrCal
ibration_g.so (0x3F1B8000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/testControl/vanguard/libTrTes
tControl_g.so (0x3F268000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/setup/vanguard/libTrSetup_g.s
o (0x3F2F9000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/foundation/vanguard/libTrFoun
dation_g.so (0x3F35F000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/hardware/libTrHardware_g.so
(0x3F396000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/adsp21kElf/libTrAdsp21kElf_g.
so (0x3F698000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/notify/vanguard/libVa
nguardNotifyS_g.so (0x3F6E0000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/foundation/libFoundat
ionS_g.so (0x3F716000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/event/libEvent_g.so
(0x3F7B1000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/enumeration/libEnumS_
g.so (0x3F89E000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/support/vanguard/libS
upport_g.so (0x3F944000)
==4641== Reading syms from
/ims/core/release/linux/subp/Core/X3_07A/lib/libCoreS_g.so (0x3F98A000)
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/libpthread.so (0x40238000)
==4641== Reading syms from /lib/libdl-2.3.2.so (0x4027A000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/libnsl-2.3.2.so (0x4027E000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/tls/libm-2.3.2.so (0x40296000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/tls/libc-2.3.2.so (0x402B9000)
==4641== object doesn't have any debug info
--4641-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--4641-- si_code=1 Fault EIP: 0xB8025D66; Faulting address: 0xBFF25004
valgrind: the `impossible' happened:
Killed by fatal signal
Basic block ctr is approximately 43050000
==4641== at 0xB802A070: vgPlain_core_panic (vg_mylibc.c:1230)
==4641== by 0xB802A06F: panic (vg_mylibc.c:1226)
==4641== by 0xB802A084: vgPlain_core_panic (vg_mylibc.c:1231)
==4641== by 0xB802F936: vg_sync_signalhandler (vg_signals.c:1756)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
valgrind: ../../valgrind-2.1.1/coregrind/vg_mylibc.c:1681
(vgPlain_get_memory_from_mmap): Assertion `p >= (void
*)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end' failed.
==4641== at 0xB802A001: vgPlain_skin_assert_fail (vg_mylibc.c:1211)
==4641== by 0xB802A000: assert_fail (vg_mylibc.c:1207)
==4641== by 0xB802A03E: vgPlain_core_assert_fail (vg_mylibc.c:1218)
==4641== by 0xB802A8CC: vgPlain_get_memory_from_mmap (vg_mylibc.c:1681)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
96 mexia(2.4.21-4.0.1.EL):jroberts:server> uname -a
Linux mexia 2.4.21-4.0.1.EL #1 Thu Oct 23 01:36:33 EDT 2003 i686 i686 i386
GNU/Linux
97 mexia(2.4.21-4.0.1.EL):jroberts:server> cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon)
------------- End Forwarded Message -------------
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-16 21:14:56
|
On Tue, 16 Mar 2004, John Roberts wrote: > >That's strange... and the fact that it worked when you added an empty > >Makefile is even stranger... is 'build/' the name of Valgrind's top-level > >directory, from which the install is being done? > > My directory structure has the "build" directory at the same > level as "valgrind-2.1.1", which contains the valgrind sources. > > In "build" I did a "../valgrind-2.1.1/configure --prefix=/export/jroberts/tmp" > > Then, while still in the "build" directory, I typed make. > > Since the error said it was looking for a Makefile in the source > tree, I cd-ed into the source tree (valgrind-2.1.1/coregrind) > and added the empty Makefile to satisfy the depend requirements. > > The build restarted and completed then, when I did "make". Right... we don't normally use separate build/ directories. Interesting that this was required to get it to work... N |
|
From: John R. <joh...@cr...> - 2004-03-16 21:06:51
|
Memcheck in Valgrind 2.1.1 doesn't work on my
program, while the 2.1.0 distro did.
I'm running the 2.4.21 kernel on Redhat Enterprise
Linux 3. I made two "tweaks" to valgrind that might
of affected this. :)
I upped two values in coregrind/vg_include.h:
#define M_PROCMAP_BUF 500000
(was 50000)
#define VG_N_SEMAPHORES 250
(was 50)
I upped those values because I ran into these limits
in some earlier version of Valgrind.
The gory details are appended...
John Roberts
Credence Systems Corporation
95 mexia(2.4.21-4.0.1.EL):jroberts:server>
/export/jroberts/valgrind/latest/bin/valgrind --tool=memcheck -v .vserver_g
==4641== Memcheck, a memory error detector for x86-linux.
==4641== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==4641== Using valgrind-2.1.1, a program supervision framework for x86-linux.
==4641== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==4641== Valgrind library directory:
/export/jroberts/valgrind/latest/lib/valgrind
==4641== Command line
==4641== .vserver_g
==4641== Startup, with flags:
==4641== --tool=memcheck
==4641== -v
==4641== Reading syms from /export/jroberts/c/ServerApps/src/server/.vserver_g
(0x8048000)
==4641== Reading syms from /lib/ld-2.3.2.so (0x3C000000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/ld-2.3.2.so (0xB0000000)
==4641== object doesn't have any debug info
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vgskin_memcheck.so (0xB728D000)
==4641== Reading syms from /lib/tls/libc-2.3.2.so (0xB74B5000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/libdl-2.3.2.so (0xB75ED000)
==4641== object doesn't have any debug info
==4641== Reading syms from /export/jroberts/valgrind/latest/lib/valgrind/stage2
(0xB8000000)
==4641== Reading suppressions file:
/export/jroberts/valgrind/latest/lib/valgrind/default.supp
==4641== REDIRECT soname:libc.so.6(__GI___errno_location) to
soname:libpthread.so.0(__errno_location)
==4641== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==4641== REDIRECT soname:libc.so.6(__GI___h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==4641== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==4641== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==4641== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==4641== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
==4641== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen)
==4641== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==4641== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==4641==
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vg_inject.so (0x3C019000)
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/vgpreload_memcheck.so (0x3C01C000)
==4641== TRANSLATE: 0x3C011E90 redirected to 0x3C01DA00
==4641== Reading syms from
/ims/cobalt/release/linux/subp/TestStation/1_0_Build_17/src/libTestStationS_g.so
(0x3C022000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/levels/libLevelsS_g.so
(0x3C2A7000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/parameter/libParametersS_g.so
(0x3C582000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/command/libCommandS_g.so
(0x3C76D000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Pattern/1_0_Build_17/src/libPatternS_g.so
(0x3C841000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/timing/libTimingS_g.so
(0x3D58B000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Sync/1_0_Build_17/src/libSyncS_g.so (0x3D9EE000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/continuity/libContinu
ityTestS_g.so (0x3DC76000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/functional/vanguard/l
ibFunctionalTestS_g.so (0x3DE52000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/pmu/libPmuTestS_g.so
(0x3DF26000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/search/libSearchTestS
_g.so (0x3E240000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/waves/vanguard/libWav
esTestS_g.so (0x3E384000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/DeviceTest/1_0_Build_17/src/deviceTest/libDeviceT
estS_g.so (0x3E469000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Packet/1_0_Build_17/src/libPacketS_g.so
(0x3E5E1000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Ar/1_0_Build_17/src/device/libDeviceS_g.so
(0x3E62B000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/setup/libCollections
SetupS_g.so (0x3EA1A000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/layout/libCollection
sLayoutS_g.so (0x3EB54000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/result/libCollection
sResultS_g.so (0x3EC13000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Collections/1_0_Build_17/src/foundation/libCollec
tionsFoundationS_g.so (0x3EC98000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Protocol/1_0_Build_17/src/libProtocolS_g.so
(0x3EDFD000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Vtr/1_0_Build_17/src/libVtr_g.so (0x3EE87000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/foundati
on/libTrDiagFoundationS_g.so (0x3F06C000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/timingMo
dule/libTrDiagTimingModule_g.so (0x3F0D4000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/dataModu
le/libTrDiagDataModule_g.so (0x3F136000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/diagnostics/vanguard/cobaltMo
dules/libTrDiagCobaltModules_g.so (0x3F17D000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/calibration/vanguard/libTrCal
ibration_g.so (0x3F1B8000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/testControl/vanguard/libTrTes
tControl_g.so (0x3F268000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/setup/vanguard/libTrSetup_g.s
o (0x3F2F9000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/foundation/vanguard/libTrFoun
dation_g.so (0x3F35F000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/hardware/libTrHardware_g.so
(0x3F396000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Tr/1_0_Build_17/src/adsp21kElf/libTrAdsp21kElf_g.
so (0x3F698000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/notify/vanguard/libVa
nguardNotifyS_g.so (0x3F6E0000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/foundation/libFoundat
ionS_g.so (0x3F716000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/event/libEvent_g.so
(0x3F7B1000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/enumeration/libEnumS_
g.so (0x3F89E000)
==4641== Reading syms from
/ims/cobalt/release/linux/subp/Foundation/1_0_Build_17/src/support/vanguard/libS
upport_g.so (0x3F944000)
==4641== Reading syms from
/ims/core/release/linux/subp/Core/X3_07A/lib/libCoreS_g.so (0x3F98A000)
==4641== Reading syms from
/export/jroberts/valgrind/latest/lib/valgrind/libpthread.so (0x40238000)
==4641== Reading syms from /lib/libdl-2.3.2.so (0x4027A000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/libnsl-2.3.2.so (0x4027E000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/tls/libm-2.3.2.so (0x40296000)
==4641== object doesn't have any debug info
==4641== Reading syms from /lib/tls/libc-2.3.2.so (0x402B9000)
==4641== object doesn't have any debug info
--4641-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--4641-- si_code=1 Fault EIP: 0xB8025D66; Faulting address: 0xBFF25004
valgrind: the `impossible' happened:
Killed by fatal signal
Basic block ctr is approximately 43050000
==4641== at 0xB802A070: vgPlain_core_panic (vg_mylibc.c:1230)
==4641== by 0xB802A06F: panic (vg_mylibc.c:1226)
==4641== by 0xB802A084: vgPlain_core_panic (vg_mylibc.c:1231)
==4641== by 0xB802F936: vg_sync_signalhandler (vg_signals.c:1756)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
valgrind: ../../valgrind-2.1.1/coregrind/vg_mylibc.c:1681
(vgPlain_get_memory_from_mmap): Assertion `p >= (void
*)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end' failed.
==4641== at 0xB802A001: vgPlain_skin_assert_fail (vg_mylibc.c:1211)
==4641== by 0xB802A000: assert_fail (vg_mylibc.c:1207)
==4641== by 0xB802A03E: vgPlain_core_assert_fail (vg_mylibc.c:1218)
==4641== by 0xB802A8CC: vgPlain_get_memory_from_mmap (vg_mylibc.c:1681)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
96 mexia(2.4.21-4.0.1.EL):jroberts:server> uname -a
Linux mexia 2.4.21-4.0.1.EL #1 Thu Oct 23 01:36:33 EDT 2003 i686 i686 i386
GNU/Linux
97 mexia(2.4.21-4.0.1.EL):jroberts:server> cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon)
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-16 20:28:46
|
On Tue, 16 Mar 2004, John Roberts wrote: > (1) First, I encountered a build problem when I tried to build Valgrind. > After I did my "configure --prefix=path", then tried make, I got the > following error: > > make[2]: Entering directory `/export/jroberts/valgrind/build/coregrind' > make[2]: *** No rule to make target > `../../valgrind-2.1.1/coregrind/Makefile', needed by `vg_toolint.c'. Stop. > > So I went to valgrind-2.1.1/coregrind and made an empty file called > "Makefile". > > Then I returned to the build directory and the make succeeded. That's strange... and the fact that it worked when you added an empty Makefile is even stranger... is 'build/' the name of Valgrind's top-level directory, from which the install is being done? > (2) I tried Massif and its very cool! I have one question/comment. I > don't understand the concept of "spacetime". > [...] > So the percentages are very unintuitive to me. I think they would be > better reflecting just plain space utilization. > > What is the motive behind "spacetime"? Spacetime = space x time :) ie. the area under the graph. I used spacetime because that's what existing space profilers for Haskell that I based Massif on used; in particular that's what hp2ps, the graph-drawing program, uses. And I find it a more general measurement than, say, peak memory use. > (3) Massif gave a cryptic label/title > to my postscript chart: > > 3,240,776,-39,-221 bytes xms > > Did this overflow some value? > I don't understand this either. > My printout shows about a 10 meg peak > and the max X-axis time is 350000.0 ms. Yes, it's an overflow in hp2ps, code I grabbed wholesale from somewhere else, and I don't know how it works. I'll have a look; in the meantime you can ignore the value in the title (but you can trust the one that Massif prints out in its summary). > I think you're too timid versioning this at 0.0.3. It should be more > like 0.3.0, unless you don't want to reach 1.0.0 in your lifetime. :) Oh, that version number's irrelevant now that Massif is in the main distro. I'll change it. Thanks for the feedback. N |
|
From: Tom H. <th...@cy...> - 2004-03-16 19:15:25
|
In message <405...@bm...>
Shibu Nair <shi...@bm...> wrote:
> I am unable to build valgrind 2.0.0 on a Opterob x86_64 platfomr running
> Suse 8.1. the error I get when I run configure
>
> checking host system type... x86_64-suse-linux
> checking for a supported CPU... no (x86_64)
> configure: error: Valgrind is ix86 specific. Sorry
>
> Any help to resolve this will be appreciated.
I would have though it was fairly clear. Athlon 64 is not currently
support by valgrind - only 32 bit x86 platforms are supported.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2004-03-16 19:11:13
|
> Any help to resolve this will be appreciated. Valgrind hasn't yet been ported to Opteron, or any 64-bit system, for that matter. This is a non-trivial change, so it may be a while in coming. The good news is that other people do care so it will get done. Regards, Robert. |
|
From: Shibu N. <shi...@bm...> - 2004-03-16 19:02:12
|
I am unable to build valgrind 2.0.0 on a Opterob x86_64 platfomr running Suse 8.1. the error I get when I run configure checking host system type... x86_64-suse-linux checking for a supported CPU... no (x86_64) configure: error: Valgrind is ix86 specific. Sorry Any help to resolve this will be appreciated. Thanks Shibu |
|
From: John R. <joh...@cr...> - 2004-03-16 18:56:34
|
I also noticed in Massif that the addresses in
the postscript chart are incremented by one
compared to the addresses referenced in the
text file output, so for example in the
massif.7760.txt file I have:
0x80C01FD: __STL::__node_alloc<true, 0>::etc.
but in the postscript printout I get:
x80C01FE:__STL::__node_al
and as I mentioned before, the shell prompt output
for my application was:
Total spacetime: 815,383,091,245 ms.B
but the postscript chart title was:
3,240,776,-39,-221 bytes x ms
Minor nitpicks... :)
John Roberts
Staff Software Engineer
5975 N.W. Pinefarm Place
Credence Systems Corporation
Hillsboro, Oregon 97124
email: joh...@cr...
tel: (503) 466-8056
|
|
From: John R. <joh...@cr...> - 2004-03-16 18:38:49
|
Hi all,
I just downloaded and tried Valgrind 2.1.1
on my Redhat Enterprise Linux 3 system
using gcc 3.2.3.
(1) First, I encountered a build problem when
I tried to build Valgrind. After I did
my "configure --prefix=path", then tried
make, I got the following error:
make[2]: Entering directory `/export/jroberts/valgrind/build/coregrind'
make[2]: *** No rule to make target
`../../valgrind-2.1.1/coregrind/Makefile', needed by `vg_toolint.c'. Stop.
So I went to valgrind-2.1.1/coregrind
and made an empty file called "Makefile".
Then I returned to the build directory
and the make succeeded.
(2) I tried Massif and its very cool!
I have one question/comment. I don't
understand the concept of "spacetime".
When I ran Massif, it made a very cool
postscript chart. The top band for
method1 (most memory used) peaked out
at about a 4 megabyte thickness.
The third band, lets call this method3,
looks to be about a 2 meg thickness.
When I look at the textfile output
though, method3 is listed at 16.7%
and method1 at 15.7%.
So the percentages are very unintuitive
to me. I think they would be better
reflecting just plain space utilization.
What is the motive behind "spacetime"?
(3) Massif gave a cryptic label/title
to my postscript chart:
3,240,776,-39,-221 bytes xms
Did this overflow some value?
I don't understand this either.
My printout shows about a 10 meg peak
and the max X-axis time is 350000.0 ms.
Anyway it looks _very_ cool and is
potentially extremely useful!
I think you're too timid versioning this
at 0.0.3. It should be more like 0.3.0,
unless you don't want to reach 1.0.0
in your lifetime. :)
John Roberts
Staff Software Engineer
5975 N.W. Pinefarm Place
Credence Systems Corporation
Hillsboro, Oregon 97124
email: joh...@cr...
tel: (503) 466-8056
|
|
From: Josef W. <Jos...@gm...> - 2004-03-15 19:39:01
|
On Monday 15 March 2004 15:07, Nicholas Nethercote wrote:
> On Sun, 14 Mar 2004, Josef Weidendorfer wrote:
> > I think that for coverage, you *need* also the number of distinct
> > instruction never touched. Currenty, Cachegrind does not do this.
>
> Oh, yeah. And that's hard to find, since it never instruments code it
> never sees Maybe it could be done somehow in the post-annotation script.
I made a small skin for this some time ago, which translates all basic blocks
with debug info into UCode using VG_(disBB), and writes out a cachegrind.out
file for instructions found. Unfortunately, I had to do
=========================================
...
/* functions from valgrind core not found in vg_skin.h ;-( */
extern UCodeBlock* VG_(alloc_UCodeBlock) ( void );
extern Int VG_(disBB) ( UCodeBlock* cb, Addr eip0 );
/* Expandable arrays of uinstrs. */
struct _UCodeBlock {
Addr orig_eip;
Int used;
Int size;
UInstr* instrs;
Int nextTemp;
};
...
cb = VG_(alloc_UCodeBlock)();
cb->orig_eip = addr;
size = VG_(disBB)(cb, addr);
...
============================================
Opinions on putting
VG_(alloc_UCodeBlock)(Addr orig_eip)
VG_(disBB) ( UCodeBlock*, Addr)
into vg_skin.h ?
Josef
>
> N
|
|
From: smiley g. <smi...@ya...> - 2004-03-15 16:14:38
|
Hello David,
Thanks for your note. I did go through the
documentation but missed it. thanks for your concern
and patience again David.
What I am really trying to do is to valgrind a daemon
process - actually a host of daemon processes.
I downloaded a sample daemon code and tried valgrind
on it. Have provided it below.
Its evident that you chdir('/'), and usually there is
no write permission there. when i comment it off it
does the same.
i referred other places and saw that we close stdout
and stderr of the daemon process. Its not so with the
code.
How to go about in this case ?
Thanks,
Madhan.
--- David Eriksson <tw...@us...>
wrote:
> On Fri, 2004-02-27 at 08:49, smiley glitter wrote:
> > Hello,
> >
> > Is valgrind compatible with a fork'd program. I
> have
> > an application (foo) that forks/execs another
> > program(bar).
> >
> > What is required is to only valgrind the fork'd
> > application (bar). Is it possible.
> >
> > I tried valgrind foo, but bar is not valgrinded.
> >
> > How can I check my fork'd application with
> valgrind.
> > is it possible. any pointers ?
> >
> > Thanks,
> > Smile.
>
> --trace-children=yes
>
>
> --
> Regards,
> -\- David Eriksson -/-
>
> SynCE - http://synce.sourceforge.net
> CalcEm - http://calcem.sourceforge.net
> ScummVM - http://scummvm.sourceforge.net
> Desquirr - http://desquirr.sourceforge.net
> SetiWrapper - http://setiwrapper.sourceforge.net
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2004-03-15 14:08:07
|
On Sun, 14 Mar 2004, Josef Weidendorfer wrote: > I think that for coverage, you *need* also the number of distinct instruction > never touched. Currenty, Cachegrind does not do this. Oh, yeah. And that's hard to find, since it never instruments code it never sees Maybe it could be done somehow in the post-annotation script. N |
|
From: Josef W. <Jos...@gm...> - 2004-03-14 20:59:54
|
Am Sunday 14 March 2004 12:14 schrieb Nicholas Nethercote: > Main problem with using Cachegrind for coverage is that it's massive > overkill -- it will run much slowler than necessary because of all the In calltree, I did some optimization for this case. Use --simulate-cache=no, and it will skip instrumentation for every instruction, and thus quite fast. > cache simulation stuff. 2nd problem is that you can't aggregate counts > over multiple runs of a program. Enough people have asked about coverage KCachegrind does this if you load multiple dumps together. It should be no problem to provide a PERL script to do this for 2 cachegrind files. > that I wonder if it's worth doing properly with a separate tool? Jeremy's > VGProf is a good start, but requiring a patched gprof is not nice So if we want to do a seperate tool for this, I vote for the ASCII cachegrind format. I think that for coverage, you *need* also the number of distinct instruction never touched. Currenty, Cachegrind does not do this. Josef > . > > N |
|
From: Nicholas N. <nj...@ca...> - 2004-03-14 11:14:19
|
On Sun, 14 Mar 2004, Josef Weidendorfer wrote: > > > The skin is pretty stupid, it just records hits on instructions when it > > > sees the INCEIP instruction. It also tries to do some conditional jump > > > analysis. I've written a python script that will annotate source and > > > show you what lines have been executed. > > Stupid question: Can't you use Cachegrind for this? Yes, I think the --show=Ir option will give you it. > > You might want to have a look at vgprof. I wrote it with the intention > > of making Valgrind interoperate with gprof by generating gprof-format > > files. Unfortunately, the gprof format is horrible and inextensible, so > > the only way it can work is by hacking gprof itself, which isn't fun. > > So better use Cachegrind format? You will get source annotation for free > (using cg_annotate or KCachegrind). > I found the Cachegrind file format to be astonishing flexible to use for > different purposes (in contrast to my own extensions .-). And it is quite > space saving because of ASCII (!), too: No need to store 8 bytes for a 64 bit > counter in a binary format, as most of the counters are small numbers. Main problem with using Cachegrind for coverage is that it's massive overkill -- it will run much slowler than necessary because of all the cache simulation stuff. 2nd problem is that you can't aggregate counts over multiple runs of a program. Enough people have asked about coverage that I wonder if it's worth doing properly with a separate tool? Jeremy's VGProf is a good start, but requiring a patched gprof is not nice. N |
|
From: Josef W. <Jos...@gm...> - 2004-03-14 00:15:03
|
Am Thursday 11 March 2004 22:52 schrieb Jeremy Fitzhardinge: > On Thu, 2004-03-11 at 11:43, Chris AtLee wrote: > > Hi all, > > > > I started working on a code coverage skin for valgrind...Mostly as a > > learning project to see how valgrind works. A patch against current CVS > > can be found at: > > http://atlee.ca/coverage.patch.gz > > > > The skin is pretty stupid, it just records hits on instructions when it > > sees the INCEIP instruction. It also tries to do some conditional jump > > analysis. I've written a python script that will annotate source and > > show you what lines have been executed. Stupid question: Can't you use Cachegrind for this? > You might want to have a look at vgprof. I wrote it with the intention > of making Valgrind interoperate with gprof by generating gprof-format > files. Unfortunately, the gprof format is horrible and inextensible, so > the only way it can work is by hacking gprof itself, which isn't fun. So better use Cachegrind format? You will get source annotation for free (using cg_annotate or KCachegrind). I found the Cachegrind file format to be astonishing flexible to use for different purposes (in contrast to my own extensions .-). And it is quite space saving because of ASCII (!), too: No need to store 8 bytes for a 64 bit counter in a binary format, as most of the counters are small numbers. Josef > > Anyway, you might get some ideas from it: > http://www.goop.org/~jeremy/valgrind/12-vgprof.patch > http://www.goop.org/~jeremy/valgrind/vgprof.html > > J > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Igmar P. <mai...@jd...> - 2004-03-13 10:38:24
|
> > Couldn't find previous reference to "/usr/include/sys/types.h"/61667 for > > fileidx 1 > > Sounds like the stabs reader; which version of gcc/toolchain are you > using? What distro? binutils : 2.14 gcc : 2.95.4 pre Distro is a heavely modified RH 7.3. > > and a few dozen more. > > > > Second : > > > > [igmar@ouzo fwtk]$ set | grep VAL > > VALGRIND_OPTS=--tool=memcheck > > [igmar@ouzo fwtk]$ valgrind --track-children=no ./xx > > Segmentation fault (core dumped) > > > > It's not the program. When i unset the environment variable, all goes > > fine. The segfault occurs with every option in that case. > > Hm. Which glibc/kernel are you using? Kernel : 2.4.23 with the mremap stuff fixed glibc : 2.2.5-44 (the standard RH 7.3 update) > J Igmar |