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
(5) |
2
(2) |
3
(9) |
4
(2) |
|
5
(2) |
6
(1) |
7
(2) |
8
(11) |
9
(13) |
10
(3) |
11
(1) |
|
12
|
13
(5) |
14
(18) |
15
(5) |
16
(10) |
17
|
18
|
|
19
|
20
(2) |
21
|
22
(10) |
23
(4) |
24
(8) |
25
(2) |
|
26
|
27
(10) |
28
(17) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2006-02-09 22:21:28
|
So I thought we have had the ability to read debuginfo packages for ages (Tom H will know for sure). Maybe it got broken by recent hacking. (if so, we should regression-test it somehow). What V version are you using? J On Thursday 09 February 2006 22:01, Dennis Lubert wrote: > Hello, > > I have recently discovered on the SuSE 10.0 Linux Distribution that > there are "debuginfo" packages for lots of installed packages. After > installing it for one of the apps I have installed, the ?? in the > stacktrace of gdb disappeared and I actually got usefuly output. I have > looke a bit further in it, and it installed the sources and some special > looking files. Now the question is, if its possible to get those > external infos somehow into valgrind too? Sorry to give so few > information about how its working, I couldnt really figure out. > > greets > > Dennis > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dennis L. <pla...@in...> - 2006-02-09 22:01:50
|
Hello, I have recently discovered on the SuSE 10.0 Linux Distribution that there are "debuginfo" packages for lots of installed packages. After installing it for one of the apps I have installed, the ?? in the stacktrace of gdb disappeared and I actually got usefuly output. I have looke a bit further in it, and it installed the sources and some special looking files. Now the question is, if its possible to get those external infos somehow into valgrind too? Sorry to give so few information about how its working, I couldnt really figure out. greets Dennis |
|
From: Nicholas N. <nj...@cs...> - 2006-02-09 20:54:21
|
On Thu, 9 Feb 2006 Brian_Howell@PlayStation.Sony.Com wrote: > I am now getting the same problem on Gentoo and now I am getting upset. > > I don't want spend hours looking for the memory range so will some one > please help me to remember the workaround. > I am using 3.0.1-r1 Valgrind on Gentoo. > > Here is just one of SEVERAL complaints file in Valgrind-users on this > issue, if there is not a bug there should be. > This email to the users list is similar to mine so don't need to file > another one myself. Only problem is that this one does not tell > KICKSTART_BASE to try. > > Valgrind should be compiled with something Gentoo can deal with or why > BOTHER putting it in the emerge tool if you have to do workaround. > > I need a SIMPLE workaround that does not involve recompiling in the future. > This is the second linux distrubution > I have used and second machine that I have used that showed this annoying > problem. > > FIX IT IN THE FUTURE, PLEASE!!!!!!!!!!!!!!!!!!! Two suggestions: (a) Try the most recent version of Valgrind. (b) Improve the way you report bugs. Whining won't get you anywhere. Nick |
|
From: Dennis L. <pla...@in...> - 2006-02-09 20:52:44
|
Why so offensive ? And why complain about an old version if you havent tried the latest release (3.1.0 out for 2.5 months now) or even the SVN, the bug could already been fixed there. Anyways it has been stated elsewhere already that valgrind cannot support just everything and that doing unusual hacks like shifting the load addresses isnt a good idea. Am Donnerstag, den 09.02.2006, 12:33 -0800 schrieb Brian_Howell@PlayStation.Sony.Com: > Had this problem with Valgrind on Fedora last year. After much search > finally found what I needed to do and > had to recompile Valgrind. > > I am now getting the same problem on Gentoo and now I am getting upset. > > [exec] sampleGameLobbyEPTest: no process killed > [exec] Result: 1 > [exec] valgrind: no process killed > [exec] Result: 1 > [exec] Executable range 0xb0000000-0xb080e7b0 is outside the > [exec] acceptable range 0x80d6000-0xaffff000 > [exec] valgrind: failed to load /usr/lib/valgrind/stage2: Cannot > allocate memory > [exec] Result: 1 > I can't remember where I put my workaround (involved recompilation and > memory adjustment, yuck) and it seems like several people in mailing lists > are having problem starting Valgrind on linux, especially Gentoo. > > I don't want spend hours looking for the memory range so will some one > please help me to remember the workaround. > I am using 3.0.1-r1 Valgrind on Gentoo. > > > Here is just one of SEVERAL complaints file in Valgrind-users on this > issue, if there is not a bug there should be. > This email to the users list is similar to mine so don't need to file > another one myself. Only problem is that this one does not tell > KICKSTART_BASE to try. > > Valgrind should be compiled with something Gentoo can deal with or why > BOTHER putting it in the emerge tool if you have to do workaround. > > I need a SIMPLE workaround that does not involve recompiling in the future. > This is the second linux distrubution > I have used and second machine that I have used that showed this annoying > problem. > > FIX IT IN THE FUTURE, PLEASE!!!!!!!!!!!!!!!!!!! > > Email Archive: valgrind-users (read-only) Search > > From: Tom Hughes <thh@cy...> > Re: Cannot start Valgrind > 2005-01-28 06:21 > > In message <000801c50446$16459d50$152ca8c0@nd> > Ilkka Huotari <ihu...@cc...> wrote: > > > I"m using Gentoo Linux 2.4. I installed Valgrind yesterday, first with > > emerge tool, then compiling manually from the sources. > > > > With either way, whenever I try to run it, I get this: > > > > # valgrind > > Executable range 0xb0000000-0xb01f4b40 is outside the > > acceptable range 0x80d0000-0x7ffff000 > > valgrind: failed to load /usr/lib/valgrind/stage2: Cannot allocate > memory > > > > What might be wrong? > > It looks likes your valgrind is build for a 3:1 user:kernel memory > split but your system has a 2:2 split so stage2 can"t be loaded as > the address it was built for is up in kernel space. > > You can rebuild valgrind with KICKSTART_BASE changed to a lower > address but with only 2Gb of address space you may have problems > running large programs under valgrind. > > Do you know why Gentoo is using a 2:2 split? Most systems these seem > to be moving to a 4:0 split if anything. > > Tom > > -- > Tom Hughes (thh@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > > > > > > > > Thread View > > Thread Author Date > > Re: Cannot start Valgrind Tom Hughes <thh@cy...> 2005-01-28 06:21 > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2006-02-09 20:45:54
|
> FIX IT IN THE FUTURE, PLEASE!!!!!!!!!!!!!!!!!!! Don't file bug reports against old versions, please. We fixed lots of address space layout problems in 3.1.0, which went out early Dec 05. I suggest you try that. J |
|
From: Brian_Howell@PlayStation.Sony.Com - 2006-02-09 20:33:29
|
Had this problem with Valgrind on Fedora last year. After much search=
finally found what I needed to do and
had to recompile Valgrind.
I am now getting the same problem on Gentoo and now I am getting upset.=
[exec] sampleGameLobbyEPTest: no process killed
[exec] Result: 1
[exec] valgrind: no process killed
[exec] Result: 1
[exec] Executable range 0xb0000000-0xb080e7b0 is outside the
[exec] acceptable range 0x80d6000-0xaffff000
[exec] valgrind: failed to load /usr/lib/valgrind/stage2: Cannot
allocate memory
[exec] Result: 1
I can't remember where I put my workaround (involved recompilation an=
d
memory adjustment, yuck) and it seems like several people in mailing l=
ists
are having problem starting Valgrind on linux, especially Gentoo.
I don't want spend hours looking for the memory range so will some one
please help me to remember the workaround.
I am using 3.0.1-r1 Valgrind on Gentoo.
Here is just one of SEVERAL complaints file in Valgrind-users on this
issue, if there is not a bug there should be.
This email to the users list is similar to mine so don't need to file
another one myself. Only problem is that this one does not tell
KICKSTART_BASE to try.
Valgrind should be compiled with something Gentoo can deal with or why=
BOTHER putting it in the emerge tool if you have to do workaround.
I need a SIMPLE workaround that does not involve recompiling in the fut=
ure.
This is the second linux distrubution
I have used and second machine that I have used that showed this annoyi=
ng
problem.
FIX IT IN THE FUTURE, PLEASE!!!!!!!!!!!!!!!!!!!
Email Archive: valgrind-users (read-only) Search
=
From: Tom Hughes <thh@cy...> =
Re: Cannot start Valgrind =
2005-01-28 06:21 =
=
In message <000801c50446$16459d50$152ca8c0@nd> =
Ilkka Huotari <ihu...@cc...> wrote: =
=
> I"m using Gentoo Linux 2.4. I installed Valgrind yesterday, first w=
ith
> emerge tool, then compiling manually from the sources. =
> =
> With either way, whenever I try to run it, I get this: =
> =
> # valgrind =
> Executable range 0xb0000000-0xb01f4b40 is outside the =
> acceptable range 0x80d0000-0x7ffff000 =
> valgrind: failed to load /usr/lib/valgrind/stage2: Cannot allocate =
memory =
> =
> What might be wrong? =
=
It looks likes your valgrind is build for a 3:1 user:kernel memory =
split but your system has a 2:2 split so stage2 can"t be loaded as =
the address it was built for is up in kernel space. =
=
You can rebuild valgrind with KICKSTART_BASE changed to a lower =
address but with only 2Gb of address space you may have problems =
running large programs under valgrind. =
=
Do you know why Gentoo is using a 2:2 split? Most systems these seem =
to be moving to a 4:0 split if anything. =
=
Tom =
=
-- =
Tom Hughes (thh@cy...) =
Software Engineer, Cyberscience Corporation =
http://www.cyberscience.com/ =
=
=
=
Thread View
=
Thread Author Date =
=
Re: Cannot start Valgrind Tom Hughes <thh@cy...> 2005-01-28 06:21 =
=
=
=
|
|
From: Nicholas N. <nj...@cs...> - 2006-02-09 05:37:19
|
On Wed, 8 Feb 2006, Dennis Lubert wrote: >> The same test passed in valgrind-2.1.0. Since "int" is a common x86 >> instruction, > It isnt common on x86 Linux, and valgrind was written mainly for Linux. > Under Linux only the syscall int 80 is used for anything, and following > the "implementation on demand" policy of valgrind it has not been > implemented. >> it should be supported by valgrind's VEX instruction translation >> layer. > Id disagree. Running your example program should probably segfault > anyways. The only use of int other than 'int 0x80' that I've seen is one JVM used it for generating certain kinds of exceptions (eg. array bounds exceptions). It worked prior to 3.0.0 and would be nice to get working again. Nick |
|
From: Tom H. <to...@co...> - 2006-02-08 22:46:33
|
In message <OFF...@us...>
Eduardo Munoz <ea...@us...> wrote:
> I greed with you but this is a test from your test suite
> none/tests/x86/init.c and the int.stderr.exp file has the following:
>
>
> Expected results from valgrind:
> Process terminating with default action of signal 11 (SIGSEGV)
> GPF (Pointer out of bounds?)
> at 0x........: main (int.c:5)
>
>
> I gues you just need to change you test cases or modify the expected
> results file.
Ah yes, we know that test fails at the moment as VEX doesn't yet
generate the right sort of trap for certain obscure instructions.
The test is left in because one day we would like to get back to
the point where everything that worked with the old UCode engine
works with VEX but obscure things like that are still relatively
low priority.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eduardo M. <ea...@us...> - 2006-02-08 19:23:48
|
I greed with you but this is a test from your test suite=20 none/tests/x86/init.c and the int.stderr.exp file has the following: Expected results from valgrind:=20 Process terminating with default action of signal 11 (SIGSEGV) GPF (Pointer out of bounds?) at 0x........: main (int.c:5) I gues you just need to change you test cases or modify the expected=20 results file. Regards, Eduardo A. Mu=F1oz |
|
From: Eduardo M. <ea...@us...> - 2006-02-08 19:22:15
|
I greed with you but this is a test from your test suite=20 none/tests/x86/init.c and the int.stderr.exp file has the following: Expected results from valgrind:=20 Process terminating with default action of signal 11 (SIGSEGV) GPF (Pointer out of bounds?) at 0x........: main (int.c:5) I gues you just need to change you test cases or modify the expected=20 results file. Regards, Eduardo A. Mu=F1oz |
|
From: Eduardo M. <ea...@us...> - 2006-02-08 17:53:09
|
Great!! Where can I get a patch for it . I am using valgrind 3.1.0=20 How do I get vex revision 1569?? Regards, Eduardo A. Mu=F1oz Julian Seward <js...@ac...>=20 02/08/2006 11:48 AM To Eduardo Munoz/Austin/IBM@IBMUS cc valgrind-users <val...@li...> Subject Re: Wrong results when running fxtract testcase with tool=3Dnone On Wednesday 08 February 2006 17:15, Eduardo Munoz wrote: > In a ia32 system compiled and run fxract .c program (it is one of the > testcases in valgrind 3.1.0) . It passed in valgrind 2.1.0. > Is it a bug in valgrind??=20 Yes it is. I only noticed it earlier this week; it does not always appear on x86 platforms, for reasons I don't understand. I fixed it with vex revision 1569. J |
|
From: Julian S. <js...@ac...> - 2006-02-08 17:48:36
|
On Wednesday 08 February 2006 17:15, Eduardo Munoz wrote: > In a ia32 system compiled and run fxract .c program (it is one of the > testcases in valgrind 3.1.0) . It passed in valgrind 2.1.0. > Is it a bug in valgrind?? Yes it is. I only noticed it earlier this week; it does not always appear on x86 platforms, for reasons I don't understand. I fixed it with vex revision 1569. J |
|
From: Dennis L. <pla...@in...> - 2006-02-08 17:33:44
|
Am Mittwoch, den 08.02.2006, 11:02 -0600 schrieb Eduardo Munoz: > The same test passed in valgrind-2.1.0. Since "int" is a common x86 > instruction, It isnt common on x86 Linux, and valgrind was written mainly for Linux. Under Linux only the syscall int 80 is used for anything, and following the "implementation on demand" policy of valgrind it has not been implemented. > it should be supported by valgrind's VEX instruction translation > layer. Id disagree. Running your example program should probably segfault anyways. greets Dennis |
|
From: Eduardo M. <ea...@us...> - 2006-02-08 17:15:32
|
In a ia32 system compiled and run fxract .c program (it is one of the=20
testcases in valgrind 3.1.0) . It passed in valgrind 2.1.0.
Is it a bug in valgrind?? Please advice.
x1-ia32:~ # valgrind --tool=3Dnone ./fxtract
=3D=3D7149=3D=3D Nulgrind, a binary JIT-compiler.
=3D=3D7149=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nether=
cote.
=3D=3D7149=3D=3D Using LibVEX rev 1471, a library for dynamic binary transl=
ation.
=3D=3D7149=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
=3D=3D7149=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation fra=
mework.
=3D=3D7149=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D7149=3D=3D For more details, rerun with: -v
=3D=3D7149=3D=3D
-2.8104666125e+02 -> -73674695.9668238163 0.0000000000
-2.6690452563e+02 -> -69967419.9658766091 0.0000000000
-2.5276239000e+02 -> -132520287.9298588037 0.0000000000
-2.3862025438e+02 -> -125105735.9279643893 0.0000000000
-2.2447811876e+02 -> -117691183.9260699749 0.0000000000
-2.1033598313e+02 -> -110276631.9241755605 0.0000000000
-1.9619384751e+02 -> -102862079.9222811610 0.0000000000
-1.8205171188e+02 -> -95447527.9203867465 0.0000000000
-1.6790957626e+02 -> -88032975.9184923470 0.0000000000
-1.5376744064e+02 -> -80618423.9165979326 0.0000000000
-1.3962530501e+02 -> -73203871.9147035182 0.0000000000
-1.2548316939e+02 -> -131578639.8256182224 0.0000000000
-1.1134103377e+02 -> -116749535.8218293935 0.0000000000
-9.7198898142e+01 -> -101920431.8180405796 0.0000000000
-8.3056762518e+01 -> -87091327.8142517507 0.0000000000
-6.8914626894e+01 -> -72262223.8104629219 0.0000000000
-5.4772491271e+01 -> -114866239.6133482009 0.0000000000
-4.0630355647e+01 -> -85208031.6057705730 0.0000000000
-2.6488220023e+01 -> -111099647.1963858604 0.0000000000
-1.2346084400e+01 -> -103566462.3624611348 0.0000000000
1.7960512242e+00 -> 120530957.3427955508 0.0000000000
1.5938186848e+01 -> 133699201.6981600076 0.0000000000
3.0080322472e+01 -> 126166016.8642352968 0.0000000000
4.4222458095e+01 -> 92741216.4396952838 0.0000000000
5.8364593719e+01 -> 122399424.4472729415 0.0000000000
7.2506729343e+01 -> 76028816.2274252921 0.0000000000
8.6648864967e+01 -> 90857920.2312141210 0.0000000000
1.0079100059e+02 -> 105687024.2350029349 0.0000000000
1.1493313621e+02 -> 120516128.2387917489 0.0000000000
1.2907527184e+02 -> 67672616.1212902814 0.0000000000
1.4321740746e+02 -> 75087168.1231846958 0.0000000000
1.5735954309e+02 -> 82501720.1250791103 0.0000000000
1.7150167871e+02 -> 89916272.1269735247 0.0000000000
1.8564381433e+02 -> 97330824.1288679391 0.0000000000
1.9978594996e+02 -> 104745376.1307623535 0.0000000000
2.1392808558e+02 -> 112159928.1326567680 0.0000000000
2.2807022120e+02 -> 119574480.1345511675 0.0000000000
2.4221235683e+02 -> 126989032.1364455819 0.0000000000
2.5635449245e+02 -> 67201792.0691699982 0.0000000000
2.7049662808e+02 -> 70909068.0701172054 0.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
inf -> inf inf
nan -> nan nan
7.2124891681e-308 -> 108765368.1321834326 0.0000000000
5.7982756057e-308 -> 87438825.3611670583 0.0000000000
4.3840620434e-308 -> 132224565.1803014129 0.0000000000
2.9698484810e-308 -> 89571479.6382687092 0.0000000000
1.5556349186e-308 -> 93836788.1924719810 0.0000000000
1.2727922061e-308 -> 76775553.9756588936 0.0000000000
9.8994949366e-309 -> 119428639.5176916122 0.0000000000
8.4852813742e-309 -> 102367405.3008785248 0.0000000000
7.0710678119e-309 -> 85306171.0840654373 0.0000000000
5.6568542495e-309 -> 68244936.8672522902 0.0000000000
4.2426406871e-309 -> 102367405.3008785248 0.0000000000
1.4142135624e-309 -> 68244936.8672523499 0.0000000000
1.8384182682e-320 -> 121929728.0000000000 0.0000000000
1.8379242025e-321 -> 97517568.0000000000 0.0000000000
1.8280428896e-322 -> 77594624.0000000000 0.0000000000
1.9762625834e-323 -> 67108864.0000000000 0.0000000000
1.4821969375e-323 -> 100663296.0000000000 0.0000000000
4.9406564584e-324 -> 67108864.0000000000 0.0000000000
4.9406564584e-324 -> 67108864.0000000000 0.0000000000
4.9406564584e-324 -> 67108864.0000000000 0.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
0.0000000000e+00 -> 0.0000000000 -inf
2.8104666125e+02 -> 73674695.9668238163 0.0000000000
2.6690452563e+02 -> 69967419.9658766091 0.0000000000
2.5276239000e+02 -> 132520287.9298588037 0.0000000000
2.3862025438e+02 -> 125105735.9279643893 0.0000000000
2.2447811876e+02 -> 117691183.9260699749 0.0000000000
2.1033598313e+02 -> 110276631.9241755605 0.0000000000
1.9619384751e+02 -> 102862079.9222811610 0.0000000000
1.8205171188e+02 -> 95447527.9203867465 0.0000000000
1.6790957626e+02 -> 88032975.9184923470 0.0000000000
1.5376744064e+02 -> 80618423.9165979326 0.0000000000
1.3962530501e+02 -> 73203871.9147035182 0.0000000000
1.2548316939e+02 -> 131578639.8256182224 0.0000000000
1.1134103377e+02 -> 116749535.8218293935 0.0000000000
9.7198898142e+01 -> 101920431.8180405796 0.0000000000
8.3056762518e+01 -> 87091327.8142517507 0.0000000000
6.8914626894e+01 -> 72262223.8104629219 0.0000000000
5.4772491271e+01 -> 114866239.6133482009 0.0000000000
4.0630355647e+01 -> 85208031.6057705730 0.0000000000
2.6488220023e+01 -> 111099647.1963858604 0.0000000000
1.2346084400e+01 -> 103566462.3624611348 0.0000000000
-1.7960512242e+00 -> -120530957.3427955508 0.0000000000
-1.5938186848e+01 -> -133699201.6981600076 0.0000000000
-3.0080322472e+01 -> -126166016.8642352968 0.0000000000
-4.4222458095e+01 -> -92741216.4396952838 0.0000000000
-5.8364593719e+01 -> -122399424.4472729415 0.0000000000
-7.2506729343e+01 -> -76028816.2274252921 0.0000000000
-8.6648864967e+01 -> -90857920.2312141210 0.0000000000
-1.0079100059e+02 -> -105687024.2350029349 0.0000000000
-1.1493313621e+02 -> -120516128.2387917489 0.0000000000
-1.2907527184e+02 -> -67672616.1212902814 0.0000000000
-1.4321740746e+02 -> -75087168.1231846958 0.0000000000
-1.5735954309e+02 -> -82501720.1250791103 0.0000000000
-1.7150167871e+02 -> -89916272.1269735247 0.0000000000
-1.8564381433e+02 -> -97330824.1288679391 0.0000000000
-1.9978594996e+02 -> -104745376.1307623535 0.0000000000
-2.1392808558e+02 -> -112159928.1326567680 0.0000000000
-2.2807022120e+02 -> -119574480.1345511675 0.0000000000
-2.4221235683e+02 -> -126989032.1364455819 0.0000000000
-2.5635449245e+02 -> -67201792.0691699982 0.0000000000
-2.7049662808e+02 -> -70909068.0701172054 0.0000000000
-0.0000000000e+00 -> -0.0000000000 -inf
nan -> nan nan
-7.2124891681e-308 -> -108765368.1321834326 0.0000000000
-5.7982756057e-308 -> -87438825.3611670583 0.0000000000
-4.3840620434e-308 -> -132224565.1803014129 0.0000000000
-2.9698484810e-308 -> -89571479.6382687092 0.0000000000
-1.5556349186e-308 -> -93836788.1924719810 0.0000000000
-1.2727922061e-308 -> -76775553.9756588936 0.0000000000
-9.8994949366e-309 -> -119428639.5176916122 0.0000000000
-8.4852813742e-309 -> -102367405.3008785248 0.0000000000
-7.0710678119e-309 -> -85306171.0840654373 0.0000000000
-5.6568542495e-309 -> -68244936.8672522902 0.0000000000
-4.2426406871e-309 -> -102367405.3008785248 0.0000000000
-1.4142135624e-309 -> -68244936.8672523499 0.0000000000
-1.8384182682e-320 -> -121929728.0000000000 0.0000000000
-1.8379242025e-321 -> -97517568.0000000000 0.0000000000
-1.8280428896e-322 -> -77594624.0000000000 0.0000000000
-1.9762625834e-323 -> -67108864.0000000000 0.0000000000
-1.4821969375e-323 -> -100663296.0000000000 0.0000000000
-4.9406564584e-324 -> -67108864.0000000000 0.0000000000
-4.9406564584e-324 -> -67108864.0000000000 0.0000000000
-4.9406564584e-324 -> -67108864.0000000000 0.0000000000
-0.0000000000e+00 -> -0.0000000000 -inf
-0.0000000000e+00 -> -0.0000000000 -inf
=3D=3D7149=3D=3D
x1-ia32:~ #
Regards,
Eduardo A. Mu=F1oz
|
|
From: Tom H. <to...@co...> - 2006-02-08 17:14:29
|
In message <OFB...@us...>
Eduardo Munoz <ea...@us...> wrote:
> In a IA32 machine, write and compile the following test program:
> ~~~~~
> #include <stdlib.h>
> int main(int argc, char **argv)
> {
> asm ("int $129");
> exit(0);
> }
> ~~~~~
What are you trying to achieve? Only int 0x80 normally does anything
much on an x86 linux system I thought?
> The same test passed in valgrind-2.1.0. Since "int" is a common x86
> instruction, it should be supported by valgrind's VEX instruction
> translation layer.
Only int 0x80 is common under linux, and that is supported.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eduardo M. <ea...@us...> - 2006-02-08 17:00:59
|
I am getting the following problem:
In a IA32 machine, write and compile the following test program:
~~~~~
#include <stdlib.h>
int main(int argc, char **argv)
{
asm ("int $129");
exit(0);
}
~~~~~
Run the above program in valgrind-3.1.0 with tool none, valgrind has error
outputs: vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0x83 0xEC
~~~~~
#:~/valgrind-3.1.0/none/tests/x86 # valgrind --tool=3Dnone ./int
=3D=3D3752=3D=3D Nulgrind, a binary JIT-compiler.
=3D=3D3752=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nether=
cote.
=3D=3D3752=3D=3D Using LibVEX rev 1471, a library for dynamic binary transl=
ation.
=3D=3D3752=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
=3D=3D3752=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation fra=
mework.
=3D=3D3752=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D3752=3D=3D For more details, rerun with: -v
=3D=3D3752=3D=3D
vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0x83 0xEC
=3D=3D3752=3D=3D Your program just tried to execute an instruction that Val=
grind
=3D=3D3752=3D=3D did not recognise. There are two possible reasons for thi=
s.
=3D=3D3752=3D=3D 1. Your program has a bug and erroneously jumped to a non-=
code
=3D=3D3752=3D=3D location. If you are running Memcheck and you just saw=
a
=3D=3D3752=3D=3D warning about a bad jump, it's probably your program's =
fault.
=3D=3D3752=3D=3D 2. The instruction is legitimate but Valgrind doesn't hand=
le it,
=3D=3D3752=3D=3D i.e. it's Valgrind's fault. If you think this is the c=
ase or
=3D=3D3752=3D=3D you are not sure, please let us know.
=3D=3D3752=3D=3D Either way, Valgrind will now raise a SIGILL signal which =
will
=3D=3D3752=3D=3D probably kill your program.
=3D=3D3752=3D=3D
=3D=3D3752=3D=3D Process terminating with default action of signal 4 (SIGIL=
L)
=3D=3D3752=3D=3D Illegal opcode at address 0x80483A8
=3D=3D3752=3D=3D at 0x80483A8: main (int.c:5)
=3D=3D3752=3D=3D
Illegal instruction
~~~~~
Expected results from valgrind:=20
Process terminating with default action of signal 11 (SIGSEGV)
GPF (Pointer out of bounds?)
at 0x........: main (int.c:5)
The same test passed in valgrind-2.1.0. Since "int" is a common x86=20
instruction,
it should be supported by valgrind's VEX instruction translation layer.
Any ideas????
Regards,
Eduardo A. Mu=F1oz
|
|
From: Karim B. <kar...@gm...> - 2006-02-08 16:36:58
|
Hi I have a (big) code we run on a cluster and which runs ok almost everywhere. The cluster is made of 2 types of computers with the same operating system (linux). For one type, no problems but for the other it fails with : ToolSvc.myBTagTool inserting: SV1Tag to tools list. TH1.Print Name = N2TEffSV2, Entries= 195322, Total sum= 195286 TH1.Print Name = N2TNormSV2, Entries= 291102, Total sum= 287128 TH1.Print Name = N2TEffSV2, Entries= 8513, Total sum= 8512 TH1.Print Name = N2TNormSV2, Entries= 417022, Total sum= 354695 TH1.Print Name = TridimMEN2T, Entries= 195322, Total sum= 195247 ==4122== ==4122== Invalid write of size 1 ==4122== at 0x3E5B22FB: Analysis::HistoHelperRoot::smoothASH3D(TH3*, int, int, int, bool) (in /home/atlassgm/releases/rel_11/dist/11.0.4/PhysicsAnalysis/JetTagging/JetTagTools/JetTagTools-00-02-11/i686-slc3-gcc323-opt/libJetTagToolsLib.so) ==4122== Address 0x9C1A0DFF is on thread 1's stack ==4122== Stack overflow in thread 1: can't grow stack to 0x9C1A0DFF ==4122== Can't extend stack to 0x9C1A09D0 during signal delivery for thread 1: ==4122== no stack segment ==4122== ==4122== Process terminating with default action of signal 11 (SIGSEGV) ==4122== Access not within mapped region at address 0x9C1A09D0 ==4122== at 0x3E5B22FB: Analysis::HistoHelperRoot::smoothASH3D(TH3*, int, int, int, bool) (in /home/atlassgm/releases/rel_11/dist/11.0.4/PhysicsAnalysis/JetTagging/JetTagTools/JetTagTools-00-02-11/i686-slc3-gcc323-opt/libJetTagToolsLib.so) ==4122== Stack overflow in thread 1: can't grow stack to 0x9C1A0CDC ==4122== ==4122== Process terminating with default action of signal 11 (SIGSEGV) ==4122== Access not within mapped region at address 0x9C1A0CDC ==4122== at 0x34145998: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:51) ==4122== Thanks for any advice to understand what is wrong ... Karim. |
|
From: <kei...@te...> - 2006-02-08 01:47:38
|
Hi, Thanks for the rapid reply and sorry for not replying soon. Getting the application started by the shell wrapper partly does what=20 I wanted to do. Though, this way of tracing a target process is required = to modify or create the source code which calls the target executables. So, I wonder if we can trace the target process without having to = change any source code of the applications and their callers. One way that I = think=20 is possible (not sure if it's a correct way) is to implement a feature = which detects a target process and runs valgrind on it with the following options: --tool=3Dnone --quiet --num-callers=3D0 --smc-check=3Dnone=20 What do you think? Cheers, Keishi Sonoda -----Original Message----- From: Paul Pluzhnikov [mailto:ppl...@gm...]=20 Sent: Friday, February 03, 2006 12:46 PM To: TELST ECC SONODA KEISHI Cc: val...@li... Subject: Re: [Valgrind-users] tracing child processes On 2/2/06, kei...@te... <kei...@te...> wrote: > > So, I guess we would be happier if valgrind can trace one specific=20 > process that we are interested in. One way that I have dealt with this: # assume foo is the specific binary of interest, and is exec()ed # by = some other binary. mv foo foo.exe cat > foo <<"EOF" #!/bin/sh exec valgrind <VG-options, if any> foo.exe "$@" EOF chmod +x foo If the processes all run the same executable, the same shell wrapper = could be extended to trigger VG execution depending on command line = arguments, environment variables, etc. Cheers, |
|
From: Tom H. <to...@co...> - 2006-02-07 17:08:46
|
In message <f7f...@ma...>
Andy Davis <and...@gm...> wrote:
> My code is doing a long jump to execute a dynamic syscall in an area of
> memory mapped into the processes address space by a kernel lib for dynamic
> syscalls. The instruction for this long jump (see below) appears to not be
> handled by valgrind 3.1.0.
>
> unhandled instruction bytes: 0xEA 0xCD 0x0 0xFF
>
> Can anyone confirm that this instruction is not handled? Also, will it be
> handled in a future release?
Well clearly it isn't handled or you wouldn't get that error. It is
a far JMP instruction which is a pretty weird thing to see with a
modern operating system outside the kernel.
Why are you using that instruction? Are you trying to switch to a
different code segment? or is the target a call gate or task gate?
Either way I suspect it will be rather hard to support this.
What is a "dynamic syscall" anyway? What is a kernel lib come to that?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: smiley g. <smi...@ya...> - 2006-02-07 09:46:56
|
Hello, An Uninitialized variable used in many places makes memcheck print an error for each location of the read. With a complex application with many errors this becomes too cumbersome as I end up having 2 or more different stack traces for the same source variable (same problem). Is there a way by which I can set the variable as defined after firing the first error for uninitialized read. This way I have the first read thats usually closest to the source of the error. Thanks, Smile. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Clara C. <alw...@mo...> - 2006-02-06 16:58:09
|
SHORT AND SWEET The key to making serious money through investing is not to follow the crowd. Make no mistake: Our mission at SmallCap-Investors is to claw our way through the thousands of underperforming companies out there to find the golden needle in the haystack the micro-cap DIAMOND that can make you r i c h. More often than not, the stocks we profile show a significant increase in stock price and sometimes in days, not months or years. We have come across what we feel is one of those rear deals that the public has not heard about yet. Investment Times Alert: S T R O N G Harbin Pingchuan Pharmaceutical: P G C N Current Price: $1.19 Thursday Feb 2rd Close: $1.05 - UP 0.14 (13.33%) Shares Outstanding: 20 Million Market Capitalization: $6 Million Short Term Target: $2.25 12month Target: $8 Remember the gains from our recent "S t r o n g B u y" recommendations... It is only a matter of time before it is released out into the investment community and they take it to the moon. TRADING SYMBOL: P G C N Put it on your screen now !!! The key to making serious money through investing is not to follow the crowd. This is a MUST Watch for all Investors Monday February 6th. |
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-02-05 05:30:40
|
I'm doing a project on virtual memory, and decided to use Valgrind to help
me track the memory references made by a program. I added a little to
what Nick did with Lackey. Basically, whenever I do an instruction
fetch, a read or a write, I call the relevant functions below.
static VG_REGPARM(1) void trace_ins_read(Addr addr)
{
VG_(printf)("i %p\n", addr);
}
static VG_REGPARM(1) void trace_load(Addr addr)
{
VG_(printf)("r %p %d\n", addr, VG_(seginfo_sect_kind)(addr));
}
static VG_REGPARM(1) void trace_store(Addr addr)
{
VG_(printf)("w %p %d\n", addr, VG_(seginfo_sect_kind)(addr));
}
I'm puzzled because I cannot explain some of the details of the trace I
collect. Here is some of the output:
i 0x458008
w 0x45F278 0
r 0xFDF1E90C 0
r 0x45B7A4 1
r 0x43253DC 2
r 0x584D4C 2
w 0x586058 3
In case you're not well acquainted with VG_(seginfo_sect_kind), 0 means
unknown, 1 means text, 2 means data, 3 means BSS.
(1) Why does a program read from the text part?
(2) Why is "w 0x45F278 0" unknown, if it is between the text and BSS?
Shouldn't it be data?
(3) Why is "r 0x43253DC 2" in the data region? I thought the data region
is between the text and BSS, but it appears that the data region is a lot
higher than the BSS! The other data read "r 0x584D4C 2" seems to be the
real data region. Is there an error in VG_(seginfo_sect_kind)?
Thanks in advance for any help!
Zac
|
|
From: Beorn J. <beo...@ya...> - 2006-02-05 05:09:55
|
Hello,
Recently someone added some code to a project which uses
'pthread_kill', which in turn uses the 'tkill' system call.
This resulted in the "README_MISSING_SYSCALL_OR_IOCTL" error message,
which I did, and as I dug into the matter further, I found in
valgrind-3.1.0/coregrind/m_syswrap/syswrap-linux.c (including the '//zz's):
//zz PRE(sys_tkill, Special)
//zz {
//zz /* int tkill(pid_t tid, int sig); */
//zz PRINT("sys_tkill ( %d, %d )", ARG1,ARG2);
//zz PRE_REG_READ2(long, "tkill", int, tid, int, sig);
//zz if (!ML_(client_signal_OK)(ARG2)) {
//zz SET_STATUS_( -VKI_EINVAL );
//zz return;
//zz }
//zz
//zz /* If we're sending SIGKILL, check to see if the target is one of
//zz our threads and handle it specially. */
//zz if (ARG2 == VKI_SIGKILL && ML_(do_sigkill)(ARG1, -1))
//zz SET_STATUS_(0);
//zz else
//zz SET_STATUS_(VG_(do_syscall2)(SYSNO, ARG1, ARG2));
//zz
//zz if (VG_(clo_trace_signals))
//zz VG_(message)(Vg_DebugMsg, "tkill: sent signal %d to pid %d",
//zz ARG2, ARG1);
//zz // Check to see if this kill gave us a pending signal
//zz XXX FIXME VG_(poll_signals)(tid);
//zz }
So, it seems there are some subtleties here that aren't obvious.
The same thing appears in the svn version.
Anyone have any suggestions as to how to proceed?
Thanks,
Beorn Johnson
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Igmar P. <mai...@jd...> - 2006-02-04 19:26:34
|
> I am doing a cross build of valgrind from i686 to ppc no floating point > system (440 boards). Kernel is a 2.6.5.xxxx from SLES 9 SP2 > I am using the latest valgrind code from the trunk, I got the code using > the following command: And you'r *sure* that your crossbuild environment isn't broken ? Is this a native gcc + libc combination, or is this also build on x86 ? Looks to me your cross gcc compiles bogus / non-working code. > (gdb) r > Starting program: /mytest Someone might want to take a look at the assembler generated bu this specific compiler vs a native build 0ppc32 compiler . To me it looks like it's broken. Igmar |
|
From: Andy D. <and...@gm...> - 2006-02-04 00:38:15
|
My code is doing a long jump to execute a dynamic syscall in an area of memory mapped into the processes address space by a kernel lib for dynamic syscalls. The instruction for this long jump (see below) appears to not be handled by valgrind 3.1.0. unhandled instruction bytes: 0xEA 0xCD 0x0 0xFF Can anyone confirm that this instruction is not handled? Also, will it be handled in a future release? thanks -andy |