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
(1) |
2
(9) |
3
(6) |
4
(4) |
5
(2) |
|
6
(6) |
7
(6) |
8
(4) |
9
(8) |
10
(4) |
11
(5) |
12
(2) |
|
13
(1) |
14
(11) |
15
(3) |
16
(12) |
17
(2) |
18
(12) |
19
(6) |
|
20
|
21
(11) |
22
(10) |
23
(7) |
24
(6) |
25
(11) |
26
(6) |
|
27
(1) |
28
(11) |
29
(3) |
30
(3) |
|
|
|
|
From: Tom S. <to...@pl...> - 2004-06-18 22:12:34
|
Jeroen N. Witmond wrote: >>I have two easy test cases that follow. Both generated executables that >>run, but when run under valgrind, they hang (using 100% cpu) when >>initializing the Java runtime. >> >>/* vg_cni.cc >> * compile with: >> * gcc-3.4 vg_cni.cc -o vg_cni -lgcj >> */ > > > FWIW, I have compiled and run your program, and it fails in the same way > (using all available CPU without producing output). When I kill the > program with signal 15, I get (among other stuff) the following output: > > ==3995== Process terminating with default action of signal 15 (SIGTERM) > ==3995== at 0x408FD810: pthread_cond_wait@@GLIBC_2.3.2 (in > /lib/i686/libc-2.3.2.so) > ==3995== by 0x4058EC97: GC_pthread_create (in /usr/lib/libgcj.so.3.0.0) > ==3995== by 0x405870A9: _Jv_ThreadStart(java::lang::Thread*, > _Jv_Thread_t*, void (*)(java::lang::Thread*)) (in > /usr/lib/libgcj.so.3.0.0) > ==3995== by 0x40464CE0: java::lang::Thread::start() (in > /usr/lib/libgcj.so.3.0.0) > ==3995== > > I would guess this means that the gcj runtime somehow bypasses valgrind's > thread handling, but I'm no expert. > > When I compile and link my simple java application with gcj, and valgrind > the resuling executable, I get the following warnings: > > ==4007== warning: Valgrind's pthread_attr_setschedparam does nothing > ==4007== (scheduling not changeable) > ==4007== your program may misbehave as a result > ==4007== warning: Valgrind's sem_destroy is incomplete > ==4007== (it always succeeds, even if semaphore waited on) > ==4007== your program may misbehave as a result > ==4007== warning: Valgrind's pthread_attr_destroy does nothing > ==4007== your program may misbehave as a result > > After that, the application runs and terminates normally. > > In both cases, I also get the warnings about "Conditional jump or move > depends on uninitialised value(s)" and "Syscall param sigaction(act) > contains uninitialised or unaddressable byte(s)". > > I am running RedHat9 (Linux BahcoBak 2.4.20-31.9 #1 Tue Apr 13 18:04:23 > EDT 2004 i686 i686 i386 GNU/Linux) and gcc/gcj version 3.2.2 20030222 (Red > Hat Linux 3.2.2-5). > > Hope this helps, > > Jeroen. So what is the difference between your "simple java application" and the code I posted? -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Jeroen N. W. <jn...@xs...> - 2004-06-18 21:40:57
|
> I have two easy test cases that follow. Both generated executables that > run, but when run under valgrind, they hang (using 100% cpu) when > initializing the Java runtime. > > /* vg_cni.cc > * compile with: > * gcc-3.4 vg_cni.cc -o vg_cni -lgcj > */ FWIW, I have compiled and run your program, and it fails in the same way (using all available CPU without producing output). When I kill the program with signal 15, I get (among other stuff) the following output: ==3995== Process terminating with default action of signal 15 (SIGTERM) ==3995== at 0x408FD810: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/i686/libc-2.3.2.so) ==3995== by 0x4058EC97: GC_pthread_create (in /usr/lib/libgcj.so.3.0.0) ==3995== by 0x405870A9: _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, void (*)(java::lang::Thread*)) (in /usr/lib/libgcj.so.3.0.0) ==3995== by 0x40464CE0: java::lang::Thread::start() (in /usr/lib/libgcj.so.3.0.0) ==3995== I would guess this means that the gcj runtime somehow bypasses valgrind's thread handling, but I'm no expert. When I compile and link my simple java application with gcj, and valgrind the resuling executable, I get the following warnings: ==4007== warning: Valgrind's pthread_attr_setschedparam does nothing ==4007== (scheduling not changeable) ==4007== your program may misbehave as a result ==4007== warning: Valgrind's sem_destroy is incomplete ==4007== (it always succeeds, even if semaphore waited on) ==4007== your program may misbehave as a result ==4007== warning: Valgrind's pthread_attr_destroy does nothing ==4007== your program may misbehave as a result After that, the application runs and terminates normally. In both cases, I also get the warnings about "Conditional jump or move depends on uninitialised value(s)" and "Syscall param sigaction(act) contains uninitialised or unaddressable byte(s)". I am running RedHat9 (Linux BahcoBak 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 i686 i386 GNU/Linux) and gcc/gcj version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Hope this helps, Jeroen. |
|
From: Mike S. <ms...@mo...> - 2004-06-18 18:35:10
|
On Fri, Jun 18, 2004 at 10:53:58AM +0530, Banibrata Dutta wrote: > I've been using CVS HEAD (i think 2.1.2) on RH-AS2.1, but have > not debugged programs handling signals in any non-default way etc. > Most of the times I'd had a signal reported problem, and debugged > that using Valgrind, i've faced problems, and have been told that > support for signals in Valgrind is weak. So you may be running up > against such a known issue. - Have you run "make regtest" in the valgrind source? - Can you confirm the testsuite hangs for you too? The same CVS version, make regtest doesn't lock up on both Debian/testing and AS 3.0. (both of those report a few dozen errors in the testsuite, but it doesn't get wedged). Thanks, Mike Simons > > -----Original Message----- > > Subject: [Valgrind-users] CVS latest valgrind + AS 2.1 + SIGCHLD == hang > > > > > > I'm seeing testsuite failures in valgrind on Redhat AS 2.1... > > I reported this as a bug a few weeks ago: > > http://bugs.kde.org/show_bug.cgi?id=82114 [...] > > The short version is it appears SIGCHLD signal handling is > > messed up ... when a child exits valgrind locks up solid and > > requires a kill -9 to "recover". |
|
From: Andrew H. <ap...@re...> - 2004-06-18 15:41:23
|
Tom Schutter writes: > Andrew Haley wrote: > > Tom Schutter writes: > > > Boehm, Hans wrote: > > > > I don't know what the specific issue is here. > > > > > > The specific issue is that control never returns from JvCreateJavaVM() > > > or JNI_CreateJavaVM() when the app is run under valgrind. > > > > I don't know much about Valgrind. However, my understanding is that > > Valgrind is supposed to emulate the host CPU, albeit more slowly. > > Yes, that is correct. > > > So, > > if the host CPU returns, so should Valgrind. That makes your problem > > a Valgrind bug, doesn't it? > > Maybe, maybe not. As far as I understand, GCJ is doing non-standard > things with stacks. I can't think of anything in particular. Scanning the stack, maybe? But there's nothing weird or illegal about that. Andrew. |
|
From: Tom S. <to...@pl...> - 2004-06-18 15:40:49
|
Jeroen N. Witmond wrote: > Tom (and list), > > I am not an expert on valgrind, Java, JNI or GCJ, so I have no answers, > just a few questions and comments, inlined below. > > >>I have a mixed Java/C app that I am trying to run valgrind on. The >>object of this exercise is to find a difficult-to-reproduct crash that >>is related to JNI and garbage collection. Most of the C code is >>valgrind clean, it is when it is used from JNI that I am having problems. >> >>It is obvious to me that valgrind will not be able to run a standard >>JVM, [...] > > > Do you have any evidence to support this statement? I am able to run > `valgrind --tool=memcheck -v java` on a simple Java application that does > not use JNI, without any problems, errors or warnings. Hmmm. Every time I attempted this it failed for me. But that was with an older valgrind and java. I will try again. >>[...] so I started looking into GCJ. GCJ will generate standard object >>code that I should be able to run valgrind on. [...] > > > Correct, but there is no guarantee that running this compiled version of > your application will fail in the same way, or even fail at all. The way > the JVM and GCJ implement garbage collection probably is not identical. No guarantee, but it might. My standard rule now for strange and difficult bugs is to run valgrind first before trying anything else. 9 times out of 10 I beleive that it takes less time to find the cause of the bug with valgrind than with any other method. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Tom S. <to...@pl...> - 2004-06-18 15:32:59
|
Andrew Haley wrote: > Tom Schutter writes: > > Boehm, Hans wrote: > > > I don't know what the specific issue is here. > > > > The specific issue is that control never returns from JvCreateJavaVM() > > or JNI_CreateJavaVM() when the app is run under valgrind. > > I don't know much about Valgrind. However, my understanding is that > Valgrind is supposed to emulate the host CPU, albeit more slowly. Yes, that is correct. > So, > if the host CPU returns, so should Valgrind. That makes your problem > a Valgrind bug, doesn't it? Maybe, maybe not. As far as I understand, GCJ is doing non-standard things with stacks. A valgrind internals expert could probably explain better why it is possibly a GCJ problem. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Grant S. <gs...@di...> - 2004-06-18 14:16:07
|
Odd issue here. I got this library supplied to me for tests. They define
and use a type "uint32", they have it typedef'ed as a "unsigned int"
which is 32 bits on this machine. Fine.
However, whenever I use that variable, valgrind gets upset and says I am
doing a "Invalid write of size 4" on that line. take this for example.
#//custom library include's are here..
int main()
{
uint32 value =3D 42; // <--we will call this line 10
...
return 0;
}
valgrind reports the Invalid write on line ten(see my comment).
Obviously this isn't a problem. So I am a bit confused as to why it is
reporting this. Any ideas on what I can look at?
System here is using the following config.
OS : Redhat 9
C Compiler : gcc 3.2.2
Valgrind : vagrind 2.1.1
The crazy thing here, is that see where I remove the "...", that is the
rest of the code that was received, there are a few functions defined
before it. If I remove all that code, valgrind doesn't report any
errors.
My first guess was I was getting the "wrong" line number for some
reason. However, if I add like 10 more definitions just like...
uint32 value1 =3D 42;
uint32 value2 =3D 42;
uint32 value2 =3D 42;
The number of "Invalid write size.." messages goes up for each line I
add. So I am thinking it really is complaining about this.
Something is funky here, not sure what to guess at. Any ideas of what to
look at?
-grant
=20
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-18 11:46:55
|
On Fri, 18 Jun 2004, Dennis Lubert wrote: > especially for debugging a Program under few memory conditions, I have > tried to run a program with > ulimit -v 180000 > set. Even with ls it does not work : > # valgrind --tool=memcheck ls > Segmentation Fault > > without the ulimit set, everything works fine. > > I have a P4 with 512MB RAM running Linux 2.6.6 with glibc 2.3.3 with NPTL > enabled and running HEAD from a few days ago Thanks for the report, but this is unlikely to change; Valgrind needs a fair bit of memory to run, it's pretty unavoidable. > (todays HEAD does not compile). Can you post the 'make' output? Thanks. N |
|
From: Jeroen N. W. <jn...@xs...> - 2004-06-18 09:03:40
|
Tom (and list),
I am not an expert on valgrind, Java, JNI or GCJ, so I have no answers,
just a few questions and comments, inlined below.
> I have a mixed Java/C app that I am trying to run valgrind on. The
> object of this exercise is to find a difficult-to-reproduct crash that
> is related to JNI and garbage collection. Most of the C code is
> valgrind clean, it is when it is used from JNI that I am having problems.
>
> It is obvious to me that valgrind will not be able to run a standard
> JVM, [...]
Do you have any evidence to support this statement? I am able to run
`valgrind --tool=memcheck -v java` on a simple Java application that does
not use JNI, without any problems, errors or warnings.
> [...] so I started looking into GCJ. GCJ will generate standard object
> code that I should be able to run valgrind on. [...]
Correct, but there is no guarantee that running this compiled version of
your application will fail in the same way, or even fail at all. The way
the JVM and GCJ implement garbage collection probably is not identical.
> But I am stuck at the
> starting gate.
Somebody else will have to look at your problem with valgrind and GCJ,
quoted below; it is beyond my scope.
Cheers,
Jeroen.
> Valgrind hangs when I try to initialize the GCJ Java runtime. It hangs
> with both of the alternatives that GCJ provides, namely JvCreateJavaVM()
> and JNI_CreateJavaVM(), although I suspect that one is just a wrapper
> around the other.
>
> Debian testing/unstable
> Linux rota 2.6.3-1-686 #2 Tue Feb 24 20:24:38 EST 2004 i686 GNU/Linux
> ii valgrind 2.1.1-3 A memory debugger for x86-linux
> ii gcj-3.4 3.4.0-1 The GNU compiler for Java(TM)
> ii gcc-3.4 3.4.0-1 The GNU C compiler
>
> I have two easy test cases that follow. Both generated executables that
> run, but when run under valgrind, they hang (using 100% cpu) when
> initializing the Java runtime.
>
> /* vg_cni.cc
> * compile with:
> * gcc-3.4 vg_cni.cc -o vg_cni -lgcj
> */
>
> #include <gcj/cni.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[]) {
> jint cni_error;
>
> /* Initialize the Java runtime. */
> printf("%s:%i\n", __FILE__, __LINE__);
> cni_error = JvCreateJavaVM(NULL);
> if (cni_error < 0) {
> printf(
> "ERROR: Unable to initialize the Java runtime, (%i)\n",
> (int) cni_error
> );
> return(EXIT_FAILURE);
> }
>
> printf("%s:%i\n", __FILE__, __LINE__);
> JvAttachCurrentThread(NULL, NULL);
>
> printf("%s:%i\n", __FILE__, __LINE__);
> JvDetachCurrentThread();
>
> printf("%s:%i\n", __FILE__, __LINE__);
> argc = argc;
> argv = argv;
> return(EXIT_SUCCESS);
> }
>
>
> /* vg_jni.c
> * compile with:
> * gcc-3.4 vg_jni.c -o vg_jni -lgcj
> */
>
> #include <jni.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> int main(int argc, char *argv[]) {
> JavaVMInitArgs vm_args;
> JNIEnv *env = NULL;
> JavaVM *jvm = NULL;
> jint jni_error;
>
> /* Setup the vm_args structure. */
> memset(&vm_args, 0, sizeof(vm_args));
> vm_args.version = JNI_VERSION_1_2;
>
> /* Create the Java Virtual Machine. */
> printf("%s:%i\n", __FILE__, __LINE__);
> jni_error = JNI_CreateJavaVM(&jvm, (void **) &env, &vm_args);
> if (jni_error < 0) {
> printf(
> "ERROR: Unable to create Java Virtual Machine, (%i)\n",
> (int) jni_error
> );
> return(EXIT_FAILURE);
> }
>
> printf("%s:%i\n", __FILE__, __LINE__);
> if ((*env)->ExceptionOccurred(env)) {
> printf("exception occurred %s:%i\
> n", __FILE__, __LINE__);
> }
>
>
> printf("%s:%i\n", __FILE__, __LINE__);
> (*jvm)->DestroyJavaVM(jvm);
>
> printf("%s:%i\n", __FILE__, __LINE__);
> argc = argc;
> argv = argv;
> return(EXIT_SUCCESS);
> }
>
>
>
> $ valgrind vg_cni
> ==5831== Memcheck, a memory error detector for x86-linux.
> ==5831== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
> ==5831== Using valgrind-2.1.1, a program supervision framework for
> x86-linux.
> ==5831== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
> ==5831== For more details, rerun with: -v
> ==5831==
> vg_cni.cc:14
> ==5831== Syscall param sigaction(act) contains uninitialised or
> unaddressable byte(s)
> ==5831== at 0x3CA36025: __libc_sigaction (in /lib/tls/libc-2.3.2.so)
> ==5831== Address 0x4FFFE830 is on thread 1's stack
> ==5831==
> ==5831== Syscall param sigaction(act) contains uninitialised or
> unaddressable byte(s)
> ==5831== at 0x3CA36025: __libc_sigaction (in /lib/tls/libc-2.3.2.so)
> ==5831== by 0x7FFFFFFB: ???
> ==5831== Address 0x4FFFE780 is on thread 1's stack
> ==5831==
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3C646535: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C6478C9: GC_push_current_stack (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C64E12D: GC_generic_push_regs (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C6479FD: GC_push_roots (in /usr/lib/libgcj.so.5.0.0)
> ==5831==
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3C64653A: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C6478C9: GC_push_current_stack (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C64E12D: GC_generic_push_regs (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C6479FD: GC_push_roots (in /usr/lib/libgcj.so.5.0.0)
> ==5831==
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3C646535: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C6465B9: GC_push_all_stack (in /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C64DB96: GC_push_all_stacks (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C649815: GC_default_push_other_roots (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831==
> ==5831== Syscall param sigaction(act) contains uninitialised or
> unaddressable byte(s)
> ==5831== at 0x3CAE551D: syscall (in /lib/tls/libc-2.3.2.so)
> ==5831== by 0x8048736: JvCreateJavaVM(void*) (in
> /home/tom/tmp/valgrind_gcj/vg_cni)
> ==5831== by 0x8048670: main (in /home/tom/tmp/valgrind_gcj/vg_cni)
> ==5831== Address 0x4FFFE9B0 is on thread 1's stack
> ==5831==
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3C64D25C: GC_pthread_create (in /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C472162: _Jv_ThreadStart(java::lang::Thread*,
> _Jv_Thread_t*, void (*)(java::lang::Thread*)) (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C49E6A6: java::lang::Thread::start() (in
> /usr/lib/libgcj.so.5.0.0)
> ==5831== by 0x3C473E09: _Jv_CreateJavaVM(void*) (in
> /usr/lib/libgcj.so.5.0.0)==5831==
> ==5831== Thread 2:
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3CB4CFF1: thread_wrapper (vg_libpthread.c:824)
> ==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
> ==5831==
> ==5831== Thread 2:
> ==5831== thread_wrapper: invalid attr->__detachstate
> ==5831== at 0x3CB4C00F: pthread_error (vg_libpthread.c:355)
> ==5831== by 0x3CB4D000: thread_wrapper (vg_libpthread.c:826)
> ==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
> ==5831==
> ==5831== Thread 2:
> ==5831== Conditional jump or move depends on uninitialised value(s)
> ==5831== at 0x3CB4D004: thread_wrapper (vg_libpthread.c:827)
> ==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
> ------------------------hangs here-----------------------------
>
> --
> Tom Schutter (mailto:to...@pl...)
> Platte River Associates, Inc. (http://www.platte.com)
|
|
From: Banibrata D. <du...@in...> - 2004-06-18 05:28:12
|
I've been using CVS HEAD (i think 2.1.2) on RH-AS2.1, but have not debugged programs handling signals in any non-default way etc. Most of the times I'd had a signal reported problem, and debugged that using Valgrind, i've faced problems, and have been told that support for signals in Valgrind is weak. So you may be running up against such a known issue. regards, bd > -----Original Message----- > From: val...@li... > [mailto:val...@li...] On Behalf > Of Mike Simons > Sent: Friday, June 18, 2004 3:14 AM > To: val...@li... > Subject: [Valgrind-users] CVS latest valgrind + AS 2.1 + > SIGCHLD == hang > > > Hello, > > I'm seeing testsuite failures in valgrind on Redhat AS 2.1... > I reported this as a bug a few weeks ago: > http://bugs.kde.org/show_bug.cgi?id=82114 > but didn't hear anything at all back from that... so I > figured I'd check the user lists to see if anyone knows a way > around the problem or where to start trying to figure out > what is wrong. > > The short version is it appears SIGCHLD signal handling is > messed up ... when a child exits valgrind locks up solid and > requires a kill -9 to "recover". > > - Has anyone been using the CVS HEAD versions on Redhat AS 2.1? > > > I tried checking out and building several cvs tags of > valgrind hoping to find when this behavior was introduced. > Unfortunately all 2.* versions appear to have the problem. > The 1.9.5 version didn't appear to have the problem, but > "regtest" didn't exist back then (when I tried to manually > run the tests they worked). > > Much has changed between 2.0.0 and 1.9.5, so I'm looking for > ideas on where to start... > > > Valgrind locks up after reporting an assert similar to the > following: === proxy 13480 for tid 1 exited status -1, res 0 > got signal 17 in LWP 13473 (13473) > > valgrind: vg_signals.c:2015 (vg_async_signalhandler): > Assertion `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. > ==13473== at 0xB802DE80: vgPlain_skin_assert_fail > (vg_mylibc.c:1211) > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==13473== at 0x810D8959: wait4 (in /lib/libc-2.2.4.so) > ==13473== by 0x8048E82: main (fdleak_cmsg.c:176) > === > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) > Conference Learn from the experts at JavaOne(SM), Sun's > Worldwide Java Developer Conference, June 28 - July 1 at the > Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-06-18 02:14:33
|
I am with you on that. Right now the only reason I'm runnign 32bit and not 64 bit is valgrind, it's that indispensable. Josh. On June 17, 2004 10:00 pm, David Ford wrote: > is to be able to use valgrind on x86_64, natively, not 32bit emulation, > as 32bit emulation doesn't help 64bit debugging at all :) > |
|
From: David F. <dav...@bl...> - 2004-06-18 02:00:02
|
is to be able to use valgrind on x86_64, natively, not 32bit emulation, as 32bit emulation doesn't help 64bit debugging at all :) |
|
From: Dennis L. <pla...@gm...> - 2004-06-17 22:23:39
|
Hi, especially for debugging a Program under few memory conditions, I have tried to run a program with ulimit -v 180000 set. Even with ls it does not work : # valgrind --tool=memcheck ls Segmentation Fault without the ulimit set, everything works fine. I have a P4 with 512MB RAM running Linux 2.6.6 with glibc 2.3.3 with NPTL enabled and running HEAD from a few days ago (todays HEAD does not compile). same bahaviour with latest release greets Dennis Carpe quod tibi datum est |
|
From: Mike S. <ms...@mo...> - 2004-06-17 21:43:56
|
Hello, I'm seeing testsuite failures in valgrind on Redhat AS 2.1... I reported this as a bug a few weeks ago: http://bugs.kde.org/show_bug.cgi?id=82114 but didn't hear anything at all back from that... so I figured I'd check the user lists to see if anyone knows a way around the problem or where to start trying to figure out what is wrong. The short version is it appears SIGCHLD signal handling is messed up ... when a child exits valgrind locks up solid and requires a kill -9 to "recover". - Has anyone been using the CVS HEAD versions on Redhat AS 2.1? I tried checking out and building several cvs tags of valgrind hoping to find when this behavior was introduced. Unfortunately all 2.* versions appear to have the problem. The 1.9.5 version didn't appear to have the problem, but "regtest" didn't exist back then (when I tried to manually run the tests they worked). Much has changed between 2.0.0 and 1.9.5, so I'm looking for ideas on where to start... Valgrind locks up after reporting an assert similar to the following: === proxy 13480 for tid 1 exited status -1, res 0 got signal 17 in LWP 13473 (13473) valgrind: vg_signals.c:2015 (vg_async_signalhandler): Assertion `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. ==13473== at 0xB802DE80: vgPlain_skin_assert_fail (vg_mylibc.c:1211) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==13473== at 0x810D8959: wait4 (in /lib/libc-2.2.4.so) ==13473== by 0x8048E82: main (fdleak_cmsg.c:176) === |
|
From: Tom H. <th...@cy...> - 2004-06-16 20:55:01
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> Awesome! It compiles just fine now.
Excellent. I've committed that fix. Thanks for your help.
> > There's a new patch on the bug now - you need to run autogen.sh and
> > configure after applying it.
>
> There's no autogen.sh in the valgrind-2.1.1 distribution, so I just
> ran aclocal && automake.
That's fine. It's only in CVS because the generated files are
included in the release tarballs.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 19:36:26
|
Tom,
Awesome! It compiles just fine now.
> valgrind --tool=none x86info -a
Okay, this gives the same output, regardless of whether valgrind is used or not.
> valgrind --tool=cachegrind -v x86info
This command gives the following cache information:
--22378-- warning: Pentium with 12 K micro-op instruction trace cache
--22378-- Simulating a 16 KB cache with 32 B lines
==22378== Cache configuration used:
==22378== I1: 16384B, 8-way, 32B lines
==22378== D1: 8192B, 4-way, 64B lines
==22378== L2: 524288B, 8-way, 64B lines
x86info -a gives the following cache information:
Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 128 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
L1 Data cache:
Size: 8KB Sectored, 4-way associative.
line size=64 bytes.
No L3 cache
Instruction trace cache:
Size: 12K uOps 8-way associative.
L2 unified cache:
Size: 512KB Sectored, 8-way associative.
line size=64 bytes.
> Will do - it should print a description of the cache that matches
> what x86info reports.
It appears to me that the above match.
> There's a new patch on the bug now - you need to run autogen.sh and
> configure after applying it.
There's no autogen.sh in the valgrind-2.1.1 distribution, so I just
ran aclocal && automake.
Joseph
--
http://www.cs.nyu.edu/~turian/
|
|
From: Tom H. <th...@cy...> - 2004-06-16 18:25:25
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> > Run something that looks at the CPU ID under valgrind - x86info for
> > example. I did in fact do that with that patch in place so it should
> > work. The only question was whether it would solve the problem.
>
> How would I do this?
> Please bear with me, I've never actually used valgrind :^}
Something like this:
valgrind --tool=none x86info -a
That should print details of your processor. If you want to test
the cachgrind fix then this:
valgrind --tool=cachegrind -v x86info
Will do - it should print a description of the cache that matches
what x86info reports.
> > I thought that might happen. It will need a very similar fix so I will
> > try and sort that out in a minute.
>
> I'm standing by.
There's a new patch on the bug now - you need to run autogen.sh and
configure after applying it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 17:37:07
|
Tom,
> Run something that looks at the CPU ID under valgrind - x86info for
> example. I did in fact do that with that patch in place so it should
> work. The only question was whether it would solve the problem.
How would I do this?
Please bear with me, I've never actually used valgrind :^}
> I thought that might happen. It will need a very similar fix so I will
> try and sort that out in a minute.
I'm standing by.
Joseph
--
http://www.cs.nyu.edu/~turian/
|
|
From: Tom S. <to...@pl...> - 2004-06-16 17:35:00
|
I have a mixed Java/C app that I am trying to run valgrind on. The
object of this exercise is to find a difficult-to-reproduct crash that
is related to JNI and garbage collection. Most of the C code is
valgrind clean, it is when it is used from JNI that I am having problems.
It is obvious to me that valgrind will not be able to run a standard
JVM, so I started looking into GCJ. GCJ will generate standard object
code that I should be able to run valgrind on. But I am stuck at the
starting gate.
Valgrind hangs when I try to initialize the GCJ Java runtime. It hangs
with both of the alternatives that GCJ provides, namely JvCreateJavaVM()
and JNI_CreateJavaVM(), although I suspect that one is just a wrapper
around the other.
Debian testing/unstable
Linux rota 2.6.3-1-686 #2 Tue Feb 24 20:24:38 EST 2004 i686 GNU/Linux
ii valgrind 2.1.1-3 A memory debugger for x86-linux
ii gcj-3.4 3.4.0-1 The GNU compiler for Java(TM)
ii gcc-3.4 3.4.0-1 The GNU C compiler
I have two easy test cases that follow. Both generated executables that
run, but when run under valgrind, they hang (using 100% cpu) when
initializing the Java runtime.
/* vg_cni.cc
* compile with:
* gcc-3.4 vg_cni.cc -o vg_cni -lgcj
*/
#include <gcj/cni.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
jint cni_error;
/* Initialize the Java runtime. */
printf("%s:%i\n", __FILE__, __LINE__);
cni_error = JvCreateJavaVM(NULL);
if (cni_error < 0) {
printf(
"ERROR: Unable to initialize the Java runtime, (%i)\n",
(int) cni_error
);
return(EXIT_FAILURE);
}
printf("%s:%i\n", __FILE__, __LINE__);
JvAttachCurrentThread(NULL, NULL);
printf("%s:%i\n", __FILE__, __LINE__);
JvDetachCurrentThread();
printf("%s:%i\n", __FILE__, __LINE__);
argc = argc;
argv = argv;
return(EXIT_SUCCESS);
}
/* vg_jni.c
* compile with:
* gcc-3.4 vg_jni.c -o vg_jni -lgcj
*/
#include <jni.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]) {
JavaVMInitArgs vm_args;
JNIEnv *env = NULL;
JavaVM *jvm = NULL;
jint jni_error;
/* Setup the vm_args structure. */
memset(&vm_args, 0, sizeof(vm_args));
vm_args.version = JNI_VERSION_1_2;
/* Create the Java Virtual Machine. */
printf("%s:%i\n", __FILE__, __LINE__);
jni_error = JNI_CreateJavaVM(&jvm, (void **) &env, &vm_args);
if (jni_error < 0) {
printf(
"ERROR: Unable to create Java Virtual Machine, (%i)\n",
(int) jni_error
);
return(EXIT_FAILURE);
}
printf("%s:%i\n", __FILE__, __LINE__);
if ((*env)->ExceptionOccurred(env)) {
printf("exception occurred %s:%i\n", __FILE__, __LINE__);
}
printf("%s:%i\n", __FILE__, __LINE__);
(*jvm)->DestroyJavaVM(jvm);
printf("%s:%i\n", __FILE__, __LINE__);
argc = argc;
argv = argv;
return(EXIT_SUCCESS);
}
$ valgrind vg_cni
==5831== Memcheck, a memory error detector for x86-linux.
==5831== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==5831== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==5831== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==5831== For more details, rerun with: -v
==5831==
vg_cni.cc:14
==5831== Syscall param sigaction(act) contains uninitialised or
unaddressable byte(s)
==5831== at 0x3CA36025: __libc_sigaction (in /lib/tls/libc-2.3.2.so)
==5831== Address 0x4FFFE830 is on thread 1's stack
==5831==
==5831== Syscall param sigaction(act) contains uninitialised or
unaddressable byte(s)
==5831== at 0x3CA36025: __libc_sigaction (in /lib/tls/libc-2.3.2.so)
==5831== by 0x7FFFFFFB: ???
==5831== Address 0x4FFFE780 is on thread 1's stack
==5831==
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3C646535: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C6478C9: GC_push_current_stack (in
/usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C64E12D: GC_generic_push_regs (in
/usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C6479FD: GC_push_roots (in /usr/lib/libgcj.so.5.0.0)
==5831==
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3C64653A: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C6478C9: GC_push_current_stack (in
/usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C64E12D: GC_generic_push_regs (in
/usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C6479FD: GC_push_roots (in /usr/lib/libgcj.so.5.0.0)
==5831==
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3C646535: GC_push_all_eager (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C6465B9: GC_push_all_stack (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C64DB96: GC_push_all_stacks (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C649815: GC_default_push_other_roots (in
/usr/lib/libgcj.so.5.0.0)
==5831==
==5831== Syscall param sigaction(act) contains uninitialised or
unaddressable byte(s)
==5831== at 0x3CAE551D: syscall (in /lib/tls/libc-2.3.2.so)
==5831== by 0x8048736: JvCreateJavaVM(void*) (in
/home/tom/tmp/valgrind_gcj/vg_cni)
==5831== by 0x8048670: main (in /home/tom/tmp/valgrind_gcj/vg_cni)
==5831== Address 0x4FFFE9B0 is on thread 1's stack
==5831==
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3C64D25C: GC_pthread_create (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C472162: _Jv_ThreadStart(java::lang::Thread*,
_Jv_Thread_t*, void (*)(java::lang::Thread*)) (in /usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C49E6A6: java::lang::Thread::start() (in
/usr/lib/libgcj.so.5.0.0)
==5831== by 0x3C473E09: _Jv_CreateJavaVM(void*) (in
/usr/lib/libgcj.so.5.0.0)==5831==
==5831== Thread 2:
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3CB4CFF1: thread_wrapper (vg_libpthread.c:824)
==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
==5831==
==5831== Thread 2:
==5831== thread_wrapper: invalid attr->__detachstate
==5831== at 0x3CB4C00F: pthread_error (vg_libpthread.c:355)
==5831== by 0x3CB4D000: thread_wrapper (vg_libpthread.c:826)
==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
==5831==
==5831== Thread 2:
==5831== Conditional jump or move depends on uninitialised value(s)
==5831== at 0x3CB4D004: thread_wrapper (vg_libpthread.c:827)
==5831== by 0xB800FACC: do__quit (vg_scheduler.c:1792)
------------------------hangs here-----------------------------
--
Tom Schutter (mailto:to...@pl...)
Platte River Associates, Inc. (http://www.platte.com)
|
|
From: Tom H. <th...@cy...> - 2004-06-16 17:30:19
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> > A discussion of this error as it relates to valgrind can be found on
> > the appropriate entry in the valgrind bug tracker at:
> > http://bugs.kde.org/show_bug.cgi?id=79696
>
> Thank you for the pointer. With this patch, vg_to_ucode.c compiles.
> How can I verify that this function works as desired (or, at the very
> least, sanity check it)?
Run something that looks at the CPU ID under valgrind - x86info for
example. I did in fact do that with that patch in place so it should
work. The only question was whether it would solve the problem.
> > Well given that I can"t reproduce the problem I was waiting for
> > somebody to confirm that it worked first...
>
> I ran a 'make -k' and there's but one other instance of this error:
>
> cg_main.c: In function `Intel_cache_info':
> cg_main.c:1163: error: can't find a register in class `BREG' while
> reloading `asm'
>
> If you could provide a patch for this function, I'll let you know if it
> works.
I thought that might happen. It will need a very similar fix so I will
try and sort that out in a minute.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-16 16:29:48
|
> Except that whoever provided that "solution" clearly hadn't looked > at the code in question as the asm call that is triggering the problem > doesn't even have a clobber list! It only has input and output lists. Tom, It was I who provided "that 'solution'". I did not then (nor not even now) understand the intricacies of mixing C and ASM, but I thought that the time I spent on Google could only help those more knowledgable than I. I should point out that the gentoo bug-report now contains another comment, which you may (or may not) find informative. I sure don't. ;^) > A discussion of this error as it relates to valgrind can be found on > the appropriate entry in the valgrind bug tracker at: > http://bugs.kde.org/show_bug.cgi?id=79696 Thank you for the pointer. With this patch, vg_to_ucode.c compiles. How can I verify that this function works as desired (or, at the very least, sanity check it)? > Well given that I can"t reproduce the problem I was waiting for > somebody to confirm that it worked first... I ran a 'make -k' and there's but one other instance of this error: cg_main.c: In function `Intel_cache_info': cg_main.c:1163: error: can't find a register in class `BREG' while reloading `asm' If you could provide a patch for this function, I'll let you know if it works. > One thing I don't understand is why only the Gentoo build of gcc 3.3 > seems to have this problem. I'm using 3.3.3 on my Fedora Core 2 box > and I don't see this at all. Gentoo applies a number of patches to the vanilla source before building gcc. One of these probably accounts for the discrepancy. Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-16 14:29:18
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 16 Jun 2004, Tom Hughes wrote:
>
>> A discussion of this error as it relates to valgrind can be found on
>> the appropriate entry in the valgrind bug tracker at:
>>
>> http://bugs.kde.org/show_bug.cgi?id=79696
>
> Should it be committed?
Well given that I can't reproduce the problem I was waiting for
somebody to confirm that it worked first...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-16 14:21:09
|
On Wed, 16 Jun 2004, Tom Hughes wrote: > A discussion of this error as it relates to valgrind can be found on > the appropriate entry in the valgrind bug tracker at: > > http://bugs.kde.org/show_bug.cgi?id=79696 Should it be committed? N |
|
From: Tom H. <th...@cy...> - 2004-06-16 13:56:16
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> I cannot build valgrind, neither version 2.0.0 nor 2.1.1, using gcc-3.3.3-r6
>
> The error message I receive is:
> error: can't find a register in class `BREG' while reloading `asm'
>
> For all the details, as well as a proposed solution, please see <a
> href="http://bugs.gentoo.org/show_bug.cgi?id=54068">Gentoo Bug
> #54068</a>
Except that whoever provided that "solution" clearly hadn't looked
at the code in question as the asm call that is triggering the problem
doesn't even have a clobber list! It only has input and output lists.
A discussion of this error as it relates to valgrind can be found on
the appropriate entry in the valgrind bug tracker at:
http://bugs.kde.org/show_bug.cgi?id=79696
One thing I don't understand is why only the Gentoo build of gcc 3.3
seems to have this problem. I'm using 3.3.3 on my Fedora Core 2 box
and I don't see this at all.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Olly B. <ol...@su...> - 2004-06-16 13:30:58
|
On 2004-06-14, Tom Hughes <th...@cy...> wrote:
> What is does do is have an allocated buffer that contains all the
> pointers that have been passed to putenv. When the program exits that
> buffer is freed and the pointer is lost so it winds up looking like
> the memory given to putenv has been lost, which is has in fact, but
> only for those few milliseconds during program exit.
Couldn't valgrind intercept putenv() and track pointers passed, and not
report them as leaks? There's a slight wrinkle since you want to only
exclude the last pointer passed for a given variable name - so you
really need a parallel structure to that which glibc must have.
Cheers,
Olly
|