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
|
2
|
3
|
|
4
(1) |
5
(6) |
6
(8) |
7
(3) |
8
(1) |
9
|
10
|
|
11
(2) |
12
|
13
(3) |
14
(18) |
15
(1) |
16
(16) |
17
(5) |
|
18
(3) |
19
(4) |
20
(3) |
21
(3) |
22
(7) |
23
(2) |
24
|
|
25
|
26
|
27
(2) |
28
(6) |
29
(7) |
30
(3) |
31
(2) |
|
From: Tom H. <to...@co...> - 2008-05-14 08:33:23
|
In message <e2e...@ma...>
Bart Van Assche <bar...@gm...> wrote:
> On Wed, May 14, 2008 at 10:13 AM, Erik de Castro Lopo
> <eri...@me...> wrote:
>> Christoph Bartoschek wrote:
>>> 2. Uninitialized memory does not help for randomness but it also does not
>>> hurt.
>>
>> True.
>
> If uninitialized memory does not help for randomness, why was leaving
> out uninitialized memory as a randomness source considered to be a
> security hole ? See also http://lwn.net/Articles/281901/.
It wasn't, but they also took out another (identical) line of code
that was actually adding genuine random (and initialised) data at
the same time.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bart V. A. <bar...@gm...> - 2008-05-14 08:27:09
|
On Wed, May 14, 2008 at 10:13 AM, Erik de Castro Lopo <eri...@me...> wrote: > Christoph Bartoschek wrote: >> 2. Uninitialized memory does not help for randomness but it also does not >> hurt. > > True. If uninitialized memory does not help for randomness, why was leaving out uninitialized memory as a randomness source considered to be a security hole ? See also http://lwn.net/Articles/281901/. Bart. |
|
From: Erik de C. L. <eri...@me...> - 2008-05-14 08:13:33
|
Christoph Bartoschek wrote: > The OpenSSL authors do the right thing: I disagree. Openssl is a prime example of a library which was poorly designed, a long time ago and has been badly maintained since. Its a pity that this is the most widely used SSL library available under a free license. > 1. They do not depend on the memory randomness. True. > It is just an additional > source to many other real random sources. Randomness of such poor quality that it may as well all be zero bytes. > 2. Uninitialized memory does not help for randomness but it also does not > hurt. True. > 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of > uninitialized memory. This *only* works if you compile openssl yourself, from source. If I link my program against the openssl that comes with my Linux distribution and run it under valgrind I get errors from openssl. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "He who writes the code gets to choose his license, and nobody else gets to complain" -- Linus Torvalds |
|
From: Julian S. <js...@ac...> - 2008-05-14 07:55:11
|
> 2. Uninitialized memory does not help for randomness but it also does not > hurt. If you say it does not help for randomness, why then use it? > 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of > uninitialized memory. This should pacify valgrind for all people that have > to debug their applications. True, but it has the bad effect that you need to recompile OpenSSL in order to use Memcheck on any applications which use it. This is extra hassle for programmers and packagers. At least with the new --track-origins=yes facility in V 3.4.0 it will be easy to find out which uninitialised value errors are as a result of OpenSSL using uninitialised memory. J |
|
From: Christoph B. <bar...@or...> - 2008-05-14 07:40:47
|
Am Mittwoch, 14. Mai 2008 schrieb Dirk Stoecker: > After I read the rants against Debian, I ask myself why not one of the > OpenSSL authors actually agreed, that taking uninitialised memory is no > good idea (as it is in no way random). They should have replaced that code > long ago by better randomness. The OpenSSL authors do the right thing: 1. They do not depend on the memory randomness. It is just an additional source to many other real random sources. 2. Uninitialized memory does not help for randomness but it also does not hurt. 3. OpenSSL offers a compilation macro (PURIFY) to disable usage of uninitialized memory. This should pacify valgrind for all people that have to debug their applications. Christoph |
|
From: John T. <joh...@bi...> - 2008-05-14 07:22:29
|
I'm trying to profile powerpc applications using valgrind on a powerpc system but can't seem to generate any symbolic information in the callgrind.out.xx file even though I have a full set of binutils installed on the target board. I get the full dump and the information "looks" correct but without symbolic information its of limited use. Not sure if this is connected but if I use Kcachegrind on an x86 box to view the data I get the following error even if I overwrite the x86 objdump with objdump from my cross compilation environment. Assembler There seems to be an error trying to execute the command objdump -C -d --start-address=0x10006E10 --stop-address=0x10175BA8 "" Check that the ELF object used in the command exists Check that you have installed 'objdump' This utility can be found in the 'binutils' package. Any hints/tips as to where valgrind looks for objdump or what else I could do to try and debug this. Cheers. |
|
From: Dirk S. <val...@ds...> - 2008-05-14 07:09:26
|
On Tue, 13 May 2008, Christoph Bartoschek wrote: > I've read about the debian SSL bug. http://wiki.debian.org/SSLkeys > > There they state: > > It is important to understand that this problem was caused by trying to remove > valgrind warnings related to the use of uninitialised memory within the > openssl libraries. > > > Apparently they disabled to many seeds with the patch. Unfortunately origin > tracking comes too late. :) After I read the rants against Debian, I ask myself why not one of the OpenSSL authors actually agreed, that taking uninitialised memory is no good idea (as it is in no way random). They should have replaced that code long ago by better randomness. I really hate these library authors not caring for valgrind and memory checks. So many problems in glib, x-libs and others which make debugging own applications a very hard task. And the result are many memory holes and illegal accesses in all the GUI applications using these libraries (or am I the only one who finds it hard to debug e.g. a Qt/KDE program using valgrind). Reminds me of the Amiga, where program authors used direct ROM calls and other evil things and then blamed the operating system for changing instead seeing problems in their own programming style. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Christoph B. <bar...@or...> - 2008-05-13 21:42:26
|
Hi, I've read about the debian SSL bug. http://wiki.debian.org/SSLkeys There they state: It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. Apparently they disabled to many seeds with the patch. Unfortunately origin tracking comes too late. :) Christoph |
|
From: Bart V. A. <bar...@gm...> - 2008-05-13 17:25:09
|
On Tue, May 13, 2008 at 6:37 AM, pavanks <sud...@gm...> wrote: > > Hi Iam trying to cross compile for ppc-32 on my linux desktop. Hello Pavan, As far as I know currently you can't cross-compile Valgrind -- you have to compile it natively. Bart. |
|
From: pavanks <sud...@gm...> - 2008-05-13 04:37:27
|
Hi Iam trying to cross compile for ppc-32 on my linux desktop.
My machine details are
Linux version 2.4.34 (Red Hat Linux 3.3.2-1)) #1 SMP Thu Jun 28 19:39:26 IST
2007
iam using
valgrind-3.3.0
i did
export CC=/opt/eldk/usr/bin/ppc_82xx-gcc
./configure gives warning
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
make gives the following errors, please help me.
/opt/eldk/usr/bin/ppc_82xx-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include
-I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -O2 -g
-Wmissing-prototypes -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -fno-strict-aliasing -O -g -fpic
-fno-omit-frame-pointer -fno-strict-aliasing -O2 -Wno-long-long -c -o
vgpreload_memcheck_ppc32_linux_so-mc_replace_strmem.o `test -f
'mc_replace_strmem.c' || echo './'`mc_replace_strmem.c
mc_replace_strmem.c: In function `_vgwZU_libcZdsoZa_putenv':
mc_replace_strmem.c:743: unknown register name `xer' in `asm'
mc_replace_strmem.c:745: Internal compiler error:
mc_replace_strmem.c:745: GOT/TOC register marker not removed:
(parallel[
(set (reg:SI 29 r29)
(asm_operands/v ("mr 11,%1
lwz 3,4(11)
lwz 11,0(11)
rlwinm 0,0,3,0,0 ; rlwinm 0,0,13,0,0
rlwinm 0,0,29,0,0 ; rlwinm 0,0,19,0,0
or 3,3,3
mr %0,3") ("=r") 0[
(reg:SI 29 r29)
]
[
(asm_input:SI ("r"))
] ("mc_replace_strmem.c") 743))
(clobber (reg:QI 13 r13))
(clobber (reg:QI 12 r12))
(clobber (reg:QI 11 r11))
(clobber (reg:QI 10 r10))
(clobber (reg:QI 9 r9))
(clobber (reg:QI 8 r8))
(clobber (reg:QI 7 r7))
(clobber (reg:QI 6 r6))
(clobber (reg:QI 5 r5))
(clobber (reg:QI 4 r4))
(clobber (reg:QI 3 r3))
(clobber (reg:QI 2 r2))
(clobber (reg:QI 0 r0))
(clobber (reg:QI 75 cr7))
(clobber (reg:QI 74 cr6))
(clobber (reg:QI 73 cr5))
(clobber (reg:QI 72 cr4))
(clobber (reg:QI 71 cr3))
(clobber (reg:QI 70 cr2))
(clobber (reg:QI 69 cr1))
(clobber (reg:QI 68 cr0))
(clobber (reg:QI 66 ctr))
(clobber (reg:QI 65 lr))
(clobber (mem:BLK (scratch) 0))
(clobber (reg:QI 68 cr0))
] )
make[3]: *** [vgpreload_memcheck_ppc32_linux_so-mc_replace_strmem.o] Error 1
make[3]: Leaving directory
`/home/sudarshan/software/valgrind-3.3.0/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/sudarshan/software/valgrind-3.3.0/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sudarshan/software/valgrind-3.3.0'
make: *** [all] Error 2
regards,
pavan
--
View this message in context: http://www.nabble.com/crosscompile-to-ppc-with-valgrind-3.3.0-tp17143876p17143876.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: Nicholas N. <nj...@cs...> - 2008-05-11 23:00:59
|
On Sun, 11 May 2008, Evan Jones wrote: > I am working on a thread library that maps user space threads to kernel > threads (as provided by pthreads). In order to get my library working > with Valgrind with a single kernel thread, I used > VALGRIND_STACK_REGISTER to register my user space stacks. > > However, with multiple kernel threads, I still get warnings like the > following: > > Warning: client switching stacks? SP change: 0x418461C --> 0x597B28C > > Interestingly, it is complaining when I switch from a user space stack > registered with VALGRIND_STACK_REGISTER back to the pthread stack. I > tried "guessing" at an address range for the pthread stack, and using > VALGRIND_STACK_REGISTER with it, but this caused more problems. > > The *real* problem I am having is that after I get the warnings, > valgrind reports many of "Use of uninitialised value" errors that I > don't believe. Some of the errors refer to variables allocated on the > pthread stacks, which are indeed initialized. > > Is there some way I can tell Valgrind more about what my library is > doing, in order to get it to work? It has been incredibly useful for > debugging. I have a memory of finding some bugs in the stack registering code, but alas I cannot remember them nor find them in my notes. That might be a reason, but it might not. You could try using --max-stackframe as a workaround. Another possibility: you could modify the stack-switch detection heuristic, by assuming that if it's a constant delta that it's an allocation and thus not a stack-switch. Nick |
|
From: Evan J.
|
I am working on a thread library that maps user space threads to kernel threads (as provided by pthreads). In order to get my library working with Valgrind with a single kernel thread, I used VALGRIND_STACK_REGISTER to register my user space stacks. However, with multiple kernel threads, I still get warnings like the following: Warning: client switching stacks? SP change: 0x418461C --> 0x597B28C Interestingly, it is complaining when I switch from a user space stack registered with VALGRIND_STACK_REGISTER back to the pthread stack. I tried "guessing" at an address range for the pthread stack, and using VALGRIND_STACK_REGISTER with it, but this caused more problems. The *real* problem I am having is that after I get the warnings, valgrind reports many of "Use of uninitialised value" errors that I don't believe. Some of the errors refer to variables allocated on the pthread stacks, which are indeed initialized. Is there some way I can tell Valgrind more about what my library is doing, in order to get it to work? It has been incredibly useful for debugging. Thanks for your help, and for the great tool, Evan Jones valgrind 3.3.0 Linux 2.6.24 Debian unstable -- Evan Jones http://evanjones.ca/ |
|
From: Julian S. <js...@ac...> - 2008-05-08 13:48:40
|
Richa, I'm just collecting up bugs to fix (!) I can look at this one if useful. If so it will help if you can send me the /lib/ld-2.5.so from the machine on which you got this error. J On Thursday 03 April 2008 13:29, Gupta Richa wrote: > Hi > I am cross-compiling the valgrind for ppc-32 and I am getting the > following error while using valgrind with my executables. > is_proc_ctl(ppc)(mfspr,SPR)(0x11F) > disInstr(ppc): unhandled instruction: 0x7C1F42A6 > primary 31(0x1F), secondary 678(0x2A6) > ==115== valgrind: Unrecognised instruction at address 0x40144F8. > ==115== Your program just tried to execute an instruction that Valgrind > ==115== did not recognise. There are two possible reasons for this. > ==115== 1. Your program has a bug and erroneously jumped to a non-code > ==115== location. If you are running Memcheck and you just saw a > ==115== warning about a bad jump, it's probably your program's fault. > ==115== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==115== i.e. it's Valgrind's fault. If you think this is the case or > ==115== you are not sure, please let us know and we'll try to fix it. > ==115== Either way, Valgrind will now raise a SIGILL signal which will > ==115== probably kill your program. > ==115== > ==115== Process terminating with default action of signal 4 (SIGILL) > ==115== Illegal opcode at address 0x40144F8 > ==115== at 0x40144F8: _dl_sysdep_start (in /lib/ld-2.5.so) > ==115== by 0x4002344: _dl_start_final (in /lib/ld-2.5.so) > ==115== by 0x4002898: _dl_start (in /lib/ld-2.5.so) > ==115== by 0x4015114: _start (in /lib/ld-2.5.so) > > Attached is the log for the same. Please do tell me what is the mistake. > > Thanks & Regards, > Richa |
|
From: Dirk S. <val...@ds...> - 2008-05-07 14:13:07
|
On Wed, 7 May 2008, Nicholas Nethercote wrote: >> Usually it is better to have an "if(fabs(a-b) < epsilon)" compared to an >> "if(a == b)". > > That is better than pure equality, but still has various pitfalls. See > http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm > for an excellent discussion of this topic, and a very nice implementation of > FP equality. Nice link. Directly went into my bookmarks. Actually till now I never needed anything below "Comparing with epsilon – relative error", but good to know there are possibilites. Thought if I implement these in code, I will be the only one understanding how these work. Usually not a good idea. I usually avoid comparisons with floats whenever possible and stick to integer as long as possible :-) Nowadays, where 64 bit ints are available this works fine most of the time. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Nicholas N. <nj...@cs...> - 2008-05-07 07:16:49
|
On Tue, 6 May 2008, Dara O'Brien wrote: > Can I use Massif for studying heap fragmentation? I'm > guessing no since it has it has its own malloc etc. but > would welcome the confirmation... Correct, it only considers the amount of memory allocated, not where it goes. Nick |
|
From: Nicholas N. <nj...@cs...> - 2008-05-07 07:14:50
|
On Tue, 6 May 2008, Dirk Stoecker wrote: > Usually it is better to have an "if(fabs(a-b) < epsilon)" compared to an > "if(a == b)". That is better than pure equality, but still has various pitfalls. See http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm for an excellent discussion of this topic, and a very nice implementation of FP equality. Nick |
|
From: Paul W. <pa...@bl...> - 2008-05-06 21:29:13
|
Hi Federico, > Do you remember the bug where the multimedia opcodes were no recognized by > Valgrind? Is there an estimated date for a new version? If you want to make sure the bug doesn't get forgotten, the best thing is to file a bug - http://bugs.kde.org/enter_valgrind_bug.cgi Cheers, -- Paul Some days you are the bug, some days you are the windshield. |
|
From: Dirk S. <val...@ds...> - 2008-05-06 15:10:19
|
Hello, > As i don't need 80bit precision, I guess i'll get by with > some appropriate floating point tricks such as addin small > values and rounding.... If you want to write portable applications this is anyway required. Many floating point using applications fail mysteriously, when compiled with different compiler options, on different systems and so on, when you do not care for such things. Usually it is better to have an "if(fabs(a-b) < epsilon)" compared to an "if(a == b)". This will save you a lot of debugging trouble later on. Always remember that floating point is an approximation when writing value tests. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: Dallman, J. <joh...@si...> - 2008-05-06 13:10:36
|
You'll do better to run your app with 64-bit precision throughout, even when it isn't running under valgrind. fpu_control.h has the constants and functions you'll need to do that. -- John Dallman Parasolid Porting Engineer > -----Original Message----- > From: val...@li... [mailto:valgrind- > use...@li...] On Behalf Of jody > Sent: Tuesday, May 06, 2008 1:41 PM > To: Michael Poole > Cc: val...@li... > Subject: Re: [Valgrind-users] precision problem > > Thanks for the info! > As i don't need 80bit precision, I guess i'll get by with > some appropriate floating point tricks such as addin small > values and rounding.... > > Jody > On Tue, May 6, 2008 at 1:53 PM, Michael Poole <md...@tr...> > wrote: > > jody writes: > > > > > Hi > > > I'm using valgrind-3.2.1 on fedora 6. > > > > > > I have encounter a situation where computations with doubles > > > give different result when the application is run normally or > under valgrind. > > > > > > > > > > > > Here is a very simple application showing the problem, vgt.c: > > > > Your test program behaves differently based on the implementation of > > "double". In particular, the 1950 result depends on the > intermediate > > results being calculated using 80-bit floats, as is traditional on > the > > stack of x86 FPUs. If the compiled code uses 64-bit floats, which > > will happen on x86-64 (and most other) machines, if you use gcc's > > -ffloat-store flag on x86 machines, or if you use Valgrind, it > > produces the 1949 result. > > > > According to http://valgrind.org/help/projects.html, the Vex library > > that underlies Valgrind only supports 64-bit floating-point > > arithmetic, so there is probably no way to get the 80-bit results > > within Valgrind. > > > > Michael Poole > > > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ > javaone > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: jody <jod...@gm...> - 2008-05-06 12:41:09
|
Thanks for the info! As i don't need 80bit precision, I guess i'll get by with some appropriate floating point tricks such as addin small values and rounding.... Jody On Tue, May 6, 2008 at 1:53 PM, Michael Poole <md...@tr...> wrote: > jody writes: > > > Hi > > I'm using valgrind-3.2.1 on fedora 6. > > > > I have encounter a situation where computations with doubles > > give different result when the application is run normally or under valgrind. > > > > > > > > Here is a very simple application showing the problem, vgt.c: > > Your test program behaves differently based on the implementation of > "double". In particular, the 1950 result depends on the intermediate > results being calculated using 80-bit floats, as is traditional on the > stack of x86 FPUs. If the compiled code uses 64-bit floats, which > will happen on x86-64 (and most other) machines, if you use gcc's > -ffloat-store flag on x86 machines, or if you use Valgrind, it > produces the 1949 result. > > According to http://valgrind.org/help/projects.html, the Vex library > that underlies Valgrind only supports 64-bit floating-point > arithmetic, so there is probably no way to get the 80-bit results > within Valgrind. > > Michael Poole > |
|
From: Dara O'B. <pad...@gm...> - 2008-05-06 12:02:06
|
Hi, Can I use Massif for studying heap fragmentation? I'm guessing no since it has it has its own malloc etc. but would welcome the confirmation... Thanks, Dara |
|
From: Michael P. <md...@tr...> - 2008-05-06 11:53:35
|
jody writes: > Hi > I'm using valgrind-3.2.1 on fedora 6. > > I have encounter a situation where computations with doubles > give different result when the application is run normally or under valgrind. > > > > Here is a very simple application showing the problem, vgt.c: Your test program behaves differently based on the implementation of "double". In particular, the 1950 result depends on the intermediate results being calculated using 80-bit floats, as is traditional on the stack of x86 FPUs. If the compiled code uses 64-bit floats, which will happen on x86-64 (and most other) machines, if you use gcc's -ffloat-store flag on x86 machines, or if you use Valgrind, it produces the 1949 result. According to http://valgrind.org/help/projects.html, the Vex library that underlies Valgrind only supports 64-bit floating-point arithmetic, so there is probably no way to get the 80-bit results within Valgrind. Michael Poole |
|
From: Julian S. <js...@ac...> - 2008-05-06 11:42:20
|
On Tuesday 06 May 2008 13:33, jody wrote: > Hi > I'm using valgrind-3.2.1 on fedora 6. > > I have encounter a situation where computations with doubles > give different result when the application is run normally or under > valgrind. Yes. See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits, 8th bullet point. J > > > > Here is a very simple application showing the problem, vgt.c: > > #include <stdio.h> > #include <math.h> > > > int main(int argc, char *argv) { > > > double a; > double b; > double c; > FILE *f = fopen("num.dat", "rb"); > fread(&a, sizeof(double), 1, f); > fread(&b, sizeof(double), 1, f); > fread(&c, sizeof(double), 1, f); > fclose(f); > > printf("a:%.20f, b:%.20f, c:%.20f\n", a,b,c); > printf("a-b:%.20f, (a-b)/c:%.20f\n", a-b,(a-b)/c); > double d = (a-b)/c; > printf("%.20f\n", floor(d)); > return 0; > } > > Here is the hexdump of the data file num.dat: > [jody]:~/progs/neander/import:$hexdump -C num.dat > 00000000 a9 9a fe ff ff ff 48 40 00 00 00 00 00 00 2e c0 > |......H@........| 00000010 6b 55 10 11 11 11 a1 3f > |kU.....?| 00000018 > > The normal output: > [jody]:~/progs/neander/import:$./vgt > a:49.99999999935000261075, b:-15.00000000000000000000, > c:0.03333333333300000229 a-b:64.99999999934999550533, > (a-b)/c:1950.00000000000000000000 > 1950.00000000000000000000 > > Output under valgrind: > [jody]:~/progs/neander/import:$valgrind --tool=memcheck ./vgt > ==23277== Memcheck, a memory error detector. > ==23277== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==23277== Using LibVEX rev 1658, a library for dynamic binary translation. > ==23277== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==23277== Using valgrind-3.2.1, a dynamic binary instrumentation framework. > ==23277== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==23277== For more details, rerun with: -v > ==23277== > a:49.99999999935000261075, b:-15.00000000000000000000, > c:0.03333333333300000229 a-b:64.99999999934999550533, > (a-b)/c:1949.99999999999977262632 > 1949.00000000000000000000 > ==23277== > ==23277== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) > ==23277== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==23277== malloc/free: 1 allocs, 1 frees, 352 bytes allocated. > ==23277== For counts of detected errors, rerun with: -v > ==23277== All heap blocks were freed -- no leaks are possible. > > > It is important that both calculations (normal & valgrind) are the same - > with the faulty calculation my real program never gets to the point i am > interested in. > > Is this a bug or did i overlook something? > > Thanks > jody > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java >one _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: jody <jod...@gm...> - 2008-05-06 11:33:37
|
Hi
I'm using valgrind-3.2.1 on fedora 6.
I have encounter a situation where computations with doubles
give different result when the application is run normally or under valgrind.
Here is a very simple application showing the problem, vgt.c:
#include <stdio.h>
#include <math.h>
int main(int argc, char *argv) {
double a;
double b;
double c;
FILE *f = fopen("num.dat", "rb");
fread(&a, sizeof(double), 1, f);
fread(&b, sizeof(double), 1, f);
fread(&c, sizeof(double), 1, f);
fclose(f);
printf("a:%.20f, b:%.20f, c:%.20f\n", a,b,c);
printf("a-b:%.20f, (a-b)/c:%.20f\n", a-b,(a-b)/c);
double d = (a-b)/c;
printf("%.20f\n", floor(d));
return 0;
}
Here is the hexdump of the data file num.dat:
[jody]:~/progs/neander/import:$hexdump -C num.dat
00000000 a9 9a fe ff ff ff 48 40 00 00 00 00 00 00 2e c0 |......H@........|
00000010 6b 55 10 11 11 11 a1 3f |kU.....?|
00000018
The normal output:
[jody]:~/progs/neander/import:$./vgt
a:49.99999999935000261075, b:-15.00000000000000000000, c:0.03333333333300000229
a-b:64.99999999934999550533, (a-b)/c:1950.00000000000000000000
1950.00000000000000000000
Output under valgrind:
[jody]:~/progs/neander/import:$valgrind --tool=memcheck ./vgt
==23277== Memcheck, a memory error detector.
==23277== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==23277== Using LibVEX rev 1658, a library for dynamic binary translation.
==23277== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==23277== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==23277== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==23277== For more details, rerun with: -v
==23277==
a:49.99999999935000261075, b:-15.00000000000000000000, c:0.03333333333300000229
a-b:64.99999999934999550533, (a-b)/c:1949.99999999999977262632
1949.00000000000000000000
==23277==
==23277== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==23277== malloc/free: in use at exit: 0 bytes in 0 blocks.
==23277== malloc/free: 1 allocs, 1 frees, 352 bytes allocated.
==23277== For counts of detected errors, rerun with: -v
==23277== All heap blocks were freed -- no leaks are possible.
It is important that both calculations (normal & valgrind) are the same -
with the faulty calculation my real program never gets to the point i am
interested in.
Is this a bug or did i overlook something?
Thanks
jody
|
|
From: Borse, G. <gan...@cr...> - 2008-05-05 14:06:42
|
Hi, My application dumps core due to some memory leaks or memory corruption. To investigate this, I am running my application with valgrind using following options, to find out memory leaks & related problems in my application. valgrind -v --leak-check=full --time-stamp=yes --tool=memcheck lcsvrD When my application crashes because of this memory problem, a core is getting generated with name of vgcore.<pid>. This core when I try to view using the gdb on Linux, I do not get any information. My application is compiled with debugging information & is a debug binary. I get only following output: :~/scripts> gdb ../bin/lcsvrD -c vgcore.12429 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x748f488 #0 0x04000972 in ?? () (gdb) where #0 0x04000972 in ?? () Cannot access memory at address 0x1b21a3a0 (gdb) bt #0 0x04000972 in ?? () Cannot access memory at address 0x1b21a3a0 file ./vgcore.12429 ./vgcore.12429: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'lcsvrD' Once strange thing, you can see is that when GDB opens this core, it is not able to determine the binary name from which this core is generated. But file command gives correct binary name. But, the core generated by my application without running with Valgrind can be viewed correctly with GDB. Is there anything extra I need to do here to view this core? Please help. Thanks and Regards, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== |