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
(8) |
3
(26) |
4
(14) |
5
(23) |
6
(8) |
7
(6) |
|
8
(1) |
9
(5) |
10
|
11
(7) |
12
|
13
(4) |
14
(2) |
|
15
|
16
(6) |
17
(4) |
18
(18) |
19
(10) |
20
(13) |
21
(2) |
|
22
|
23
(1) |
24
(7) |
25
(13) |
26
(35) |
27
(5) |
28
(2) |
|
29
(3) |
30
(5) |
31
(7) |
|
|
|
|
|
From: Patrick O. <Pat...@in...> - 2004-08-19 06:27:59
|
On Wed, 2004-08-18 at 17:12, Eric Estievenart wrote: > Patrick Ohly wrote: > > >>>perhaps I am missing something obvious, but > >>>is there a possibility to print the address > >>>of a memory block which was leaked in the > >>>report of the leak? I'm using memcheck. > > > > Can you point me in the right direction so that (when > > I find the time) I can provide a patch which does that? > > Would that be accepted into valgrind mainline? > > I don't see why exactly you need the address of > leaked blocks, except if: > - your program logs additional information associated > to the blocks when allocating them, e.g. for a web browser: > block at 0xXYZ allocated when requesting doc http://xxx/zzz This is exactly what I have. > For now, if you are in a hurry, Not any more because after some more searching I found the reason for the leak, and ... > you can have a look > at memcheck/mac_leakcheck.c, and: > - Add an address member in LossRecord structure > - tweak MAC_(pp_LeakError) so as to print it > - tweak MAC_(do_detect_memory_leaks): > - do not compare blocks together > - initialize the address in the LossRecord struct > > (But such a change is likely to be never accepted in > Valgrind, since it is really kludgy !) ... as it wouldn't be considered generally useful I won't bother to change it. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Software & Solutions Group Hermuelheimer Strasse 8a 50321 Bruehl Germany Tel: +49-2232-2090-30 Fax: +49-2232-2090-29 |
|
From: Tom H. <th...@cy...> - 2004-08-19 06:11:09
|
In message <412...@ci...>
Tom Hu <to...@ci...> wrote:
> xxx_validate_packet()
> {
> ...
> ...
> int rc = 0;
> if (!data) {
> return (XXX_ERROR_INVALID_PARAMETER);
> }
> xxx_debug_from_sa(sa, &debug);
> if (!receiver) xxx_log_hdr(&debug, data, receiver);
> hdr = (xxx_header *)data;
>
> /* The packet data length has to be the same as ike header length */
> if (len != ntohl(hdr->length)) {
> return XXX_INVALID_SYNTAX;
> }
>
> /* Validate spi */
> memset(spi_zero, 0x0, XXX_SPI_SIZE);
> /* Init spi MUST NOT be zero */
> rc = memcmp(hdr->init_spi, spi_zero, XXX_SPI_SIZE) ;
> =====> line 1219
> /* if (memcmp(hdr->init_spi, spi_zero, XXX_SPI_SIZE) == 0) { */
> if (rc == 0) {
> ======> line 1221
> return XXX_INVALID_SYNTAX;
> ....
> ...
> ...
> }
>
> Basically, valgrind complains line 1219 and 1221. I do not see any
> problem in 1221. It looks like rc has been initilize when declaring. The
> only I suspect is memcmp() call. Are both complained the same problem
> from memcmp or not? If those are memcmp problem. What is the possibility
> reason? Should I ignore this? If yes, how to do that?
The first complaint is from inside memcmp so either the length you
gave is uninitialised or one or more of the bytes being compared is.
I assume XXX_SPI_SIZE is a defined constant, and spi_zero is clearly
initialised, so presumably hdr->init_spi is not fully defined.
If the memcmp comapres uninitialised values then it's result is also
effectively uninitialised so the comparison of rc with zero will also
generate a warning.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom Hu <to...@ci...> - 2004-08-19 01:40:04
|
I have question about Conditional jump or move depends on uninitialised
value. I saw a lot error in my code. It is really bothered me.
I used valgrind 2.1.1.
The complain error is:
==31597== Conditional jump or move depends on uninitialised value(s)
==31597== at 0x3C01DFD4: memcmp (mac_replace_strmem.c:323)
==31597== by 0x805F10B: xxx_validate_packet (xxx_parser.c:1219)
==31597== by 0x80685CF: xxx_send_packet (xxx_action.c:48)
==31597== by 0x8068C51: action_send_init_msg (xxx_action.c:281)
==31597==
==31597== Conditional jump or move depends on uninitialised value(s)
==31597== at 0x805F116: xxx_validate_packet (xxx_parser.c:1221)
==31597== by 0x80685CF: xxx_send_packet (xxx_action.c:48)
==31597== by 0x8068C51: action_send_init_msg (xxx_action.c:281)
==31597== by 0x806C442: xxx_sm_internal (xxx_sm.c:261)
==31597==
The source snip is here:
xxx_validate_packet()
{
...
...
int rc = 0;
if (!data) {
return (XXX_ERROR_INVALID_PARAMETER);
}
xxx_debug_from_sa(sa, &debug);
if (!receiver) xxx_log_hdr(&debug, data, receiver);
hdr = (xxx_header *)data;
/* The packet data length has to be the same as ike header length */
if (len != ntohl(hdr->length)) {
return XXX_INVALID_SYNTAX;
}
/* Validate spi */
memset(spi_zero, 0x0, XXX_SPI_SIZE);
/* Init spi MUST NOT be zero */
rc = memcmp(hdr->init_spi, spi_zero, XXX_SPI_SIZE) ;
=====> line 1219
/* if (memcmp(hdr->init_spi, spi_zero, XXX_SPI_SIZE) == 0) { */
if (rc == 0) {
======> line 1221
return XXX_INVALID_SYNTAX;
....
...
...
}
Basically, valgrind complains line 1219 and 1221. I do not see any
problem in 1221. It looks like rc has been initilize when declaring. The
only I suspect is memcmp() call. Are both complained the same problem
from memcmp or not? If those are memcmp problem. What is the possibility
reason? Should I ignore this? If yes, how to do that?
Thanks,
Tom
|
|
From: Tom H. <th...@cy...> - 2004-08-18 22:52:52
|
In message <B93...@ex...>
"Canann, Michael" <mic...@pr...> wrote:
> any idea how to fix the following configure warning messages?
>
> checking linux/mii.h usability... no
> checking linux/mii.h presence... yes
> configure: WARNING: linux/mii.h: present but cannot be compiled
> configure: WARNING: linux/mii.h: check for missing prerequisite headers?
> configure: WARNING: linux/mii.h: see the Autoconf documentation
> configure: WARNING: linux/mii.h: section "Present But Cannot Be Compiled"
> configure: WARNING: linux/mii.h: proceeding with the preprocessor's result
> configure: WARNING: linux/mii.h: in the future, the compiler will take precedence
> configure: WARNING: ## ------------------------------------------ ##
> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
> configure: WARNING: ## ------------------------------------------ ##
> checking for linux/mii.h... yes
You don't need to fix them, there is no problem. We take care to work
around that broken header.
> And after ignoring the config warnings, make fails with the following message:
>
> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I../include -I./x86 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -DELFSZ=32 -MT vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" -c -o vg_syscalls.o vg_syscalls.c; \
> then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f ".deps/vg_syscalls.Tpo"; exit 1; fi
> In file included from /usr/include/linux/timex.h:152,
> from vg_unsafe.h:65,
> from vg_syscalls.c:35:
> /usr/include/asm/timex.h:10:21: asm/msr.h: No such file or directory
> make[4]: *** [vg_syscalls.o] Error 1
But timex.h |= mii.h and asm.h != mii.h so there is little connection.
The problem you have is a broken timex.h header file - there is a comment
at the top which is missing the /* at the start.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Canann, M. <mic...@pr...> - 2004-08-18 22:03:00
|
any idea how to fix the following configure warning messages?
checking linux/mii.h usability... no
checking linux/mii.h presence... yes
configure: WARNING: linux/mii.h: present but cannot be compiled
configure: WARNING: linux/mii.h: check for missing prerequisite =
headers?
configure: WARNING: linux/mii.h: see the Autoconf documentation
configure: WARNING: linux/mii.h: section "Present But Cannot Be =
Compiled"
configure: WARNING: linux/mii.h: proceeding with the preprocessor's =
result
configure: WARNING: linux/mii.h: in the future, the compiler will take =
precedence
configure: WARNING: ## ------------------------------------------ ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
configure: WARNING: ## ------------------------------------------ ##
checking for linux/mii.h... yes
And after ignoring the config warnings, make fails with the following =
message:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include =
-I../include -I./x86 -DVG_LIBDIR=3D"\"/usr/local/lib/valgrind"\" =
-Winline -Wall -Wshadow -O -fno-omit-frame-pointer =
-mpreferred-stack-boundary=3D2 -g -DELFSZ=3D32 -MT vg_syscalls.o -MD =
-MP -MF ".deps/vg_syscalls.Tpo" -c -o vg_syscalls.o vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f =
".deps/vg_syscalls.Tpo"; exit 1; fi
In file included from /usr/include/linux/timex.h:152,
from vg_unsafe.h:65,
from vg_syscalls.c:35:
/usr/include/asm/timex.h:10:21: asm/msr.h: No such file or directory
make[4]: *** [vg_syscalls.o] Error 1
more info:
> uname -a
Linux vox2 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown
--
Michael
|
|
From: Tom H. <th...@cy...> - 2004-08-18 17:02:29
|
In message <412...@cc...>
Guy Incognito <tky...@cc...> wrote:
> This is also my first contact with the valgrind list, so bear with me.
> It seems that some of the Sys V ipc syscall checkes are
> incorrect in coregrind/vg_syscalls.c atleast in version 2.1.2.
>
> msgctl return value checks are faulty (res == 0 indicates success
> and that the buf has been touched by the kernel).
>
> semctl lacked manipulation altogether, I added this only partially
> but if the patch (below) seems ok, I can also write support
> for the rest of the semctl functionality (namely the GETALL is
> still missing, which is also quite a bit trickier to implement).
I fixed all these at the weekend - checking CVS would have saved
you some work ;-)
> ps. without looking into it, it seems rather nasty that
> valgrind dumps core when ran on -gstabs+ compiled binaries
> (given that stabs are info for gdb and when valgrind
> is being used so is usually gdb)
Use DWARF, it's so much nicer ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Guy I. <tky...@cc...> - 2004-08-18 16:24:59
|
(I'm not on the list, so please cc me replies)
This is also my first contact with the valgrind list, so bear with me.
It seems that some of the Sys V ipc syscall checkes are
incorrect in coregrind/vg_syscalls.c atleast in version 2.1.2.
msgctl return value checks are faulty (res == 0 indicates success
and that the buf has been touched by the kernel).
semctl lacked manipulation altogether, I added this only partially
but if the patch (below) seems ok, I can also write support
for the rest of the semctl functionality (namely the GETALL is
still missing, which is also quite a bit trickier to implement).
Anyway, they seemed to work now.
cheers,
Tommi Kyntola tky...@cc...
ps. without looking into it, it seems rather nasty that
valgrind dumps core when ran on -gstabs+ compiled binaries
(given that stabs are info for gdb and when valgrind
is being used so is usually gdb)
diff -Naur valgrind-2.1.2-vanilla/coregrind/vg_syscalls.c valgrind-2.1.2-semfix/coregrind/vg_syscalls.c
--- valgrind-2.1.2-vanilla/coregrind/vg_syscalls.c 2004-07-17 12:43:13.000000000 +0300
+++ valgrind-2.1.2-semfix/coregrind/vg_syscalls.c 2004-08-18 19:20:17.768761016 +0300
@@ -2538,6 +2538,19 @@
MAYBE_PRINTF("getuid32 ( )\n");
}
+#if defined(__GNU_LIBRARY__) && !defined(_SEM_SEMUN_UNDEFINED)
+/* union semun is defined by including <sys/sem.h> */
+#else
+/* according to X/OPEN we have to define it ourselves */
+union semun {
+ int val; /* value for SETVAL */
+ struct semid_ds *buf; /* buffer for IPC_STAT, IPC_SET */
+ unsigned short *array; /* array for GETALL, SETALL */
+ /* Linux specific part: */
+ struct seminfo *__buf; /* buffer for IPC_INFO */
+};
+#endif
+
PRE(ipc)
{
MAYBE_PRINTF("ipc ( %d, %d, %d, %d, %p, %d )\n",
@@ -2548,8 +2561,47 @@
arg3 * sizeof(struct sembuf) );
break;
case 2: /* IPCOP_semget */
+ break;
case 3: /* IPCOP_semctl */
+ {
+ switch (arg4 /* cmd */) {
+ case IPC_STAT:
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ SYSCALL_TRACK( pre_mem_write, tid, "semctl(buf)", args->buf,
+ sizeof(struct semid_ds) );
+ }
+ break;
+ case IPC_SET:
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ SYSCALL_TRACK( pre_mem_read, tid, "semctl(buf)", args->buf,
+ sizeof(struct semid_ds) );
+ }
+ break;
+# if defined(IPC_64)
+ case IPC_STAT|IPC_64:
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ SYSCALL_TRACK( pre_mem_write, tid, "semctl(buf)", args->buf,
+ sizeof(struct semid64_ds) );
+ }
+ break;
+# endif
+# if defined(IPC_64)
+ case IPC_SET|IPC_64:
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ SYSCALL_TRACK( pre_mem_read, tid, "semctl(buf)", args->buf,
+ sizeof(struct semid64_ds) );
+ }
+ break;
+# endif
+ default:
+ break;
+ }
break;
+ }
case 4: /* IPCOP_semtimedop */
SYSCALL_TRACK( pre_mem_read, tid, "semtimedop(sops)", arg5,
arg3 * sizeof(struct sembuf) );
@@ -2685,7 +2737,41 @@
switch (arg1 /* call */) {
case 1: /* IPCOP_semop */
case 2: /* IPCOP_semget */
+ break;
case 3: /* IPCOP_semctl */
+ {
+ switch (arg4 /* cmd */) {
+ case IPC_STAT:
+ if ( res == 0 ) {
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ VG_TRACK( post_mem_write, args->buf,
+ sizeof(struct semid_ds) );
+ }
+ }
+ break;
+ case IPC_SET:
+ break;
+# if defined(IPC_64)
+ case IPC_STAT|IPC_64:
+ if ( res == 0 ) {
+ if (arg5 != 0) {
+ union semun * args = (union semun *)arg5;
+ VG_TRACK( post_mem_write, args->buf,
+ sizeof(struct semid64_ds) );
+ }
+ }
+ break;
+# endif
+# if defined(IPC_64)
+ case IPC_SET|IPC_64:
+ break;
+# endif
+ default:
+ break;
+ }
+ break;
+ }
case 4: /* IPCOP_semtimedop */
break;
case 11: /* IPCOP_msgsnd */
@@ -2710,7 +2796,7 @@
{
switch (arg3 /* cmd */) {
case IPC_STAT:
- if ( res > 0 ) {
+ if ( res == 0 ) {
VG_TRACK( post_mem_write, arg5,
sizeof(struct msqid_ds) );
}
@@ -2719,7 +2805,7 @@
break;
# if defined(IPC_64)
case IPC_STAT|IPC_64:
- if ( res > 0 ) {
+ if ( res == 0 ) {
VG_TRACK( post_mem_write, arg5,
sizeof(struct msqid64_ds) );
}
|
|
From: Eric E. <eri...@fr...> - 2004-08-18 15:13:25
|
Patrick Ohly wrote: >>>perhaps I am missing something obvious, but >>>is there a possibility to print the address >>>of a memory block which was leaked in the >>>report of the leak? I'm using memcheck. > > Can you point me in the right direction so that (when > I find the time) I can provide a patch which does that? > Would that be accepted into valgrind mainline? I don't see why exactly you need the address of leaked blocks, except if: - your program logs additional information associated to the blocks when allocating them, e.g. for a web browser: block at 0xXYZ allocated when requesting doc http://xxx/zzz - you have a tool which consolidates the valgrind log with your custom log, so you can identify exactly the context in which your program triggered the leak In that case, it would be clever to add support for user data association to the blocks, probably through a valgrind user call. The pairs (key,value) associated with each block would be dumped directly in Valgrind log. That way the mechanism would be generic. This could also help tools like massif classifying the allocations based on user-defined contexts. Could you provide a detailed example (if different from what I supposed), so a generic way of solving that problem could be designed and implemented into Valgrind in the future ? For now, if you are in a hurry, you can have a look at memcheck/mac_leakcheck.c, and: - Add an address member in LossRecord structure - tweak MAC_(pp_LeakError) so as to print it - tweak MAC_(do_detect_memory_leaks): - do not compare blocks together - initialize the address in the LossRecord struct (But such a change is likely to be never accepted in Valgrind, since it is really kludgy !) Cheers -- Eric |
|
From: Patrick O. <Pat...@in...> - 2004-08-18 14:27:42
|
On Wed, 2004-08-18 at 15:34, Tom Hughes wrote: > In message <1092831252.554.137.camel@debian> > Patrick Ohly <Pat...@in...> wrote: > > > perhaps I am missing something obvious, but > > is there a possibility to print the address > > of a memory block which was leaked in the > > report of the leak? I'm using memcheck. > > Not at the moment. Can you point me in the right direction so that (when I find the time) I can provide a patch which does that? Would that be accepted into valgrind mainline? > > I know that this would be impossible when > > --leak-resolution causes several leaks to > > be merged into one, but in my case there's > > just one block. > > Even --leak-resolution=high will merge blocks allocated in > exactly the same place. Yep, but in my case it really was just one chunk. Sounds like "--leak-resolution=none" would be a good extension, too. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Software & Solutions Group Hermuelheimer Strasse 8a 50321 Bruehl Germany Tel: +49-2232-2090-30 Fax: +49-2232-2090-29 |
|
From: I K <add...@ho...> - 2004-08-18 14:03:49
|
Operating system name and version : Red Hat Linux 2.4.18-3bigmem Valgrind version: valgrind-2.1.2 I am not sure about the split. But I can find out. The output of "cat /proc/self/maps" : 08048000-0804c000 r-xp 00000000 03:06 328393 /bin/cat 0804c000-0804d000 rw-p 00003000 03:06 328393 /bin/cat 0804d000-08051000 rwxp 00000000 00:00 0 40000000-40013000 r-xp 00000000 03:06 426907 /lib/ld-2.2.5.so 40013000-40014000 rw-p 00013000 03:06 426907 /lib/ld-2.2.5.so 40014000-40015000 r--p 00000000 03:05 2442070 /usr/lib/locale/en_US/LC_IDENTI FICATION 40015000-40016000 r--p 00000000 03:05 294920 /usr/lib/locale/en_US/LC_MEASUR EMENT 40016000-40017000 r--p 00000000 03:05 2032337 /usr/lib/locale/en_US/LC_TELEPH ONE 40017000-40018000 r--p 00000000 03:05 2032396 /usr/lib/locale/en_US/LC_ADDRES S 40018000-40019000 r--p 00000000 03:05 2032340 /usr/lib/locale/en_US/LC_NAME 40019000-4001a000 r--p 00000000 03:05 720908 /usr/lib/locale/en_US/LC_PAPER 4001a000-4001b000 r--p 00000000 03:05 2032397 /usr/lib/locale/en_US/LC_MESSAG ES/SYS_LC_MESSAGES 4001b000-4001c000 r--p 00000000 03:05 294916 /usr/lib/locale/en_US/LC_MONETA RY 4001c000-40022000 r--p 00000000 03:05 573445 /usr/lib/locale/en_US/LC_COLLAT E 40022000-40023000 r--p 00000000 03:05 2441221 /usr/lib/locale/en_US/LC_TIME 40023000-40024000 r--p 00000000 03:05 918773 /usr/lib/locale/en_US/LC_NUMERI C 4002c000-4002d000 rw-p 00000000 00:00 0 4002d000-40058000 r--p 00000000 03:05 918783 /usr/lib/locale/en_US/LC_CTYPE 42000000-4212c000 r-xp 00000000 03:06 1149155 /lib/i686/libc-2.2.5.so 4212c000-42131000 rw-p 0012c000 03:06 1149155 /lib/i686/libc-2.2.5.so 42131000-42135000 rw-p 00000000 00:00 0 bfffb000-c0000000 rwxp ffffc000 00:00 0 "--tool=none" works fine. Even "--tool=addrcheck" is working now most of the times ! However, " --tool=memcheck" is not working at all and always gives : valgrind: vg_main.c:553 (layout_remaining_space): Assertion `(void*)-1 != vres" failed. My guess is that "--tool=memcheck" requires huge memory that the system is unable to provide. Is this right? Thank you very much. Iyad _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |
|
From: Tom H. <th...@cy...> - 2004-08-18 13:34:44
|
In message <1092831252.554.137.camel@debian>
Patrick Ohly <Pat...@in...> wrote:
> perhaps I am missing something obvious, but
> is there a possibility to print the address
> of a memory block which was leaked in the
> report of the leak? I'm using memcheck.
Not at the moment.
> I know that this would be impossible when
> --leak-resolution causes several leaks to
> be merged into one, but in my case there's
> just one block.
Even --leak-resolution=high will merge blocks allocated in
exactly the same place.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Patrick O. <Pat...@in...> - 2004-08-18 12:13:52
|
Hi all, perhaps I am missing something obvious, but is there a possibility to print the address of a memory block which was leaked in the report of the leak? I'm using memcheck. I know that this would be impossible when --leak-resolution causes several leaks to be merged into one, but in my case there's just one block. Having that address and some debug output might make it easier to track down a memory leak. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Tom H. <th...@cy...> - 2004-08-18 09:02:06
|
In message <BAY...@ho...>
I. K. <add...@ho...> wrote:
> I just installed Valgrind and tried to debug my program. The problem
> is that when I type, for example, " valgrind --tool=addrcheck -v
> ./hello " , I receive this :
Please include the version number when reporting a problem - it makes
like much easier.
> valgrind: vg_main.c:553 (layout_remaining_space): Assertion `(void*)-1
> != vres' failed.
This means that your system refused to allocate the shadow memory
space. What distribution and kernel are you using - this sort of
thing has been seen with some RedHat kernels but upgrading to the
latest kernel for that release usually solves it. In fact rebooting
often seems to solve it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-18 08:49:33
|
On Wed, 18 Aug 2004, I K wrote: > I just installed Valgrind and tried to debug my program. The problem is that > when I type, for example, " valgrind --tool=addrcheck -v ./hello " , I > receive this : > > valgrind: vg_main.c:553 (layout_remaining_space): Assertion `(void*)-1 != > vres' failed. > > I am sorry if this sounds dump. It's just my first day working with Valgrind > and I didn't find any reference to this problem in Valgrind's documentation. It's not a dumb question. Normally x86/Linux machines are setup with a 3G/1G user/kernel split of the address space. Do you know if your box has a different split, eg. 2G/2G? Can you post the output of 'cat /proc/self/maps' ? Also, can you try 'valgrind --tool=none ./hello' to see if that works? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-18 08:43:42
|
On Wed, 18 Aug 2004, Tom Hughes wrote: >> Has anyone been able to get valgrind to compile on this >> platform? > > There is no x86-64 support in valgrind at the moment. I have done/am doing some work on it, but it's not a simple task -- ie. several person-months' worth of work at least. But it's definitely on our radar, as it's easily the most commonly requested port. N |
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-18 07:24:46
|
> In message <595...@we...> > "Jeroen N. Witmond" <jn...@xs...> wrote: > >> During configuration of valgrind from CVS on debian sarge (the upcoming >> 3.1 release) I ran into the same problem with linux/mii.h Sefer Tov >> mentions at the bottom of >> http://article.gmane.org/gmane.comp.debugging.valgrind/1549/match=+mii >> and >> Nicholas Nethercote in >> http://lists.gnu.org/archive/html/bug-autoconf/2004-06/msg00056.html >> using kernel 2.4.26-1-386 and gcc version 3.3.4 (Debian >> 1:3.3.4-6sarge1). > > You may indeed have hit the same problem. > >> FWIW, I think this is a kernel header bug; file linux/mii.h does not >> #define __KERNEL__ before including file linux/types.h, or should use >> __u16 instead of u16. > > But it has nothing to do with this, as we are careful to define u16 > before including mii.h in vg_unsafe.h. The error above occurs during configuration, where you do not define u16. During the compilation of valgrind, the error does not occur. > >> Compilation results in: >> In file included from >> /home/jeroen/projects/valgrind/coregrind/vg_unsafe.h:56, >> from >> /home/jeroen/projects/valgrind/coregrind/vg_syscalls.c:35: >> /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type >> /usr/include/asm/ipc.h:10: error: parse error before '*' token >> /usr/include/asm/ipc.h:12: error: parse error before '}' token >> >> These can be fixed with the patch below. This has been tested only on >> one >> debian sarge system. > > The include of linux/msg.h was added to CVS a while and should fix > this. Was there some reason you also added the linux/compiler.h test? - I moved the include of linux/msg.h to before the include of asm/ipc.h, because the latter needs 'struct msgbuf'. - I have added the test for linux/compiler.h because debian sarge uses this header, even with a 2.4 kernel, and asm/ipc.h uses the __user annotation. Jeroen. |
|
From: I K <add...@ho...> - 2004-08-18 07:17:00
|
Fellow Valgrinders, I just installed Valgrind and tried to debug my program. The problem is that when I type, for example, " valgrind --tool=addrcheck -v ./hello " , I receive this : valgrind: vg_main.c:553 (layout_remaining_space): Assertion `(void*)-1 != vres' failed. I am sorry if this sounds dump. It's just my first day working with Valgrind and I didn't find any reference to this problem in Valgrind's documentation. I would really appreciate your help. Iyad _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Tom H. <th...@cy...> - 2004-08-18 06:23:59
|
In message <5.2.1.1.2.20040817123446.03dc35c8@api253>
"bruce.ferjulian" <fer...@em...> wrote:
> SUBJECT: Building on AMD Opteron Suse 9.1 (64_bit)
>
> I would like to use this very fast box to check code but
> there is no target for my platform...
>
> Linux api1053 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54
> UTC 2004 x86_64 x86_64 x86_64 GNU/Linux
>
> in ( configure.in, configure.guess ).
>
> Has anyone been able to get valgrind to compile on this
> platform?
There is no x86-64 support in valgrind at the moment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-18 06:23:27
|
In message <595...@we...>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> During configuration of valgrind from CVS on debian sarge (the upcoming
> 3.1 release) I ran into the same problem with linux/mii.h Sefer Tov
> mentions at the bottom of
> http://article.gmane.org/gmane.comp.debugging.valgrind/1549/match=+mii and
> Nicholas Nethercote in
> http://lists.gnu.org/archive/html/bug-autoconf/2004-06/msg00056.html
> using kernel 2.4.26-1-386 and gcc version 3.3.4 (Debian 1:3.3.4-6sarge1).
You may indeed have hit the same problem.
> FWIW, I think this is a kernel header bug; file linux/mii.h does not
> #define __KERNEL__ before including file linux/types.h, or should use
> __u16 instead of u16.
But it has nothing to do with this, as we are careful to define u16
before including mii.h in vg_unsafe.h.
> Compilation results in:
> In file included from
> /home/jeroen/projects/valgrind/coregrind/vg_unsafe.h:56,
> from
> /home/jeroen/projects/valgrind/coregrind/vg_syscalls.c:35:
> /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type
> /usr/include/asm/ipc.h:10: error: parse error before '*' token
> /usr/include/asm/ipc.h:12: error: parse error before '}' token
>
> These can be fixed with the patch below. This has been tested only on one
> debian sarge system.
The include of linux/msg.h was added to CVS a while and should fix
this. Was there some reason you also added the linux/compiler.h test?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Eric E. <eri...@fr...> - 2004-08-18 01:04:33
|
Jeroen N. Witmond wrote:
> ==2241== Conditional jump or move depends on uninitialised value(s)
> ==2241== at 0x804FAB4: main (SimpleExample.cpp:240)
>
> The relevant part of this source file SimpleExample.cpp is:
>
> const unsigned int nFailed = speedy.getRunCount(Executor::Failed);
> if (nFailed == 0) // <== line 240.
...
> This seems to indicate that variable nFailed *is* initialised. The
> corresponding part in the output of gdb command 'disassemble' is:
Looking at the source code, you may think that your variable
is properly initialized in the affectation nFailed = getRunCount(...).
What Valgrind tells you here is that the value returned by getRunCount()
is likely to be completely random, since it has not been initialized.
e.g. (the most simple case) :
int zz::getRunCount()
{
int k;
[ code which does not initialize k ]
return k;
}
Cheers
--
Eric
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-17 23:20:04
|
During configuration of valgrind from CVS on debian sarge (the upcoming 3.1 release) I ran into the same problem with linux/mii.h Sefer Tov mentions at the bottom of http://article.gmane.org/gmane.comp.debugging.valgrind/1549/match=+mii and Nicholas Nethercote in http://lists.gnu.org/archive/html/bug-autoconf/2004-06/msg00056.html using kernel 2.4.26-1-386 and gcc version 3.3.4 (Debian 1:3.3.4-6sarge1). FWIW, I think this is a kernel header bug; file linux/mii.h does not #define __KERNEL__ before including file linux/types.h, or should use __u16 instead of u16. Compilation results in: In file included from /home/jeroen/projects/valgrind/coregrind/vg_unsafe.h:56, from /home/jeroen/projects/valgrind/coregrind/vg_syscalls.c:35: /usr/include/asm/ipc.h:10: error: field `__user' has incomplete type /usr/include/asm/ipc.h:10: error: parse error before '*' token /usr/include/asm/ipc.h:12: error: parse error before '}' token These can be fixed with the patch below. This has been tested only on one debian sarge system. Jeroen. Index: configure.in =================================================================== RCS file: /home/kde/valgrind/configure.in,v retrieving revision 1.115 diff -u -r1.115 configure.in --- configure.in 14 Aug 2004 18:52:26 -0000 1.115 +++ configure.in 17 Aug 2004 17:25:59 -0000 @@ -331,7 +331,7 @@ # Checks for header files. AC_HEADER_STDC -AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/socket.h sys/statfs.h sys/time.h sys/endian.h endian.h termios.h unistd.h u time.h linux/fb.h linux/mii.h mqueue.h]) +AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/socket.h sys/statfs.h sys/time.h sys/endian.h endian.h termios.h unistd.h u time.h linux/fb.h linux/mii.h mqueue.h linux/compiler.h]) # Checks for typedefs, structures, and compiler characteristics. AC_TYPE_UID_T Index: coregrind/vg_unsafe.h =================================================================== RCS file: /home/kde/valgrind/coregrind/vg_unsafe.h,v retrieving revision 1.32 diff -u -r1.32 vg_unsafe.h --- coregrind/vg_unsafe.h 16 Aug 2004 19:46:55 -0000 1.32 +++ coregrind/vg_unsafe.h 17 Aug 2004 17:26:00 -0000 @@ -50,11 +50,11 @@ #include <net/if.h> /* for struct ifreq et al */ #include <net/if_arp.h> /* for struct arpreq */ #include <net/route.h> /* for struct rtentry */ -#ifdef KERNEL_2_6 +#include <linux/msg.h> /* for struct msgbuf */ +#ifdef HAVE_LINUX_COMPILER_H #include <linux/compiler.h> /* for __user definition */ #endif #include <asm/ipc.h> /* for struct ipc_kludge */ -#include <linux/msg.h> /* for struct msgbuf */ #include <linux/sem.h> /* for struct sembuf */ #include <scsi/sg.h> /* for the SG_* ioctls */ |
|
From: bruce.ferjulian <fer...@em...> - 2004-08-17 22:57:14
|
SUBJECT: Building on AMD Opteron Suse 9.1 (64_bit) I would like to use this very fast box to check code but there is no target for my platform... Linux api1053 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux in ( configure.in, configure.guess ). Has anyone been able to get valgrind to compile on this platform? -Bruce- |
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-17 22:50:25
|
Dear all,
When memchecking my C++ program SimpleExample with the CVS version of
valgrind, I get error:
==2241== Conditional jump or move depends on uninitialised value(s)
==2241== at 0x804FAB4: main (SimpleExample.cpp:240)
The relevant part of this source file SimpleExample.cpp is:
const unsigned int nFailed = speedy.getRunCount(Executor::Failed);
if (nFailed == 0) // <== line 240.
return 0;
else
return 1;
This seems to indicate that variable nFailed *is* initialised. The
corresponding part in the output of gdb command 'disassemble' is:
0x0804faa8 <main+566>: call 0x8051880
<_ZNK12UnitPlusPlus10TextRunner11getRunCountENS_8Executor5StateE>
0x0804faad <main+571>: mov %eax,0xffffffa4(%ebp)
0x0804fab0 <main+574>: cmpl $0x0,0xffffffa4(%ebp)
0x0804fab4 <main+578>: jne 0x804fad5 <main+611>
The expression 0xffffffa4(%ebp) adresses variable nFailed. This code was
generated by gcc version 3.3.4 (Debian 1:3.3.4-6sarge1). gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) generates essentially the same code, and
memchecking it with valgrind-2.1.0 results in the same error.
Can anybody tell me why I get this error?
Thanks in advance,
Jeroen.
|
|
From: Samofatov, N.
|
Hi, Dear Valgrind Developers! I'm on my way to make threaded version of Firebird to work under Valgrind. Here is my problem. ------------------------------------------------------------------------ -------------------------- =3D=3D6492=3D=3D Memcheck, a memory error detector for x86-linux. =3D=3D6492=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian = Seward et al. =3D=3D6492=3D=3D Using valgrind-2.1.2, a program supervision framework = for x86-linux. =3D=3D6492=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian = Seward et al. =3D=3D6492=3D=3D For more details, rerun with: -v =3D=3D6492=3D=3D =3D=3D6492=3D=3D valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: pthread_rwlockattr_setkind_np =3D=3D6492=3D=3D valgrind's libpthread.so: unimplemented function Please report this bug at: valgrind.kde.org ------------------------------------------------------------------------ -------------------------- The convern I have that people using very fresh Firebird client may have problems using Valgrind to debug their applications. They of course may apply some of the Valgrind patches floating around such as http://people.redhat.com/graydon/02-valgrind-pthread-api.patch but it would be nice to see this feature in main Valgrind tree. Since pthread_rwlockattr_setkind_np options are mostly performance optimizations stubbed implementation should work fine. We use PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP if it is available. Nickolay Samofatov |
|
From: Tom H. <th...@cy...> - 2004-08-16 19:58:53
|
In message <412...@ki...>
Mathieu Malaterre <mat...@ki...> wrote:
> Could someone confirm that this mem leak is in X11:
I can confirm that it isn't - it's actually in valgrind. It is
supposed to be suppressed by the default suppressions. Some older
versions may not manage to supress it on some systems however.
It doesn't really matter because the memory in question could only
ever be freed at exit anyway.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|