|
From: Eyal L. <ey...@ey...> - 2004-01-03 14:16:20
|
There is a problem with spawn. 2.0.0 is OK but later it went south (2.1.0 and current). I set --trace-children=no for now (this works OK). Basically, I get a "child got sig 11" type message. I am moving up to current cvs. I also notice that the old way where my servers (which launch many threads) were running with 98% idle CPU now run with 0% idle, but the whole run seems to take at lease the same amount of time. This suggests busy waiting. I will check the new timing options and see which gives better performance. I am running on an AMD Athlon 1200 (pre-XP). Any suggestions for which values to try? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Jeremy F. <je...@go...> - 2004-01-03 22:40:16
|
On Sat, 2004-01-03 at 06:15, Eyal Lebedinsky wrote: > There is a problem with spawn. 2.0.0 is OK but later it went south > (2.1.0 and current). I set --trace-children=no for now (this works OK). > > Basically, I get a "child got sig 11" type message. I am moving up > to current cvs. > > > I also notice that the old way where my servers (which launch many > threads) were running with 98% idle CPU now run with 0% idle, but > the whole run seems to take at lease the same amount of time. This > suggests busy waiting. I will check the new timing options and > see which gives better performance. > > I am running on an AMD Athlon 1200 (pre-XP). Any suggestions for > which values to try? Um. It would be nice if you could give us a lot more detail - like the actual error message it generated, and other debugging stuff it probably printed. And what do you mean by "spawn"? There's no library function or syscall called that. Do you mean system? execve? Also, what does your server actually do? If you expect threads to be blocking in syscalls, which syscalls are they blocking in? The old pre-2.1 code had a tendency to wait up to a 100ms before doing anything, so if your code is syscall-heavy, it might have been using 2% CPU because the rest of the time Valgrind was just sleeping and doing nothing useful. If you run without Valgrind, what CPU usage do you get? If you're using 2.6 kernel, then there aren't really any tuneables which matter. It really depends on what your program is doing - if you have some CPU-bound threads and some IO-bound threads, then --lowlat-syscalls=yes might help, but I'd be surprised. J |
|
From: Eyal L. <ey...@ey...> - 2004-01-04 04:40:43
Attachments:
vg1.sh
|
Attached is a small program that demonstrates the problem. HTH. eyal@e7:~$ sh vg1.sh gcc version: 2.95.4 /home/eyal/zz.c(60) will pthread_attr_init /home/eyal/zz.c(63) pthread_attr_init=0 /home/eyal/zz.c(66) will pthread_create /home/eyal/zz.c(70) pthread_create=0 /home/eyal/zz.c(73) will pthread_attr_destroy /home/eyal/zz.c(76) pthread_attr_destroy=0 /home/eyal/zz.c(79) will pthread_join /home/eyal/zz.c(21) thread alive! zz.log /home/eyal/zz.c(34) wait() failed /home/eyal/zz.c(39) child returned 0 /home/eyal/zz.c(82) pthread_join=0 eyal@e7:~$ vi vg1.sh ***** set --trace-children=yes ***** eyal@e7:~$ sh vg1.sh gcc version: 2.95.4 /home/eyal/zz.c(60) will pthread_attr_init /home/eyal/zz.c(63) pthread_attr_init=0 /home/eyal/zz.c(66) will pthread_create /home/eyal/zz.c(70) pthread_create=0 /home/eyal/zz.c(73) will pthread_attr_destroy /home/eyal/zz.c(76) pthread_attr_destroy=0 /home/eyal/zz.c(79) will pthread_join /home/eyal/zz.c(21) thread alive! /home/eyal/zz.c(34) wait() failed /home/eyal/zz.c(44) child did not exit normally /home/eyal/zz.c(47) child received signal 11 /home/eyal/zz.c(82) pthread_join=0 eyal@e7:~$ -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2004-01-04 01:57:27
Attachments:
ssaexec.err.no
ssaexec.err.yes
|
Jeremy Fitzhardinge wrote: > Um. It would be nice if you could give us a lot more detail - like the > actual error message it generated, and other debugging stuff it probably > printed. And what do you mean by "spawn"? There's no library function > or syscall called that. Do you mean system? execve? OK, I now have these logs. First a good run of a program 'ssaexec' which simply spawn a child with the same arguments as itself. In real life it is used as a wrapper for redirecting stdout/err and such. ================================ $ valgrind --tool=memcheck --leak-check=yes --show-reachable=no --num-callers=32 \ > --error-limit=no --run-libc-freeres=no --trace-syscalls=yes --trace-children=no --logfile-fd=9 \ > ../bin/ssaexec -- ls *.dbg 9>ssaexec.err.no ids.dbg $ valgrind --tool=memcheck --leak-check=yes --show-reachable=no --num-callers=32 \ > --error-limit=no --run-libc-freeres=no --trace-syscalls=yes --trace-children=yes --logfile-fd=9 \ > ../bin/ssaexec -- ls *.dbg 9>ssaexec.err.yes ssaexec> Spawned program 'ls' failed -9 ssaexec> ErrorLog [104122857 1] ssaexec > It is now 20040104122857 ssaexec> ErrorLog [104122857 1] ssaexec.c 152 rc 2 9*10 ssaexec> ErrorLog [104122857 1] spawn.c 453 rc 9 ssaexec> ErrorLog [104122857 1] pgm_parms[1] ids.dbg ssaexec> ErrorLog [104122857 1] pgm_parms[0] ls ssaexec> ErrorLog [104122857 1] log_parms: pgm_name='ls' ssaexec> ErrorLog [104122857 1] child received signal 11 ssaexec> ErrorLog [104122857 1] child 'ls' did not exit normally $ ================================ The test should simply execute 'ls *.dbg'. And the piece of code that does the actual spawn is executings the usual pid = fork () if (pid == 0) execve () wait (&status) if (WIFEXITED (status))... execve() failed to start the child when --trace-children=yes is used. I should make it clear that the underlying process is a bit more complex than it should be (for this simple case). The events are: - main() starts - a thread is launched and main() waits (join) for it - the thread is where the real meat is, and it does the spawning If this looks too complex for people in the know to track then I can spend more time and synthesize a small program that reproduces the problem. But I hope the attached traces will ring someones bell. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Jeremy F. <je...@go...> - 2004-01-04 23:55:14
|
On Sat, 2004-01-03 at 17:57, Eyal Lebedinsky wrote: > Jeremy Fitzhardinge wrote: > > Um. It would be nice if you could give us a lot more detail - like the > > actual error message it generated, and other debugging stuff it probably > > printed. And what do you mean by "spawn"? There's no library function > > or syscall called that. Do you mean system? execve? > > OK, I now have these logs. First a good run of a program 'ssaexec' which > simply spawn a child with the same arguments as itself. In real life it > is > used as a wrapper for redirecting stdout/err and such. OK, sync to CVS and try again. I just fixed a bug which would cause child Valgrinds to die with a SEGV. (Though it would have only affected CVS HEAD; 2.1.0 should have been OK.) J |
|
From: Eyal L. <ey...@ey...> - 2004-01-05 02:22:30
|
Jeremy Fitzhardinge wrote: > > On Sat, 2004-01-03 at 17:57, Eyal Lebedinsky wrote: > > Jeremy Fitzhardinge wrote: > > > Um. It would be nice if you could give us a lot more detail - like the > > > actual error message it generated, and other debugging stuff it probably > > > printed. And what do you mean by "spawn"? There's no library function > > > or syscall called that. Do you mean system? execve? > > > > OK, I now have these logs. First a good run of a program 'ssaexec' which > > simply spawn a child with the same arguments as itself. In real life it > > is > > used as a wrapper for redirecting stdout/err and such. > > OK, sync to CVS and try again. I just fixed a bug which would cause > child Valgrinds to die with a SEGV. (Though it would have only affected > CVS HEAD; 2.1.0 should have been OK.) This fixed the problem with the sample program, but my real application still goes down sig 11 with --trace-children=yes. I will try to produce another sample. I tried to get a gdb trace but: ==26406== --gdb-attach=yes conflicts with --trace-children=yes ==26406== Please choose one or the other, but not both. very funny... -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2004-01-07 14:30:58
|
Jeremy Fitzhardinge wrote: > > On Sat, 2004-01-03 at 17:57, Eyal Lebedinsky wrote: > > Jeremy Fitzhardinge wrote: > > > Um. It would be nice if you could give us a lot more detail - like the > > > actual error message it generated, and other debugging stuff it probably > > > printed. And what do you mean by "spawn"? There's no library function > > > or syscall called that. Do you mean system? execve? > > > > OK, I now have these logs. First a good run of a program 'ssaexec' which > > simply spawn a child with the same arguments as itself. In real life it > > is > > used as a wrapper for redirecting stdout/err and such. > > OK, sync to CVS and try again. I just fixed a bug which would cause > child Valgrinds to die with a SEGV. (Though it would have only affected > CVS HEAD; 2.1.0 should have been OK.) As said before, while the sample program works now, my program still segfaults. I should explain how it works. To run valgrind with debugging each program (e.g. 'ssasrsv') is renamed to ssasrsv.orig and a shell script called 'ssasrsv' is put in its place, which does some setup and then runs 'ssasrsv.orig'. To get a clean run, when 'ssasrsv.orig' is about to be execvp()ed, the '.orig' suffix is removed thus execing the shell wrapper. OK, so in the following log you will see the execv() stage, which should start the shell wrapper (which will emit the 'start:' and 'cmd:' lines) which will then run 'ssasrsv'. I hope someone will figure what is going on. First, the '=no' case. We see 27843, which is the forked child, execing the shell, which then runs the real child (27849) which dumps the env as main() is entered. It looks right. ssasrsv [27843/1]> exec.c(294) ssaio_exec: CALL execvp [27843] start: Thu Jan 8 00:45:25 EST 2004 [27843] cmd: /ssa/builds/20031229-vgi/bin/ssasrsv -n3050 -m3052 -vus -1/ssa/builds/20031229-vgi/ids/idssrsv.log -2/ss a/builds/20031229-vgi/ids/idssrsv.err -3/ssa/builds/20031229-vgi/ids/ids.dbg -f356004891 --27849-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --27849-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --27849-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --27849-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --27849-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --27849-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --27849-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --27849-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:25 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:27 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==27849== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==27849== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==27849== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==27849== ==27849== Time: 2004/01/08 00:45:27 ==27849== Conditional jump or move depends on uninitialised value(s) ==27849== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==27849== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==27849== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==27849== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==27849== by 0x3C0012D5: (within /lib/ld-2.2.5.so) pid=27849 env[1]='PWD=/ssa/builds/20031229-vgi/ids' env[2]='SSANAME=/ssa/builds/20031229-vgn/ssaname' env[3]='SSACCID=GCCLIBC2' env[4]='SSAWORKDIR=/ssa/builds/20031229-vgi/ids' Now the same story with '=yes' looks very different. The forked child (28103) seems to actually sleep while the main program continues for a while (pid 28114 and 28121 which are probably 'basename' and 'date' in the shell). Finally the shell runs ssasrsv (pid 28128) which crashed right away. ssasrsv [28103/1]> exec.c(294) ssaio_exec: CALL execvp --28103-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28103-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28103-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28103-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28103-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28103-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28103-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28103-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28103== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28103== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28103== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28103== ==28103== Time: 2004/01/08 00:46:14 ==28103== Conditional jump or move depends on uninitialised value(s) ==28103== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28103== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28103== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28103== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28103== by 0x3C0012D5: (within /lib/ld-2.2.5.so) --28114-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28114-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28114-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28114-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28114-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28114-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28114-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28114-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28114== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28114== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28114== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28114== ==28114== Time: 2004/01/08 00:46:15 ==28114== Conditional jump or move depends on uninitialised value(s) ==28114== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28114== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28114== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28114== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28114== by 0x3C0012D5: (within /lib/ld-2.2.5.so) --28121-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28121-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28121-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28121-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28121-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28121-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28121-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28121-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C0015FC: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C001652: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C00820C: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28121== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28121== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28121== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) ==28121== ==28121== Time: 2004/01/08 00:46:16 ==28121== Conditional jump or move depends on uninitialised value(s) ==28121== at 0x3C00821A: _dl_relocate_object (in /lib/ld-2.2.5.so) ==28121== by 0x3C002A88: dl_main (in /lib/ld-2.2.5.so) ==28121== by 0x3C00BCE8: _dl_sysdep_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C001819: _dl_start_final (in /lib/ld-2.2.5.so) ==28121== by 0x3C00178A: _dl_start (in /lib/ld-2.2.5.so) ==28121== by 0x3C0012D5: (within /lib/ld-2.2.5.so) [28103] start: Thu Jan 8 00:46:16 EST 2004 [28103] cmd: /ssa/builds/20031229-vgi/bin/ssasrsv -n3050 -m3052 -vus -1/ssa/builds/20031229-vgi/ids/idssr sv.log -2/ssa/builds/20031229-vgi/ids/idssrsv.err -3/ssa/builds/20031229-vgi/ids/ids.dbg -f355182354 --28128-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28128-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28128-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28128-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28128-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28128-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28128-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28128-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF Executable is mapped outside of range 0x80c9000-0x4fffd000 failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory --28135-- warning: line info addresses out of order at entry 1751: 0xB800CB19 0x70019599 --28135-- warning: line info addresses out of order at entry 1755: 0xB800CB2E 0x700195AE --28135-- warning: line info addresses out of order at entry 1827: 0xB800CC76 0x700198DA --28135-- warning: line info addresses out of order at entry 1831: 0xB800CC88 0x700198EC --28135-- warning: line info addresses out of order at entry 2161: 0xB800D421 0x7001A82D --28135-- warning: line info addresses out of order at entry 2165: 0xB800D441 0x7001A845 --28135-- warning: line info addresses out of order at entry 29797: 0xB8039478 0x7007288C --28135-- warning: line info addresses out of order at entry 29804: 0xB80394AB 0x700728BF ==28135== Time: 2004/01/08 00:46:17 ==28135== Conditional jump or move depends on uninitialised value(s) ==28135== at 0x3C0015E7: _dl_start (in /lib/ld-2.2.5.so) ==28135== by 0x3C0012D5: (within /lib/ld-2.2.5.so) -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2004-01-07 23:18:55
Attachments:
vg2.sh
|
I found what is causing the problem. I run a program which execvp()s a shell which runs the original program. My shell runs the program as 'valgrind ... ssasrsv', meaning that valgrind is memchecking itself. Attached is a program that demonstrates the problem. It used to be OK until 2.0.0 but is failing since 2.1.0. I now changed my scripts to never recurse into valgrind (I never really needed or wanted to do so). Still, something changed which needs a looking into. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |