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
(1) |
2
(5) |
3
|
|
4
(1) |
5
(8) |
6
(16) |
7
(5) |
8
(1) |
9
(3) |
10
|
|
11
|
12
(10) |
13
(5) |
14
(14) |
15
(6) |
16
(4) |
17
(2) |
|
18
(2) |
19
(13) |
20
(1) |
21
(5) |
22
(2) |
23
(1) |
24
|
|
25
|
26
(5) |
27
(10) |
28
(8) |
29
(7) |
30
(2) |
31
|
|
From: Igmar P. <mai...@jd...> - 2004-07-14 14:42:16
|
> I know all that. The point is that under valgrind it will always > be choosing the valgrind libpthread.so and not either of the system > ones! > > What LD_ASSUME_KERNEL normally does is to make it choose between either > /lib/libpthread.so or /lib/i686/libpthread.so or /lib/tls/libpthread.so > depending on the ABI version. But under valgrind it will always be > using /usr/lib/valgrind/libpthread.so which does not have multiple > versions for the different ABIs. Ugh.. I should have thought about this. Ah well, that rules out the NTPL differences :) Igmar |
|
From: Paul L D. <pld...@pl...> - 2004-07-14 13:24:08
|
Is anyone still running a database of applications shows as "valgrind clean" ? Regards. -- Paul L Daniels - PLD Software - Xamime Unix systems Internet Development A.B.N. 19 500 721 806 ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73 PGP Public Key at http://www.pldaniels.com/gpg-keys.pld |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 12:39:25
|
On Tue, 13 Jul 2004, Nicholas Nethercote wrote: >> Results in the error: >> >> ==27651== Mismatched free() / delete / delete [] >> ==27651== at 0x3C01E87B: free (vg_replace_malloc.c:127) >> ==27651== by 0x3C0C78D0: operator delete(void*, std::nothrow_t >> const&) (del_opnt.cc:39) > > Looks like a Valgrind bug. It's not catching replacing delete(nothrow) with > its own version. > > To fix this requires knowing what the mangled name of delete(nothrow) is, but > I don't know how to work this out... the one for new(nothrow) is > _ZnwjRKSt9nothrow_t... maybe someone else can enlighten me. Can you try the attached patch against the current Valgrind CVS HEAD? (See valgrind.kde.org/cvs.html for how to obtain/build the CVS HEAD.) If the patch works, I will commit it. Thanks for your help. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 10:47:34
|
On Tue, 13 Jul 2004, Howard Chu wrote: >> I get this output, and a message to submit this data.. I have no idea >> what it means, but here it is.. > > It means you ran out of memory. valgrind 2.1.1 appears to be quite a memory > pig compared to previous versions. > >> How do I work around this? > > Installing more RAM in your computer might help. I recall reading on the > -developer list that there's a patch to decrease some of valgrind's demand > for RAM. Hopefully it will be publically released soon. I don't think installing more RAM would help. The issue isn't physical memory, rather address space. 2.1.1 does do not so well here; the current CVS version has some improvements in this respect, and I'm looking at improving things further. The CVS version also no longer asserts when malloc() fails, rather it just returns NULL as standard. If you really need to do big mallocs like this and Memcheck is failing, you could try Addrcheck as it uses less memory. N |
|
From: Howard C. <hy...@sy...> - 2004-07-14 03:13:48
|
Joshua Moore-Oliva wrote: > I get this output, and a message to submit this data.. I have no idea what it means, but here it is.. It means you ran out of memory. valgrind 2.1.1 appears to be quite a memory pig compared to previous versions. > How do I work around this? Installing more RAM in your computer might help. I recall reading on the -developer list that there's a patch to decrease some of valgrind's demand for RAM. Hopefully it will be publically released soon. > Thanks, Josh. > > Valgrind version: 2.1.1 > Operating system: Gentoo > > ==24017== Warning: set address range perms: large range 134217728, a 0, v 1 > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. > ==24017== at 0xB802FA70: vgPlain_skin_assert_fail (vg_mylibc.c:1211) > ==24017== by 0xB802FA6F: assert_fail (vg_mylibc.c:1207) > ==24017== by 0xB802FADD: vgPlain_core_assert_fail (vg_mylibc.c:1218) > ==24017== by 0xB802BBEF: vgPlain_arena_malloc (vg_malloc2.c:535) > ==24017== by 0xB802C741: vgPlain_cli_malloc (vg_malloc2.c:1393) > ==24017== by 0xB02474E7: vgSkin_malloc (mac_malloc_wrappers.c:181) > ==24017== by 0xB8012097: do_client_request (vg_scheduler.c:2886) > ==24017== by 0xB800E3E0: vgPlain_scheduler (vg_scheduler.c:1065) > ==24017== by 0xB802A2E3: main (vg_main.c:2994) > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==24017== at 0x3C01C40D: malloc (vg_replace_malloc.c:105) > ==24017== by 0x3C01CC88: realloc (vg_replace_malloc.c:154) > ==24017== by 0x804949F: FreeTdsxx_convertBufferResize (FreeTdsxx_convertBufferResize.c:6) > ==24017== by 0x80492E6: FreeTdsxx_colValFromIdx (FreeTdsxx_colValFromIdx.c:23) > ==24017== by 0x804AB2A: main (main.c:48) -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-07-14 03:10:49
|
I was allocating a stupidly large buffer, that is the cause of the error... although, as a suggestion it could be a little more specific in the error. Josh. On July 13, 2004 10:48 pm, Joshua Moore-Oliva wrote: > I get this output, and a message to submit this data.. I have no idea what it means, but here it is.. > > How do I work around this? > > Thanks, Josh. > > Valgrind version: 2.1.1 > Operating system: Gentoo > > ==24017== Warning: set address range perms: large range 134217728, a 0, v 1 > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. > ==24017== at 0xB802FA70: vgPlain_skin_assert_fail (vg_mylibc.c:1211) > ==24017== by 0xB802FA6F: assert_fail (vg_mylibc.c:1207) > ==24017== by 0xB802FADD: vgPlain_core_assert_fail (vg_mylibc.c:1218) > ==24017== by 0xB802BBEF: vgPlain_arena_malloc (vg_malloc2.c:535) > ==24017== by 0xB802C741: vgPlain_cli_malloc (vg_malloc2.c:1393) > ==24017== by 0xB02474E7: vgSkin_malloc (mac_malloc_wrappers.c:181) > ==24017== by 0xB8012097: do_client_request (vg_scheduler.c:2886) > ==24017== by 0xB800E3E0: vgPlain_scheduler (vg_scheduler.c:1065) > ==24017== by 0xB802A2E3: main (vg_main.c:2994) > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==24017== at 0x3C01C40D: malloc (vg_replace_malloc.c:105) > ==24017== by 0x3C01CC88: realloc (vg_replace_malloc.c:154) > ==24017== by 0x804949F: FreeTdsxx_convertBufferResize (FreeTdsxx_convertBufferResize.c:6) > ==24017== by 0x80492E6: FreeTdsxx_colValFromIdx (FreeTdsxx_colValFromIdx.c:23) > ==24017== by 0x804AB2A: main (main.c:48) > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-07-14 02:48:57
|
I get this output, and a message to submit this data.. I have no idea what it means, but here it is.. How do I work around this? Thanks, Josh. Valgrind version: 2.1.1 Operating system: Gentoo ==24017== Warning: set address range perms: large range 134217728, a 0, v 1 valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. ==24017== at 0xB802FA70: vgPlain_skin_assert_fail (vg_mylibc.c:1211) ==24017== by 0xB802FA6F: assert_fail (vg_mylibc.c:1207) ==24017== by 0xB802FADD: vgPlain_core_assert_fail (vg_mylibc.c:1218) ==24017== by 0xB802BBEF: vgPlain_arena_malloc (vg_malloc2.c:535) ==24017== by 0xB802C741: vgPlain_cli_malloc (vg_malloc2.c:1393) ==24017== by 0xB02474E7: vgSkin_malloc (mac_malloc_wrappers.c:181) ==24017== by 0xB8012097: do_client_request (vg_scheduler.c:2886) ==24017== by 0xB800E3E0: vgPlain_scheduler (vg_scheduler.c:1065) ==24017== by 0xB802A2E3: main (vg_main.c:2994) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==24017== at 0x3C01C40D: malloc (vg_replace_malloc.c:105) ==24017== by 0x3C01CC88: realloc (vg_replace_malloc.c:154) ==24017== by 0x804949F: FreeTdsxx_convertBufferResize (FreeTdsxx_convertBufferResize.c:6) ==24017== by 0x80492E6: FreeTdsxx_colValFromIdx (FreeTdsxx_colValFromIdx.c:23) ==24017== by 0x804AB2A: main (main.c:48) |
|
From: senganal <set...@ci...> - 2004-07-13 17:05:03
|
hi Thanks for the replies . I tried 'setenv LD_ASSUME_KERNEL 2.4.18' but it didn't work. Valgrind still doesen't wait at the ACE_Manual_Event.wait (). ACE is doing something funny with the mutexes but couldnt figure out what .Internally ACE uses pthread_cond_wait() in these events, and pthread_cond_wait works fine with valgrind. I am kind of stuck with the testing and will be grateful for any help. Regards Senganal |
|
From: Hoai T. <ho...@ya...> - 2004-07-13 15:28:17
|
Hi Tom, Nice to help me :) But, I just put the print command for debug. In my real code, there is a computing function there instead of cout. The similar result occurs warning an uninitialised data :( Any further hint ? Thank alot, Cheers, Hoai --- Tom Hughes <th...@cy...> wrote: > In message > <200...@we...> > Hoai Tran <ho...@ya...> wrote: > > > I'm a new guy in Valgrind. It's quite useful to > me. However, there is a > > case that I cannot explain. I have a segment of > code as following: > > > > double best; > > .... > > best = -1.0e20; > > cout << "BEst = " << best << endl; > > > > And Valgrind prints messages: > > > > ==12945== Syscall param write(buf) contains > uninitialised or unaddressable byte(s) > > ==12945== at 0x3C3F43E4: write (in > /lib/libc-2.2.5.so) > > ==12945== by 0x3C39B7C7: _IO_file_write (in > /lib/libc-2.2.5.so) > > ==12945== by 0x3C2E5E37: > sys_write__7filebufPCci (in > /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) > > ==12945== by 0x3C39AE87: (within > /lib/libc-2.2.5.so) > > ==12945== by 0x3C39B92B: _IO_file_xsputn (in > /lib/libc-2.2.5.so) > > ==12945== by 0x3C2E5EAF: xsputn__7filebufPCci > (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) > > ==12945== by 0x3C2E9871: (within > /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) > > ==12945== by 0x3C2E9998: __ls__7ostreami (in > /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) > > ==12945== by 0x80E64D2: > newOpenSubCount__13ABA_PARMASTER > (parmaster_opensubcount.cc:178) > > > > Please help me to work around the error. Or tell > me what exactly I must > > follow in order to use Valgrind correctly. Thank > alot. > > You are writing uninitialised data to cout at some > point. Note that > if cout is buffered then the actual problem write > may have occurred > some time before because valgrind will only report > the problem when > the write system call occurs as the buffer is > flushed, which may be > sometime later. > > Making the stream unbuffered can help make this sort > of problem easier > to track down. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & > Training. > Attend Black Hat Briefings & Training, Las Vegas > July 24-29 - > digital self defense, top technical experts, no > vendor pitches, > unmatched networking opportunities. Visit > www.blackhat.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Tom H. <th...@cy...> - 2004-07-13 13:43:47
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> Looks like a Valgrind bug. It's not catching replacing
> delete(nothrow) with its own version.
>
> To fix this requires knowing what the mangled name of delete(nothrow)
> is, but I don't know how to work this out... the one for new(nothrow)
> is _ZnwjRKSt9nothrow_t... maybe someone else can enlighten me.
A bit of playing with nm and c++filt on libstdc++.so suggests this:
_ZdaPvRKSt9nothrow_t operator delete[](void*, std::nothrow_t const&)
_ZdlPvRKSt9nothrow_t operator delete(void*, std::nothrow_t const&)
_ZnwjRKSt9nothrow_t operator new(unsigned, std::nothrow_t const&)
_ZnajRKSt9nothrow_t operator new[](unsigned, std::nothrow_t const&)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-13 13:29:56
|
On Mon, 12 Jul 2004 fa...@ca... wrote:
> Is this a known error in valgrind or the gnu STL, or (more likely) am I
> doing something stupid?
>
> A simple test program:
>
> #include <vector>
> #include <algorithm>
> #include <functional>
> #include <iostream>
>
> int main(int argc, char* argv[])
> {
> std::vector<int> data;
> for (int i=0;i<100;i++) data.push_back(i%7);
> stable_sort( data.begin(), data.end() );
> std::cout << data[50] << std::endl;
> }
>
>
> Results in the error:
>
> ==27651== Mismatched free() / delete / delete []
> ==27651== at 0x3C01E87B: free (vg_replace_malloc.c:127)
> ==27651== by 0x3C0C78D0: operator delete(void*, std::nothrow_t
> const&) (del_opnt.cc:39)
Looks like a Valgrind bug. It's not catching replacing delete(nothrow)
with its own version.
To fix this requires knowing what the mangled name of delete(nothrow) is,
but I don't know how to work this out... the one for new(nothrow) is
_ZnwjRKSt9nothrow_t... maybe someone else can enlighten me.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-13 07:47:48
|
On Mon, 12 Jul 2004, tarun kapoor wrote: > ==17527== discard syms in /usr/lib/libz.so.1.1.4 due to munmap() > > What is the reason for this? and what does this > message means? It just means the debugging information for a file is being unloaded, because its code has been unloaded. It's not important. > Also, is there any way to suppress them? I am trying > to run valgrind with a -q option, still no help. It shouldn't appear with -q; that's a bug in 2.0.0, it's fixed in later versions. If you want to stick with 2.0.0, just find the message in coregrind/vg_symtab2.c, comment it out, and recompile (assuming you have a source distribution). N |
|
From: tarun k. <tar...@ya...> - 2004-07-12 23:12:12
|
Hi, I am using valgrind 2.0.0. I keep on getting messages like ==17527== discard syms in /usr/lib/libmyodbc-2.50.39.so due to munmap() ==17527== discard syms in /usr/lib/mysql/libmysqlclient.so.10.0.0 due to munmap() ==17527== discard syms in /usr/lib/libz.so.1.1.4 due to munmap() ==17527== discard syms in /usr/lib/libmyodbc-2.50.39.so due to munmap() ==17527== discard syms in /usr/lib/mysql/libmysqlclient.so.10.0.0 due to munmap() ==17527== discard syms in /usr/lib/libz.so.1.1.4 due to munmap() What is the reason for this? and what does this message means? Also, is there any way to suppress them? I am trying to run valgrind with a -q option, still no help. Thanks!! Tarun __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
|
From: <fa...@ca...> - 2004-07-12 21:52:27
|
I'm running across a mismatched new/delete error in stable_sort() from
the STL. I'm using valgrind 2.1.1, gcc 3.4.1 on RHEL 3.0 (glibc 2.3.2).
Is this a known error in valgrind or the gnu STL, or (more likely) am I
doing something stupid?
Thanks for the great program!
- Matt
A simple test program:
#include <vector>
#include <algorithm>=20
#include <functional>
#include <iostream>
int main(int argc, char* argv[])=20
{
std::vector<int> data;
for (int i=3D0;i<100;i++) data.push_back(i%7);
stable_sort( data.begin(), data.end() );
std::cout << data[50] << std::endl;
}
Results in the error:
=3D=3D27651=3D=3D Mismatched free() / delete / delete []
=3D=3D27651=3D=3D at 0x3C01E87B: free (vg_replace_malloc.c:127)
=3D=3D27651=3D=3D by 0x3C0C78D0: operator delete(void*, std::nothrow_t
const&) (del_opnt.cc:39)
=3D=3D27651=3D=3D by 0x8049758: void std::return_temporary_buffer<int>(i=
nt*)
(memory:122)
=3D=3D27651=3D=3D by 0x80492E2:
std::_Temporary_buffer<__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, int>::~_Temporary_buffer()
(stl_tempbuf.h:129)
=3D=3D27651=3D=3D Address 0x3C2705A0 is 0 bytes inside a block of size 400=
alloc'd
=3D=3D27651=3D=3D at 0x3C01E5B6: operator new(unsigned, std::nothrow_t
const&) (vg_replace_malloc.c:110)
=3D=3D27651=3D=3D by 0x8049F37: std::pair<int*, int>
std::__get_temporary_buffer<int>(int, int*) (memory:81)
=3D=3D27651=3D=3D by 0x804972C: std::pair<int*, int>
std::get_temporary_buffer<int>(int) (memory:110)
=3D=3D27651=3D=3D by 0x804921B:
std::_Temporary_buffer<__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >,
int>::_Temporary_buffer(__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >,
__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int>
> >) (stl_tempbuf.h:153)
|
|
From: Tom H. <th...@cy...> - 2004-07-12 19:54:16
|
In message <200...@we...>
Hoai Tran <ho...@ya...> wrote:
> I'm a new guy in Valgrind. It's quite useful to me. However, there is a
> case that I cannot explain. I have a segment of code as following:
>
> double best;
> ....
> best = -1.0e20;
> cout << "BEst = " << best << endl;
>
> And Valgrind prints messages:
>
> ==12945== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
> ==12945== at 0x3C3F43E4: write (in /lib/libc-2.2.5.so)
> ==12945== by 0x3C39B7C7: _IO_file_write (in /lib/libc-2.2.5.so)
> ==12945== by 0x3C2E5E37: sys_write__7filebufPCci (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==12945== by 0x3C39AE87: (within /lib/libc-2.2.5.so)
> ==12945== by 0x3C39B92B: _IO_file_xsputn (in /lib/libc-2.2.5.so)
> ==12945== by 0x3C2E5EAF: xsputn__7filebufPCci (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==12945== by 0x3C2E9871: (within /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==12945== by 0x3C2E9998: __ls__7ostreami (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so)
> ==12945== by 0x80E64D2: newOpenSubCount__13ABA_PARMASTER (parmaster_opensubcount.cc:178)
>
> Please help me to work around the error. Or tell me what exactly I must
> follow in order to use Valgrind correctly. Thank alot.
You are writing uninitialised data to cout at some point. Note that
if cout is buffered then the actual problem write may have occurred
some time before because valgrind will only report the problem when
the write system call occurs as the buffer is flushed, which may be
sometime later.
Making the stream unbuffered can help make this sort of problem easier
to track down.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Hoai T. <ho...@ya...> - 2004-07-12 18:46:25
|
Dear all, I'm a new guy in Valgrind. It's quite useful to me. However, there is a case that I cannot explain. I have a segment of code as following: double best; .... best = -1.0e20; cout << "BEst = " << best << endl; And Valgrind prints messages: ==12945== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==12945== at 0x3C3F43E4: write (in /lib/libc-2.2.5.so) ==12945== by 0x3C39B7C7: _IO_file_write (in /lib/libc-2.2.5.so) ==12945== by 0x3C2E5E37: sys_write__7filebufPCci (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==12945== by 0x3C39AE87: (within /lib/libc-2.2.5.so) ==12945== by 0x3C39B92B: _IO_file_xsputn (in /lib/libc-2.2.5.so) ==12945== by 0x3C2E5EAF: xsputn__7filebufPCci (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==12945== by 0x3C2E9871: (within /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==12945== by 0x3C2E9998: __ls__7ostreami (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==12945== by 0x80E64D2: newOpenSubCount__13ABA_PARMASTER (parmaster_opensubcount.cc:178) Please help me to work around the error. Or tell me what exactly I must follow in order to use Valgrind correctly. Thank alot. Regards, Hoai __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail |
|
From: Grant S. <gs...@di...> - 2004-07-12 18:02:09
|
This is telling you, in at line 118 in api_Registry, new[] is being called. It is detecting a leak, because a delete[] is never being called for that memory. Check where that pointer is going out of scope. Where it does, be sure the appropriate delete is called. -grant -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Maretick Scott-SMARETI1 Sent: Monday, July 12, 2004 11:13 AM To: 'val...@li...' Subject: [Valgrind-users] output usage question =3D=3D10932=3D=3D 404 bytes in 1 blocks are definitely lost in loss = record 7 of 9 =3D=3D10932=3D=3D at 0x40029886: __builtin_vec_new = (vg_replace_malloc.c:203) =3D=3D10932=3D=3D by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) =3D=3D10932=3D=3D by 0x4074A9F0: = api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) =3D=3D10932=3D=3D by 0x4074E1DF: api_Registry::api_Registry(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:116) =3D=3D10932=3D=3D=20 =3D=3D10932=3D=3D=20 =3D=3D10932=3D=3D 200084 bytes in 1 blocks are possibly lost in loss = record 9 of 9 =3D=3D10932=3D=3D at 0x40029886: __builtin_vec_new = (vg_replace_malloc.c:203) =3D=3D10932=3D=3D by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) =3D=3D10932=3D=3D by 0x4074A9F0: = api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) =3D=3D10932=3D=3D by 0x4074DE40: api_Registry::api_Registry(unsigned = short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:82) =3D=3D10932=3D=3D=20 |
|
From: Nicholas N. <nj...@ca...> - 2004-07-12 17:32:18
|
On Mon, 12 Jul 2004, Maretick Scott-SMARETI1 wrote: > So when I see this output, how can I determine where the leaks are at in > the code? You have to work that out for yourself... Valgrind can only tell you where the leaked blocks were allocated. N |
|
From: Tom H. <th...@cy...> - 2004-07-12 17:29:31
|
In message <7FD...@az...>
Maretick Scott-SMARETI1 <SMA...@mo...> wrote:
> So when I see this output, how can I determine where the leaks are at in
> the code?
By reading the stack trace for the leak to see where the leaked
memory was allocated and then examining your code to see why it
isn't being freed again.
> Obviously, there's a problem in
> /vob/mm2/plat/src/libMMUnsorted/api_HashTable.c on line 118?
That's what it says, yes.
> What about in the "LEAK SUMMARY"
What about it? It's a sumary of the total amount of memory leaked.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-12 17:15:23
|
In message <200...@al...>
"John Roberts" <joh...@cr...> wrote:
> I don't know if this is affecting ACE, but you can
> test that hypothesis by doing:
>
> setenv LD_ASSUME_KERNEL 2.4.18
>
> prior to invoking Valgrind. That will induce the
> older kernel behavior that won't interrupt
> semaphores when threads are created.
That probably won't have any effect with valgrind as valgrind
always uses the same libpthread.so no matter what you set that
variable to.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Maretick Scott-S. <SMA...@mo...> - 2004-07-12 17:13:43
|
So when I see this output, how can I determine where the leaks are at in the code? Obviously, there's a problem in /vob/mm2/plat/src/libMMUnsorted/api_HashTable.c on line 118? What about in the "LEAK SUMMARY" -----------------------start output----------------------------------------- ==10932== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==10932== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==10932== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==10932== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==10932== ==10932== My PID = 10932, parent PID = 10877. Prog and args are: ==10932== mm_cp ==10932== ==10932== Command line: ==10932== mm_cp ==10932== Startup, with flags: ==10932== --suppressions=/apps/public/valgrind_2.0.0/lib/valgrind/default.supp ==10932== --logfile=/project/mm2dev/smareti1/valgrind_output/mm_cp.out ==10932== --leak-check=yes ==10932== -v ==10932== Reading syms from /project/mm2dev/smareti1/executables/mm_cp ==10932== Reading syms from /lib/ld-2.3.2.so ==10932== object doesn't have any debug info ==10932== Reading syms from /apps/public/valgrind_2.0.0/lib/valgrind/vgskin_memcheck.so ==10932== Reading syms from /apps/public/valgrind_2.0.0/lib/valgrind/valgrind.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libpal.so ==10932== Reading syms from /usr/lib/libbz2.so.1.0.2 ==10932== object doesn't have a symbol table ==10932== object doesn't have any debug info ==10932== Reading syms from /project/mm2dev/smareti1/executables/libpalsa.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libhapLinuxOnly.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libCMICommon.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libFwMsg.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libftb.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libpalPCDClassNames.so ==10932== Reading syms from /lib/libdl-2.3.2.so ==10932== object doesn't have any debug info ==10932== Reading syms from /lib/librt-2.3.2.so ==10932== object doesn't have any debug info ==10932== Reading syms from /project/mm2dev/smareti1/executables/libdatabaseProxy.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libpcdupdate.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libpcml.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libnemiCommon.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libnemi.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libplatformServices.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgobas.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgosrk.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgodb.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgodms.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgodpc.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libgoamsClient.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libComponentManager.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMAppServices.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMCdfIO.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMCompat.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMFSUtil.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMLogUtil.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMMutexMgr.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMPcb.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMSharedMem.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMTimers.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMUnsorted.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMGEM.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMTagTables.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMList.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMMsgConsumer.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMSCAP.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMPacketComm.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMDbCommonUtils.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMFDN.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMDataCache.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMDataStorage.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMPmPeg.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMCpGlobal.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMCP.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMScAm.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMFmIntrf.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMClCp.so ==10932== Reading syms from /project/mm2dev/smareti1/executables/libMMSS7.so ==10932== Reading syms from /usr/lib/libstdc++.so.5.0.3 ==10932== object doesn't have a symbol table ==10932== object doesn't have any debug info ==10932== Reading syms from /lib/libm-2.3.2.so ==10932== object doesn't have any debug info ==10932== Reading syms from /lib/libgcc_s-3.2.2-20030225.so.1 ==10932== object doesn't have a symbol table ==10932== object doesn't have any debug info ==10932== Reading syms from /lib/libc-2.3.2.so ==10932== object doesn't have any debug info ==10932== Reading syms from /apps/public/valgrind_2.0.0/lib/valgrind/libpthread.so ==10932== Reading suppressions file: /apps/public/valgrind_2.0.0/lib/valgrind/default.supp ==10932== Estimated CPU clock rate is 2788 MHz ==10932== REPLACING libc(__GI___errno_location) with libpthread(__errno_location) ==10932== REPLACING libc(__GI___h_errno_location) with libpthread(__h_errno_location) ==10932== REPLACING libc(__GI___res_state) with libpthread(__res_state) ==10932== ==10932== TRANSLATE: 0x40FBBBC0 redirected to 0x410E6DC8 ==10932== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==10932== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==10932== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==10932== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==10932== TRANSLATE: 0x41099D90 redirected to 0x410E6EAC ==10932== ==10932== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==10932== malloc/free: in use at exit: 213688 bytes in 21 blocks. ==10932== malloc/free: 38 allocs, 17 frees, 218027 bytes allocated. ==10932== ==10932== searching for pointers to 21 not-freed blocks. ==10932== checked 18645436 bytes. ==10932== ==10932== 404 bytes in 1 blocks are definitely lost in loss record 7 of 9 ==10932== at 0x40029886: __builtin_vec_new (vg_replace_malloc.c:203) ==10932== by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) ==10932== by 0x4074A9F0: api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) ==10932== by 0x4074E1DF: api_Registry::api_Registry(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:116) ==10932== ==10932== ==10932== 200084 bytes in 1 blocks are possibly lost in loss record 9 of 9 ==10932== at 0x40029886: __builtin_vec_new (vg_replace_malloc.c:203) ==10932== by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) ==10932== by 0x4074A9F0: api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) ==10932== by 0x4074DE40: api_Registry::api_Registry(unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:82) ==10932== ==10932== LEAK SUMMARY: ==10932== definitely lost: 404 bytes in 1 blocks. ==10932== possibly lost: 200084 bytes in 1 blocks. ==10932== still reachable: 13000 bytes in 18 blocks. ==10932== suppressed: 200 bytes in 1 blocks. ==10932== Reachable blocks (those to which a pointer was found) are not shown. ==10932== To see them, rerun with: --show-reachable=yes ==10932== --10932-- TT/TC: 0 tc sectors discarded. --10932-- 11108 chainings, 0 unchainings. --10932-- translate: new 26325 (347848 -> 4400729; ratio 126:10) --10932-- discard 0 (0 -> 0; ratio 0:10). --10932-- dispatch: 1000000 jumps (bb entries), of which 138554 (13%) were unchained. --10932-- 22/33393 major/minor sched events. 30269 tt_fast misses. --10932-- reg-alloc: 1143 t-req-spill, 811040+6393 orig+spill uis, 110117 total-reg-r. --10932-- sanity: 23 cheap, 1 expensive checks. --10932-- ccalls: 99454 C calls, 65% saves+restores avoided (382550 bytes) --10932-- 133946 args, avg 0.90 setup instrs each (25726 bytes) --10932-- 0% clear the stack (298362 bytes) --10932-- 27814 retvals, 33% of reg-reg movs avoided (17850 bytes) -----------------------end output------------------------------------------- |
|
From: John R. <joh...@cr...> - 2004-07-12 16:34:12
|
I don't know if this affects Valgrind, but I know
it does affect gdb.
In the newer Linux kernel, when gdb is notified
that a new thread has been created it calls the
ptrace() operating system call with PTRACE_CONT
which cancels pending POSIX semaphore operations.
So any pending sem_wait() calls are sent an EINTR
and return -1. I had to recode our multi-threaded
application to check the return value of sem_wait()
and restart if errno=EINTR.
I don't know if this is affecting ACE, but you can
test that hypothesis by doing:
setenv LD_ASSUME_KERNEL 2.4.18
prior to invoking Valgrind. That will induce the
older kernel behavior that won't interrupt
semaphores when threads are created.
Just an idea,
John Roberts
Software Engineer
Credence Systems Corporation
Hillsboro, Oregon, USA
joh...@cr...
|
|
From: tarun k. <tar...@ya...> - 2004-07-09 14:45:35
|
Steve, I am getting the same error too. I agree to you on that Valgrind 2.1.1 has bugs. If i run valgrind 2.1.1 with a --logfile=filename parameter, valgrnid segfaults. That's why i movoed back to the 2.0.0 version, but i still get the syscall error. Tarun Message: 2 From: Steven Dake <sd...@mv...> Reply-To: sd...@mv... To: val...@li... Organization: MontaVista Software, Inc. Date: Wed, 07 Jul 2004 14:06:56 -0700 Subject: [Valgrind-users] strangeness in valgrind 2.1.1 Folks I am using valgrind 2.1.1 to run the openais project (developer.osdl.org/dev/openais) through its paces. Its an excellent tool and I have already found a few errors. I am trying to sanitize all of the remaining errors and get an error that is: ==2834== Syscall param socketcall.recvmsg(msg.msg_iov[i] contains uninitialised or unaddressable byte(s) ==2834== at 0x3C111A16: sendmsg (socket.S:63) ==2834== by 0x8053371: message_handler_orf_token (gmi.c:2240) ==2834== by 0x8054779: recv_handler (gmi.c:3012) ==2834== by 0x8050876: poll_run (poll.c:458) ==2834== Address 0x3C182171 is 9 bytes inside a block of size 52 alloc'd ==2834== at 0x3C01D2CB: malloc (vg_replace_malloc.c:105) ==2834== by 0x8050AC7: gmi_pend_trans_item_store (gmi.c:501) ==2834== by 0x8050F59: gmi_mcast (gmi.c:669) ==2834== by 0x804A52F: clmNodeJoinSend (clm.c:323) I'm not quite sure how to read this message. It says "at sendmsg" but the syscall param is "socketcall.recvmsg". So which one is it? I have cleaned up all uninitialized variables that could possibly be related so I'm a little stuck as to what to do next to remove this error. Also, what does the "address X is 9 bytes insid ea block of size 52 alloced". does that tell where the iov[i] was allocated? --__--__-- __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
|
From: Nicholas N. <nj...@ca...> - 2004-07-09 08:12:31
|
On Thu, 8 Jul 2004, smiley glitter wrote: > or anybody knows is valgrind uses pipes internally ? > for I know that my application doesn't use pipes but > /proc/pid/fd lists a few pipes ??? Valgrind 2.1.0 and later do use pipes. I can't help with your other questions, sorry. N |
|
From: smiley g. <smi...@ya...> - 2004-07-09 06:03:54
|
Hi friends, I had my application almost up and running with valgrind, when the admins upgraded my Linux machine to RedHat Linux AS 3 upgrade 2. I am facing a hang and I have no clue where its happening. The application starts numerous daemon processes and involves interaction among these daemon processes. I am not able to attach a debugger to these processes when valgrind is involved and --db-attach doesn't work with fork'd processes yet. Can somebody give me a clue about how to attach debugger to a daemon process and get to see code in the debugger. when i do a backtrace I only see a list of addresses and addr2line utility doesn't give me anything new. or anybody seeing anything new with upgrade 2 ? or anybody knows is valgrind uses pipes internally ? for I know that my application doesn't use pipes but /proc/pid/fd lists a few pipes ??? Thanks a lot in advance, Madhan. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |