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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: <ste...@ex...> - 2003-08-27 20:35:26
|
Hello, when trying to convert a hp file produced by massif, I get the following message: $ hp2ps hp.25447.hp hp2ps: hp.25447.hp, line 11: integer unexpected any idea ? I tryed Haskell's hp2ps and the version you put on your page, and both versions (maybe it's the same ?) failed. here is the head of my .hp file: JOB "/ng/src/donze/ng/bin/intel-linux/exe/exa -free -p exa.lang (32 ms/ sample)" DATE "(time and date)" SAMPLE_UNIT "ms" VALUE_UNIT "bytes" MARK 3.0 BEGIN_SAMPLE 3.0 stack(s) 2820 END_SAMPLE 3.0 MARK 36.0 BEGIN_SAMPLE 36.0 0x40A717AF:get_or_allocate 200 heap-admin 8 stack(s) 3980 END_SAMPLE 36.0 MARK 68.0 BEGIN_SAMPLE 68.0 0x402CECB9:ChannelNew 23444 0x40A717AF:get_or_allocate 200 0x40DE68D9:HashMalloc 207 0x402DCCA8:NGDigestNew 104 0x40DE6C0E:HashTableNew 52 Stephane |
|
From: Tom H. <th...@cy...> - 2003-08-27 15:23:05
|
In message <287...@se...>
Jason Gauthier <jga...@la...> wrote:
> Maybe I just don't completely understand what I'm looking for. Can someone
> offer an idea?
>
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
The first place you want to look is check_dispel, as that is the
innermost function in that stack trace.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joerg B. <jo...@we...> - 2003-08-27 15:19:06
|
Jason Gauthier wrote:
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
>
> void reset_area(AREA_DATA * pArea)
> {
> 2997: long vnum=0;
> 2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
> 2989: if (pRoomArray[vnum]){
> 2990: reset_room(pRoomArray[vnum]);
> }
> }
> return;
> }
>
> Obviously, I have initialized vnum to 0 here.
only if pArea->min_vnum is initialized, else vnum has been initialized
and then was overwritten with some uninitialized.
> So does that mean pRoomArray is not initialized? It's a global array, and I
> thought they were initialized to NULL.
Joerg
|
|
From: Lee K. <lki...@cs...> - 2003-08-27 15:17:31
|
You should be looking at the lowest levle, line 246 in magic.c - the
cause should be much more apparent there.
L.
Jason Gauthier writes:
> This is driving me crazy.
>
> Maybe I just don't completely understand what I'm looking for. Can someone
> offer an idea?
>
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
>
> void reset_area(AREA_DATA * pArea)
> {
> 2997: long vnum=0;
> 2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
> 2989: if (pRoomArray[vnum]){
> 2990: reset_room(pRoomArray[vnum]);
> }
> }
> return;
> }
>
> Obviously, I have initialized vnum to 0 here.
> So does that mean pRoomArray is not initialized? It's a global array, and I
> thought they were initialized to NULL.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Jason G. <jga...@la...> - 2003-08-27 14:57:50
|
This is driving me crazy.
Maybe I just don't completely understand what I'm looking for. Can someone
offer an idea?
==20872== Conditional jump or move depends on uninitialised value(s)
==20872== at 0x81361A0: check_dispel (magic.c:246)
==20872== by 0x8123B6F: char_to_room (handler.c:1904)
==20872== by 0x81024BC: reset_room (db.c:2797)
==20872== by 0x8102B1B: reset_area (db.c:2990)
So,I look at reset_area:
void reset_area(AREA_DATA * pArea)
{
2997: long vnum=0;
2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
2989: if (pRoomArray[vnum]){
2990: reset_room(pRoomArray[vnum]);
}
}
return;
}
Obviously, I have initialized vnum to 0 here.
So does that mean pRoomArray is not initialized? It's a global array, and I
thought they were initialized to NULL.
|
|
From: Mincu A. <al...@cy...> - 2003-08-27 09:59:41
|
Here is the problem : My program has 3 threads that sleep in pthread_cond_timedwait, when i send a cancelation signal to one of the threads valgrind gives the following error: =3D=3D2417=3D=3D =3D=3D2417=3D=3D Thread 3: =3D=3D2417=3D=3D pthread_mutex_unlock: mutex is not locked =3D=3D2417=3D=3D at 0x402B1CC0: __pthread_mutex_unlock (in /usr/lib/valgrind/libpthread.so) =3D=3D2417=3D=3D by 0x402B120E: (within /usr/lib/valgrind/libpthread.so) =3D=3D2417=3D=3D by 0xBEADDEEE: ??? =3D=3D2417=3D=3D by 0x8054072: messages_main (messages.c:242) I guess that error occurs when the cleanup functions are executed because i do something like this: pthread_cleanup_push((void*)pthread_mutex_unlock, &mutex); pthread_mutex_lock(&mutex); ..... pthread_cond_timedwait(...); ..... pthread_cleanup_pop(1); My question is: Should pthread_cond_timedwait lock the mutex when exiting because of cancelation? |
|
From: <as...@ho...> - 2003-08-26 22:45:38
|
Hi, I want to use gdb-attach option with valgrind. Actually, I run my application from an application launcher. I specify the valgrind path to this application launcher and ask it to launch my application with valgrind. I have made a script which invokes valgrind with specific options. I specify this script to the application launcher. In this script, I included option for gdb-attach=yes. When I run my application, valgrind pauses on a valgrind warning, and asks ------Attach to GDB?---[Return/N/n/Y/y/C/c]---- When I want to give any option(return or N or C or y), it doesn't take it. Rather the shell gives me an error "Y:Command not found." That is, I am not able to interact with valgrind. Maybe it is expecting an answer from the application launcher. Is there any way, I can ask valgrind to take input from stdin? Thanks and Regards, Aasheesh |
|
From: Mark L. <lof...@qw...> - 2003-08-26 17:06:51
|
>From: Andreas Oesterhelt
>Subj: Probably OT: Losing memory within gethostbyname_r, inet_ntoa
>Date: 2003-05-08 07:01
>For example, gethostbyname_r is not supposed to do any allocations
>at all (the result structure and scratch buffer are provided by
>the caller). Yet at exit I get lots of these:
...
>Looking closer it seems as if ld was callocing memory for whatever
>use, leaving me with a dynamic allocation that I don't have a pointer
>to to free it. Even stranger: This being listed under "still reachable"
>implies that there is a pointer -- but where?
>
>Also note the oddness of gethostbyname_r@@GLIBC_2.1.2 although the
>application and valgrind were compiled and run on a glibc 2.2.4 system.
I've been working on a project lately that uses getaddrinfo() to resolve
names. This function soon calls gethostbyname2_r which has (it seems)
some of the same issues you are having with gethostbyname_r. In order to
save myself the headaches of seeing these errors repeated every time I
debug my program, I whipped up the following suppression file.
The invalid read scares me a little as it appears to be an off-by-one
read error in strrchr. The memory leaks are more of a nuisance I think,
as the amount of mem leaked remains constant (~2k) regardless of the
number of iterations on gethostbyname2_r.
Mark
--gethost.supp--
###############
## the getaddrinfo() calls gaih_inet() which in turn calls
gethostbyname2_r@@GLIBC_2.1.2
## this suppression file should hide all the errors in the
gethostbyname2_r function.
###############
## based on a glibc-2.2.4/gcc-2.96 setup (RH 7.2)
###############
################
##<---suppress the Invalid read of size 4
################
{
strrchr/_dl_map_object_from_fd(Addr4)
Memcheck:Addr4
fun:strrchr
fun:_dl_map_object_from_fd
}
################
##<---suppress all the memory leaks
################
{
gethostbyname2/malloc/_dl_map_object(Leak)
Memcheck:Leak
fun:malloc
fun:_dl_map_objec*
fun:dl_open_worker
fun:_dl_catch_error
}
{
gethostbyname2/malloc/__res_nsend(Leak)
Memcheck:Leak
fun:malloc
fun:__res_nsend
fun:__res_nquery
fun:__res_nquerydomain
}
{
gethostbyname2/(X)alloc/_dl_new_object(Leak)
Memcheck:Leak
fun:?alloc
fun:_dl_new_object
fun:_dl_map_object_from_fd
fun:_dl_map_object
}
{
gethostbyname2/calloc/_dl_check_map_version(Leak)
Memcheck:Leak
fun:calloc
fun:_dl_check_map_versions
fun:dl_open_worker
fun:_dl_catch_error
}
|
|
From: Benjamin L. <ben...@us...> - 2003-08-26 16:43:59
|
Find patch attached that should add syscall 7 __NR_waitpid support. It is based on wait4 code. Does it need to be ifdef-ed for? Or do we all have __NR_waitpid? The patch has worked for me with elinks -- which, by the way, I've found to be a nice partner to mutt. Later. -- Benjamin Lee Melbourne, Australia "Always real." http://www.realthought.net/ __________________________________________________________________________ You can always tell luck from ability by its duration. |
|
From: Rob L. <ro...@te...> - 2003-08-25 04:22:07
|
On Tue, Aug 19, 2003 at 08:45:35AM +0100, Nicholas Nethercote wrote: > I'd be interested to know why you want to do this. using valgrind with prorams using MPICH, for one :> mpich-1.2.x uses an 'mpirun' script, which takes care of launching the job on the differnt nodes of the job. it also happens to permute the order of the command line arguments and adds a few more. this works fine for mpirun -np 3 cpi but not so well for mpirun -np 3 valgrind cpi linking against valgrind is a lot easier than the current solution: acking a one-off shell script to do mpiruns work for you. this sound like something fun to play with. thanks. ==rob -- Rob Latham Chicago, IL USA |
|
From: Josef W. <Jos...@gm...> - 2003-08-23 10:52:25
|
Hi, On Wednesday 20 August 2003 14:07, Pascal GULA wrote: > Hi, > > I'm trying to found out how to correct the following type of trace: > > ==11318== 1 errors in context 1 of 4: > ==11318== Invalid free() / delete / delete[] > ==11318== at 0x400281C2: __builtin_vec_delete (vg_replace_malloc.c:252) > ==11318== by 0x4026D371: HashTable::~HashTable(void) > (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:130) > ==11318== by 0x40269FA2: __static_initialization_and_destruction_0 > (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) > ==11318== by 0x4026A029: global destructors keyed to CTypeX::testFd > (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) > ==11318== by 0x402644D2: (within > /home/pg2/platforms/i686-pc-linux-gnu/debug.ecusim/lib/libdevkit.so.1.0.4) > ==11318== by 0x4000A575: (within /lib/ld-2.1.3.so) > ==11318== Address 0x4045A024 is not stack'd, malloc'd or free'd > [...] > > It concerns global destructors which are keyed to strange reference... > > It doesn't make my program terminate abnormally but I'm curious why > Valgrind check it. These errors are triggered by calls to destructors of static C++ objects, so this seems to happen at program termination, and of course can't influence your program while it's running. The call to the destructors is triggered after you return from main, and the "...keyed to..." symbols are generated by the C++ compiler. Still, you should fix it. It could lead to spurious SEGFAULTS at program termination, and that's confusing. You seem to delete objects in the destructors which have never been allocated? Greetings, Josef > > Thanks. > > Bye. |
|
From: <jsa...@ma...> - 2003-08-22 20:55:47
|
Re previous message about MSG_DONTWAIT - send doesn't seem to have this problem (only recv, recvfrom, and recvmsg, I think). Whoops! |
|
From: Jon S. <jsa...@ma...> - 2003-08-22 20:15:08
|
First of all, Valgrind totally rocks - it has saved me a tremendous amount
of time since I've started using it to track down bug and memory leaks.
Think I've found a teensy bug though. The Valgrind-wrapped recv() and
send() called don't seem to honor MSG_DONTWAIT. The culprit seems to be:
int VGR_(recv)(int s, void *buf, size_t len, int flags)
{
__my_pthread_testcancel();
VGR_(wait_for_fd_to_be_readable_or_erring)(s);
__my_pthread_testcancel();
return __libc_recv(s, buf, len, flags);
}
If MSG_DONTWAIT isn't provided, then Valgrind shouldn't wait for the FD to
be readable or erring. This seems to fix things:
int VGR_(recv)(int s, void *buf, size_t len, int flags)
{
if (!(flags & MSG_DONTWAIT)) {
__my_pthread_testcancel();
VGR_(wait_for_fd_to_be_readable_or_erring)(s);
__my_pthread_testcancel();
}
return __libc_recv(s, buf, len, flags);
}
Similar fix in recvfrom and recvmsg. If this seems reasonable, I'll be
happy to whip up a diff if you'd like.
- Jon
--
----------------------------------------------------------------------
Jon Salz <jsalz@jsalz dot net> "In theory, there is no difference
http://jsalz.net/ between theory and practice.
In practice, there is."
- Yogi Berra
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-22 08:13:25
|
On Thu, 21 Aug 2003, Trey Jackson wrote: > I didn't see any mention of valgrind being strictly 32-bit in the > documentation. Does it support 64-bit? It's strictly IA-32 only, ie. won't run any 64-bit code. Apparently it can run 32-bit-only code on 64-bit machines like the Opteron; not sure about IA-64 machines though. N |
|
From: Bryan O'S. <bo...@se...> - 2003-08-22 03:39:23
|
On Thu, 2003-08-21 at 14:07, Trey Jackson wrote: > I didn't see any mention of valgrind being strictly 32-bit in the > documentation. Does it support 64-bit? It supports 64-bit code insofar as IA-32 does, yes. <b |
|
From: Trey J. <tja...@ic...> - 2003-08-21 22:55:29
|
All, I didn't see any mention of valgrind being strictly 32-bit in the documentation. Does it support 64-bit? TJ -- Trey Jackson tja...@ic... "If you choose not to decide, you still have made a choice." -- Neil Peart |
|
From: Pascal G. <pas...@ax...> - 2003-08-20 12:13:57
|
Hi, I'm trying to found out how to correct the following type of trace: ==11318== 1 errors in context 1 of 4: ==11318== Invalid free() / delete / delete[] ==11318== at 0x400281C2: __builtin_vec_delete (vg_replace_malloc.c:252) ==11318== by 0x4026D371: HashTable::~HashTable(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:130) ==11318== by 0x40269FA2: __static_initialization_and_destruction_0 (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x4026A029: global destructors keyed to CTypeX::testFd (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x402644D2: (within /home/pg2/platforms/i686-pc-linux-gnu/debug.ecusim/lib/libdevkit.so.1.0.4) ==11318== by 0x4000A575: (within /lib/ld-2.1.3.so) ==11318== Address 0x4045A024 is not stack'd, malloc'd or free'd ==11318== ==11318== 1 errors in context 2 of 4: ==11318== Invalid free() / delete / delete[] ==11318== at 0x4002807E: free (vg_replace_malloc.c:220) ==11318== by 0x40264D4B: CString::~CString(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/CString.cc:239) ==11318== by 0x40268409: __static_initialization_and_destruction_0 (/home/pg2/sourceware/rtsim/../devkit/devkit/CString.cc:58) ==11318== by 0x40268499: global destructors keyed to CString::catenate(char const *, int) (/home/pg2/sourceware/rtsim/../devkit/devkit/CString.cc:58) ==11318== by 0x402644D2: (within /home/pg2/platforms/i686-pc-linux-gnu/debug.ecusim/lib/libdevkit.so.1.0.4) ==11318== by 0x4000A575: (within /lib/ld-2.1.3.so) ==11318== Address 0x4045A1A0 is not stack'd, malloc'd or free'd ==11318== ==11318== 83 errors in context 3 of 4: ==11318== Invalid write of size 4 ==11318== at 0x4026D51E: HashTable::clear(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:176) ==11318== by 0x4026D35C: HashTable::~HashTable(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:129) ==11318== by 0x40269FA2: __static_initialization_and_destruction_0 (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x4026A029: global destructors keyed to CTypeX::testFd (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x402644D2: (within /home/pg2/platforms/i686-pc-linux-gnu/debug.ecusim/lib/libdevkit.so.1.0.4) ==11318== by 0x4000A575: (within /lib/ld-2.1.3.so) ==11318== Address 0x4045A024 is not stack'd, malloc'd or free'd ==11318== ==11318== 83 errors in context 4 of 4: ==11318== Invalid read of size 4 ==11318== at 0x4026D4DD: HashTable::clear(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:170) ==11318== by 0x4026D35C: HashTable::~HashTable(void) (/home/pg2/sourceware/rtsim/../devkit/devkit/DvkHash.cc:129) ==11318== by 0x40269FA2: __static_initialization_and_destruction_0 (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x4026A029: global destructors keyed to CTypeX::testFd (/home/pg2/sourceware/rtsim/../devkit/devkit/CTypeX.cc:47) ==11318== by 0x402644D2: (within /home/pg2/platforms/i686-pc-linux-gnu/debug.ecusim/lib/libdevkit.so.1.0.4) ==11318== by 0x4000A575: (within /lib/ld-2.1.3.so) ==11318== Address 0x4045A024 is not stack'd, malloc'd or free'd It concerns global destructors which are keyed to strange reference... It doesn't make my program terminate abnormally but I'm curious why Valgrind check it. Thanks. Bye. -- ============================================= GULA Pascal Ingénieur d'études chez AXLOG Ingénierie 19-21 rue du 8 mai 1945 94110 ARCUEIL Tel : 01.41.24.31.38 ============================================= |
|
From: David L. <lee...@ho...> - 2003-08-20 11:45:33
|
That sounds exactly like what's happening! Thanks, dave <>< -=- Teracruz -- Performance Made Simple Learn more about Teracruz database acceleration at http://www.teracruz.com >From: Jeremy Fitzhardinge <je...@go...> >To: David Lee <lee...@ho...> >CC: val...@li... >Subject: Re: [Valgrind-users] sys_epoll Support >Date: Wed, 20 Aug 2003 01:06:21 -0700 > >On Tue, 2003-08-19 at 13:34, David Lee wrote: > > Has anyone worked on adding the epoll syscalls to valgrind yet? I made >an > > attempt to hack in something, but it still doesn't work. I've attached >my > > diff below. > >I've never looked at epoll, so I don't know what's wrong with your >patch. However, judging by its name, epoll_wait is a blocking call, and >it doesn't seem you're doing anything to make it non-blocking. This >will cause all threads to block if any of them does. > >You might have better success trying to patch my "syscalls" tree, which >has a new syscall handling mechanism which can cope with blocking >syscalls. See http://www.goop.org/~jeremy/valgrind/snapshots/ . > > J > _________________________________________________________________ <b>Get MSN 8</b> and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus |
|
From: Nicholas N. <nj...@ca...> - 2003-08-20 11:10:24
|
On 20 Aug 2003, John Hetherington wrote: > Help, I'm struggling with suppressions ! Use --gen-suppressions=yes, it makes it much easier. You'll need a recent version of Valgrind. N |
|
From: Jeremy F. <je...@go...> - 2003-08-20 10:33:01
|
On Tue, 2003-08-19 at 13:34, David Lee wrote: > Has anyone worked on adding the epoll syscalls to valgrind yet? I made an > attempt to hack in something, but it still doesn't work. I've attached my > diff below. I've never looked at epoll, so I don't know what's wrong with your patch. However, judging by its name, epoll_wait is a blocking call, and it doesn't seem you're doing anything to make it non-blocking. This will cause all threads to block if any of them does. You might have better success trying to patch my "syscalls" tree, which has a new syscall handling mechanism which can cope with blocking syscalls. See http://www.goop.org/~jeremy/valgrind/snapshots/ . J |
|
From: John H. <joh...@ha...> - 2003-08-20 09:05:13
|
Help, I'm struggling with suppressions !
I know the format should be:
# {
# name_of_suppression
# kind: one of Param Value1 Value2 Value4 Value8
# Free Addr1 Addr2 Addr4 Addr8
# Cond (previously known as Value0)
# (if Param: name of system call param, if Free: name of free-ing
fn)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
# (optionally: caller2 name)
# (optionally: caller3 name)
# }
but I just can not get it to work.
Can anyone start me off by providing the entry to suppress the leak
below ?
TIA
-- John Hetherington.
==26458== 84 bytes in 7 blocks are definitely lost in loss record 7957
of 8995
==26458== at 0x4003CE85: malloc (vg_clientfuncs.c:100)
==26458== by 0x404F8B8C: XQueryTree (in /usr/X11R6/lib/libX11.so.6.2)
==26458== by 0x403E102B: XmGetVisibility (in
/usr/X11R6/lib/libXm.so.2.1)
==26458== by 0x403E0D30: IsTraversable (in
/usr/X11R6/lib/libXm.so.2.1)
==26458== by 0x403E0576: CallTraverseObsured (in
/usr/X11R6/lib/libXm.so.2.1)
==26458== by 0x403E02F2: _XmMgrTraversal (in
/usr/X11R6/lib/libXm.so.2.1)
==26458== by 0x403E13B5: XmProcessTraversal (in
/usr/X11R6/lib/libXm.so.2.1)
==26458== by 0x81A51D9: XiSetFocusArtifact (XiFocus.c:39)
==26458== by 0x817A870: cigSetArtifactFocus (cig_focus.c:54)
==26458== by 0x81B3EE0: ci_getargs (ci_pprim.c:456)
|
|
From: Dan K. <da...@ke...> - 2003-08-20 08:15:42
|
David Lee wrote: > Has anyone worked on adding the epoll syscalls to valgrind yet? I made > an attempt to hack in something, but it still doesn't work. I've > attached my diff below. > > For anyone curious, more info (man pages, etc.) on epoll can be found at > http://www.xmailserver.org/linux-patches/nio-improve.html. I could really use epoll support in valgrind, but have been too busy to add it... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: David L. <lee...@ho...> - 2003-08-20 06:19:54
|
Has anyone worked on adding the epoll syscalls to valgrind yet? I made an attempt to hack in something, but it still doesn't work. I've attached my diff below. For anyone curious, more info (man pages, etc.) on epoll can be found at http://www.xmailserver.org/linux-patches/nio-improve.html. dave <>< diff -uar valgrind-20030725/coregrind/vg_syscalls.c valgrind-20030725-tera/coregrind/vg_syscalls.c --- valgrind-20030725/coregrind/vg_syscalls.c 2003-07-24 16:00:03.000000000 -0500 +++ valgrind-20030725-tera/coregrind/vg_syscalls.c 2003-08-19 15:03:34.000000000 -0500 @@ -3463,6 +3463,42 @@ VG_TRACK( post_mem_write, arg1, sizeof( vki_ksigset_t ) ) ; break ; +# if defined(__NR_epoll_create) + case __NR_epoll_create: /* syscall 254 */ + /* int epoll_create(int size) */ + MAYBE_PRINTF("epoll_create ( %d )\n", arg1); + KERNEL_DO_SYSCALL(tid,res); + break; +# endif + +# if defined(__NR_epoll_ctl) + case __NR_epoll_ctl: /* syscall 255 */ + /* int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) */ + MAYBE_PRINTF("epoll_ctl ( %d, %d, %d, %p )\n", arg1, arg2, arg3, arg4); + if (arg4 != (UInt)NULL) + { + SYSCALL_TRACK( pre_mem_read, tid, "epoll_ctl", arg4, + sizeof(struct epoll_event) ); + } + KERNEL_DO_SYSCALL(tid,res); + break; +# endif + +# if defined(__NR_epoll_wait) + case __NR_epoll_wait: /* syscall 256 */ + /* int epoll_wait(int epfd, struct epoll_event * events, int maxevents, + int timeout) */ + MAYBE_PRINTF("epoll_wait ( %d, %p, %d, %d )\n", arg1, arg2, arg3, arg4); + SYSCALL_TRACK( pre_mem_write, tid, "epoll_wait", arg2, + arg3 * sizeof(struct epoll_event) ); + KERNEL_DO_SYSCALL(tid,res); + if (!VG_(is_kerror)(res) && res > 0 && arg2 != (UInt)NULL) + { + VG_TRACK( post_mem_write, arg2, res * sizeof(struct epoll_event) ); + } + break; +# endif + default: VG_(message) (Vg_DebugMsg,"FATAL: unhandled syscall: %d",syscallno); diff -uar valgrind-20030725/coregrind/vg_unsafe.h valgrind-20030725-tera/coregrind/vg_unsafe.h --- valgrind-20030725/coregrind/vg_unsafe.h 2003-06-14 03:50:27.000000000 -0500 +++ valgrind-20030725-tera/coregrind/vg_unsafe.h 2003-08-06 16:02:22.000000000 -0500 @@ -87,7 +87,7 @@ #include <sys/sysinfo.h> #include <sys/poll.h> - +#include <sys/epoll.h> /*--------------------------------------------------------------------*/ /*--- end vg_unsafe.h ---*/ -=- Teracruz -- Performance Made Simple Learn more about Teracruz database acceleration at http://www.teracruz.com _________________________________________________________________ <b>MSN 8:</b> Get 6 months for $9.95/month http://join.msn.com/?page=dept/dialup |
|
From: Jason G. <jga...@la...> - 2003-08-19 13:55:42
|
> -----Orig > Let's see: > > [~/grind/annelid] gcc a.o memcheck/vgskin_memcheck.so > coregrind/valgrind.so [~/grind/annelid] > VG_ARGS=--suppressions=default.supp; a.out ==26034== > Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==26034== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==26034== Using valgrind-20030725, a program supervision > framework for x86-linux. > ==26034== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==26034== Estimated CPU clock rate is 1404 MHz ==26034== For > more details, rerun with: -v ==26034== ==26034== ==26034== > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from > 0) ==26034== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==26034== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > ==26034== For a detailed leak analysis, rerun with: > --leak-check=yes ==26034== For counts of detected errors, > rerun with: -v > > So the answer seems to be yes, with some provisos: > > - You have to link with a particular skin. I linked with Memcheck > above. > > - You have to put the skin .so before valgrind.so when linking. > > - You have to setup $VG_ARGS, by adding a --suppressions= > entry, at the > least. > > I'd be interested to know why you want to do this. That's very nice. Thank you. The reason I want to do this: I run a MUD. I know it has some invalid read/writes and more than likely some memory issues (judging from the cores I've been getting :) ) The problem is, that I cannot reasonable run the MUD in valgrind and find these problems. I need the players to get on there and do what players do (hours or DAYS before a crash occurs). Therefore, I was hoping I could just create a single executable for simplicity. I could run it through the executable, but I thought this would be a little nicer. Thanks! |
|
From: Julian S. <js...@ac...> - 2003-08-19 08:05:17
|
On Tuesday 19 August 2003 07:18, Tom Hughes wrote: > In message <3F4...@re...> > > Steve Fink <sf...@re...> wrote: > > I was mostly wondering if, now that valgrind supports MMX and some SSE, > > it is now reporting that it is an MMX/SSE cpu? If so, is there some way > > of making it act stupid again? (I don't know whether my problem is with > > MMX or SSE instructions, actually.) > > I sent a patch to this list several weeks ago to stop valgrind > reporting the CPU as SSE capable for people with your problem. > > There shouldn't be any problem with MMX as valgrind's MMX support > is supposed to be complete. Yes, the problem happens because the current cvs head, and 20030725 report whatever the real machine's CPUID report, but do not actually implement all the SSE insns. Hence the Intel libraries think the cpu is sse capable when in fact it isn't. A quick hack is to change the definition of VG_(helper_CPUID) in vg_helpers.S back to what it was in 1.9.6 or thereabouts, which claimed to be a pre-MMX pentium-I. That should fool the intel libraries appropraitely. J |