|
From: John R.
|
Valgrind 2.0.0 (memcheck) complains about a bit that is not uninitialized.
-----jfrtest1.c
int
test1()
{
unsigned x; /* uninitialized */
x &= 0x0000000c; /* possible 0, 4, 8, 12 */
if (2 & (x % 15)) { /* memcheck complains but should not */
return 1;
}
else {
return 0;
}
}
int
main()
{
return test1();
}
-----end jfrtest1.c
$ gcc -g -o jfrtest1 jfrtest1.c
$ valgrind ./jfrtest1
==7084== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==7084== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==7084== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==7084== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==7084== Estimated CPU clock rate is 1619 MHz
==7084== For more details, rerun with: -v
==7084==
==7084== Conditional jump or move depends on uninitialised value(s)
==7084== at 0x8048318: test1 (jfrtest1.c:6)
==7084== by 0x8048343: main (jfrtest1.c:17)
==7084== by 0x40247AB6: __libc_start_main (in /lib/libc-2.3.2.so)
==7084== by 0x8048264: ??? (start.S:81)
$ gdb ./jfrtest1 ## generated assembly code looks OK
(gdb) x/23i test1
0x80482f4 <test1>: push %ebp
0x80482f5 <test1+1>: mov %esp,%ebp
0x80482f7 <test1+3>: sub $0xc,%esp
0x80482fa <test1+6>: lea 0xfffffffc(%ebp),%eax
0x80482fd <test1+9>: andl $0xc,(%eax)
0x8048300 <test1+12>: mov 0xfffffffc(%ebp),%edx
0x8048303 <test1+15>: mov %edx,%eax
0x8048305 <test1+17>: mov $0xf,%ecx
0x804830a <test1+22>: mov $0x0,%edx
0x804830f <test1+27>: div %ecx
0x8048311 <test1+29>: mov %edx,%eax
0x8048313 <test1+31>: and $0x2,%eax
0x8048316 <test1+34>: test %eax,%eax
0x8048318 <test1+36>: je 0x8048323 <test1+47> ## complaint here
0x804831a <test1+38>: movl $0x1,0xfffffff8(%ebp)
0x8048321 <test1+45>: jmp 0x804832a <test1+54>
0x8048323 <test1+47>: movl $0x0,0xfffffff8(%ebp)
0x804832a <test1+54>: mov 0xfffffff8(%ebp),%eax
0x804832d <test1+57>: leave
0x804832e <test1+58>: ret
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
glibc-2.3.2-27.9.6
System is Red Hat 9: 2.4.20-20.9.
--
John Reiser, jreiser@BitWagon.com
|
|
From: Dirk M. <dm...@gm...> - 2003-11-21 00:22:59
|
On Thursday 20 November 2003 22:58, John Reiser wrote: > Valgrind 2.0.0 (memcheck) complains about a bit that is not uninitialized. ok, thats because the div instruction triggered by the (superflous) modulo operation is not tracking the validity of its operants on a bit-wise level. Instead it expects all bits to be initialized and will then track full validity of the result. We *could* implement bitwise-tracking of the modulo operation with relative ease. However, is it really important? |
|
From: John R.
|
Dirk Mueller wrote: > On Thursday 20 November 2003 22:58, John Reiser wrote: > > >>Valgrind 2.0.0 (memcheck) complains about a bit that is not uninitialized. > > > ok, thats because the div instruction triggered by the (superflous) modulo > operation is not tracking the validity of its operants on a bit-wise level. > Instead it expects all bits to be initialized and will then track full > validity of the result. > > We *could* implement bitwise-tracking of the modulo operation with relative > ease. However, is it really important? For serious use it is important to understand when memcheck will complain, amd when it will not. This shows that DIV and REM are exceptions to the rule "complain exactly when an uninit bit affects conditional control flow or I/O." Apparently FPU, MMX, and SSE/SSE2 instructions also are exceptions: they complain on fetch. [Why is MMX AND/OR/XOR/LOAD/STORE different from integer AND/OR/XOR/LOAD/STORE?] Are there any other exceptions? For instance, tracking uninit bits through MUL is much more complicated than through ADD, although not as bad as through DIV/REM. Multiplying by 0x11111111, 0x01010101, 0x01001001, or 0x00010001 does useful things. Could memcheck have problems here? Is there an option to have "integer" instructions complain on fetch instead of "as late as possible?" I find it easier to find and fix errors when uninit is reported "as soon as possible," namely when first fetched from memory. Yes, "complain ASAP" tends to catch structure holes and padding, and too many bitfields. But I want to know about those anyway, because most of the time they indicate performance or reliability problems that I want to correct. [I also know about speculative overruns by memcpy, etc.; they can be readily diagnosed and suppressed.] -- John Reiser, jreiser@BitWagon.com |
|
From: Dirk M. <dm...@gm...> - 2003-11-21 13:11:48
|
On Friday 21 November 2003 05:50, John Reiser wrote: > For serious use it is important to understand when memcheck will complain, > amd when it will not. This shows that DIV and REM are exceptions to the > rule "complain exactly when an uninit bit affects conditional control flow > or I/O." They're no exceptions. Note it doesn't complain when you feed an uninitialized value into DIV - it just makes the result undefined. Actually, valgrind probably should complain when you divide by an undefined variable - it could be 0 and cause an exception. > Apparently FPU, MMX, and SSE/SSE2 instructions also are > exceptions: they complain on fetch. [Why is MMX AND/OR/XOR/LOAD/STORE > different from integer AND/OR/XOR/LOAD/STORE?] Because tracking definedness of FPU/MMX registers is extreme pain. How do you want to track definedness through instructions like sincos() ? Or even more important: how do you want to validate that all your value tracking is correct? (if you can't validate it - what use is a definedness tracker that might have bugs in its definedness tracking?) Of course its not impossible - it just proved not to be necessary so far. The usual mmx_memcpy() is an exception though. We might have to implement value tracking for those mmx instructions some time. > Are there any other exceptions? Yes, additionally value tracking for these instructions is not bitwise: IN, OUT DAS DAA BSR BSF SHLDL SHLDW SHRDL SHRDW except the first one these are very rarely generated by compilers so that is not a usual problem. > For instance, tracking uninit bits through MUL is much more complicated > than through ADD, although not as bad as through DIV/REM. Multiplying > by 0x11111111, 0x01010101, 0x01001001, or 0x00010001 does useful things. > Could memcheck have problems here? valgrind 2.1 tracks partial definedness now through MUL sometimes. As I said, its possible to do that for REM at least. Does it make sense? I haven't seen such bittricks on undefined values being done so far for legitimate reasons. > Is there an option to have "integer" instructions complain on fetch > instead of "as late as possible?" No. That makes absolutely no sense. compilers regularly fetch integer size data from word-aligned bytes for performance reasons etc. You will get so many warnings that you don't find the real ones anymore. > I find it easier to find and fix errors > when uninit is reported "as soon as possible," namely when first fetched > from memory. Yes, but then you're asking for the feature that whenever an if() decision is made based on an undefined value it doesn't show the backtrace of the if() but of the place where that uninitialized value was "created". Thats an interesting feature that is on our todo, however so far we had no idea how to actually implement it. You'd need to store for each bit in memory a backtrace structure on where it was fetched. Thats an immense runtime and memory space overhead that would not be useful on slightly more complex programs. Note that code checkers which instrument the binary don't have this problem, since they can do this tracking mostly statically during analysing the source. valgrind can't do that. > [I also know about speculative overruns by memcpy, > etc.; they can be readily diagnosed and suppressed.] No, they can't, since compilers tend to inline those, so you'd have to suppress almost each and every function in your application, and then it makes little sense using valgrind at all. |
|
From: Daniel G. <dan...@no...> - 2003-11-21 17:00:24
|
I am trying to run valgrind on a Cx486DX2 which has no CPUID or RDTSC instruction. I've managed to get past the CPUID in vg_startup.S with a hack suggested by Jeremy, but now I'm trying to figure out the best way around RDSTC. The instuction is called by start_rdtsc_calibration() in vg_main.c. Suggestions? I'm going to keep beating on it for now, but if someone can point me down the right path, great! Cheers, Dan. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-21 17:14:46
|
On Fri, 21 Nov 2003, Daniel Goertzen wrote: > I am trying to run valgrind on a Cx486DX2 which has no CPUID or RDTSC > instruction. > > I've managed to get past the CPUID in vg_startup.S with a hack suggested by > Jeremy, but now I'm trying to figure out the best way around RDSTC. The > instuction is called by start_rdtsc_calibration() in vg_main.c. > > Suggestions? I'm going to keep beating on it for now, but if someone can > point me down the right path, great! At a guess, try disabling the uses of RDTSC in VG_(read_millisecond_timer)() and VG_(start_rdtsc_calibration)(); try hard-coding in some reasonable values instead. N |
|
From: Salim S. <ssa...@ti...> - 2003-11-21 18:19:41
Attachments:
valgrind_output.txt
|
Hello all, I'm trying to run valgrind on my stack. Unfortunately it fails all time when calling a function in the Judy lib (C libraries for creating and accessing dynamic arrays: http://judy.sourceforge.net/) I wonder if someone has success doing this (running valgrind on a code using Judy array)? I make a small test on which there is a call to the Judy lib. It works fine but when I run it with valgrind ... It fails.!! Here the test: /*************************************************************************** */ #include <unistd.h> #include <stdio.h> #include <string.h> #include <Judy.h> #define MAXLINE 65536 // max string (line) len int main() { Pvoid_t PJArray = (PWord_t)NULL; // Judy array. PWord_t PValue; // Judy array element. Word_t Bytes; // size of JudySL array. char Index[MAXLINE]; // string to check uint32_t i=0; while ((fgets(Index, sizeof(Index), stdin) != "")&&(i++<5) ) { JSLI(PValue, PJArray, Index); // store string into array if (PValue == PJERR) // if out of memory? { // so do something printf("ERROR \n"); exit(1); } ++(*PValue); // count instances of string } Index[0] = '\0'; // start with smallest string. JSLF(PValue, PJArray, Index); // get first string while (PValue != NULL) { while ((*PValue)--) // print duplicates printf("%s", Index); JSLN(PValue, PJArray, Index); // get next string } JSLFA(Bytes, PJArray); // free array fprintf(stderr, "The JudySL array used %lu bytes of memory\n", Bytes); return (0); } /*************************************************************************** */ Many thanks in advance for your reply. All the best, salim PS: I'm working on : + RedHat Advanced Server 2.1 machine, + proc: IA32 + uname -a Linux host_1 2.4.9-e.24smp #1 SMP Tue May 27 16:07:39 EDT 2003 i686 unknown and using the last version of valgrind 2.0.0. Valgrind report is attached |
|
From: Dan K. <da...@ke...> - 2003-11-21 18:26:01
|
Salim SAYOURI wrote: > I'm trying to run valgrind on my stack. Unfortunately it fails all time when > calling a function in the Judy lib (C libraries for creating and accessing > dynamic arrays: http://judy.sourceforge.net/) > ==21866== Invalid read of size 4 > ==21866== at 0x402702E4: JudySLIns (src/JudySL/JudySL.c:630) > ==21866== by 0x8048789: main (judySL_test.c:20) > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > ==21866== by 0x8048630: (within /home/ocadmin/salim/lab_RD/a.out) > ==21866== Address 0x40D35020 is 4 bytes before a block of size 7 alloc'd > ==21866== at 0x4002BB60: malloc (vg_replace_malloc.c:153) > ==21866== by 0x40270009: JudySLIns (src/JudySL/JudySL.c:552) > ==21866== by 0x8048789: main (judySL_test.c:20) > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > ==21866== > ==21866== Invalid free() / delete / delete[] > ==21866== at 0x4002BE5B: free (vg_replace_malloc.c:231) > ==21866== by 0x40270378: JudySLIns (src/JudySL/JudySL.c:639) > ==21866== by 0x8048789: main (judySL_test.c:20) > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > ==21866== Address 0x40D35020 is 4 bytes before a block of size 7 alloc'd > ==21866== at 0x4002BB60: malloc (vg_replace_malloc.c:153) > ==21866== by 0x40270009: JudySLIns (src/JudySL/JudySL.c:552) > ==21866== by 0x8048789: main (judySL_test.c:20) > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > File 'judySL_test.c', line 20: JudySLIns(), JU_ERRNO_* == 7, ID == 396 Assuming your test program isn't buggy, you may have found a bug in the Judy library. Either way, you probably want to take this up on the Judy mailing list... - Dan |
|
From: Olly B. <ol...@su...> - 2003-11-21 19:01:06
|
On Fri, Nov 21, 2003 at 07:22:26PM +0100, Salim SAYOURI wrote:
> while ((fgets(Index, sizeof(Index), stdin) != "")&&(i++<5) )
Off-topic, but the != test here is clearly wrong. fgets will return
Index (on success) or NULL (on failure). Neither will compare equal to
a pointer to the string constant "" since != compares pointers - use
strcmp to compare the strings pointed to...
Cheers,
Olly
|
|
From: Jeremy F. <je...@go...> - 2003-11-21 18:58:03
|
On Fri, 2003-11-21 at 08:59, Daniel Goertzen wrote: > I am trying to run valgrind on a Cx486DX2 which has no CPUID or RDTSC > instruction. > > I've managed to get past the CPUID in vg_startup.S with a hack suggested by > Jeremy, but now I'm trying to figure out the best way around RDSTC. The > instuction is called by start_rdtsc_calibration() in vg_main.c. > > Suggestions? I'm going to keep beating on it for now, but if someone can > point me down the right path, great! First question: are you using 2.0 or HEAD? 2.0 is a bit more dependent on the TSC for timing everything, whereas I think HEAD only needs it to pthread_cond_timedwait. Probably the best thing to do is go and find all instances of rdtsc (ie, calls to do_rdtsc_insn), and replace them with calls to gettimeofday. This is something we probably need to do anyway, since many machines have TSCs which change rate anyway, which makes it useless for us. J |
|
From: Daniel G. <dan...@no...> - 2003-11-21 21:10:22
Attachments:
valgrind-ar.patch
valgrind-cx486.patch
|
I am using 2.0.0. The only call to do_rtdsc_insn was in read_millsecond_timer, and I replace that with gettimeofday. VG will now run on my board, yay! Attached are two patches: The first one, valgrind-cx486.patch, works around the CPUID and RTDSC instructions in coregrind/. The second one, valgrind-ar.patch, hacks some of the makefiles to respect the environmental "AR" variable. The build system handles AR great but and then blows it at the last minute by saying "AR = ar". Nicholas and Jeremy, thank you for your help! Cheers, Dan. -----Original Message----- From: val...@li... [mailto:val...@li...]On Behalf Of Jeremy Fitzhardinge Sent: Friday, November 21, 2003 12:58 PM To: Daniel Goertzen Cc: val...@li... Subject: Re: [Valgrind-users] start_rstsc_calibration causes illegalinstruction crash On Fri, 2003-11-21 at 08:59, Daniel Goertzen wrote: > I am trying to run valgrind on a Cx486DX2 which has no CPUID or RDTSC > instruction. > > I've managed to get past the CPUID in vg_startup.S with a hack suggested by > Jeremy, but now I'm trying to figure out the best way around RDSTC. The > instuction is called by start_rdtsc_calibration() in vg_main.c. > > Suggestions? I'm going to keep beating on it for now, but if someone can > point me down the right path, great! First question: are you using 2.0 or HEAD? 2.0 is a bit more dependent on the TSC for timing everything, whereas I think HEAD only needs it to pthread_cond_timedwait. Probably the best thing to do is go and find all instances of rdtsc (ie, calls to do_rdtsc_insn), and replace them with calls to gettimeofday. This is something we probably need to do anyway, since many machines have TSCs which change rate anyway, which makes it useless for us. J |
|
From: Nicholas N. <nj...@ca...> - 2003-11-24 11:46:26
|
On Fri, 21 Nov 2003, Daniel Goertzen wrote: > Attached are two patches: The first one, valgrind-cx486.patch, works around > the CPUID and RTDSC instructions in coregrind/. The RTDSC patch removes a lot of code, which is good. What are the pros and cons of gettimeofday() vs. rdtsc? I don't know much about timing issues, but gettimeofday() seems simpler and would avoid the problems with laptops that RTDSC has? Maybe gettimeofday() makes VG_(read_millisecond_timer)() more expensive, as it requires a system call? Any other relevant issues? The skipping of CPUID in the patch isn't good though, we need to use it. Ideally, we'd set up a SIGILL handler before doing the CPUID (that's what Cachegrind does when detecting the cache parameters). However, that's not so easy to do in assembly code, AFAIK. > The second one, valgrind-ar.patch, hacks some of the makefiles to > respect the environmental "AR" variable. The build system handles AR > great but and then blows it at the last minute by saying "AR = ar". The Makefile.in files are built from Makefile.am files, by automake. It sticks the "AR = ar" lines in there of its own accord. Any ideas how to stop it doing this? N |
|
From: Sebastian K. <Seb...@so...> - 2003-11-24 11:55:29
|
From: "Nicholas Nethercote" <nj...@ca...> > On Fri, 21 Nov 2003, Daniel Goertzen wrote: > The skipping of CPUID in the patch isn't good though, we need to use it. > Ideally, we'd set up a SIGILL handler before doing the CPUID (that's what > Cachegrind does when detecting the cache parameters). However, that's not > so easy to do in assembly code, AFAIK. Do not forget that all CPUID CPU's allow for changing CPUID flag in flags register -- i.e. no need to handle signals, just few PUSHFs, POPFs, PUSHes anf POPs... rgds Sebastian Kaliszewski -- "Never underestimate the power of human stupidity" - from Notebooks of L.L. |
|
From: Jeremy F. <je...@go...> - 2003-11-25 08:30:31
|
On Mon, 2003-11-24 at 03:46, Nicholas Nethercote wrote: > On Fri, 21 Nov 2003, Daniel Goertzen wrote: > > > Attached are two patches: The first one, valgrind-cx486.patch, works around > > the CPUID and RTDSC instructions in coregrind/. > > The RTDSC patch removes a lot of code, which is good. What are the pros > and cons of gettimeofday() vs. rdtsc? I don't know much about timing > issues, but gettimeofday() seems simpler and would avoid the problems with > laptops that RTDSC has? Maybe gettimeofday() makes > VG_(read_millisecond_timer)() more expensive, as it requires a system > call? Any other relevant issues? It would certainly be nice to use the TSC as a timebase if we can be sure it is reliable, but I don't know how we can tell. The CVS HEAD version of Valgrind makes much less use of read_millisecond_timer, so I don't think its efficiency is a huge issue. J |
|
From: Tom H. <th...@cy...> - 2003-11-24 12:56:22
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> The skipping of CPUID in the patch isn't good though, we need to use it.
> Ideally, we'd set up a SIGILL handler before doing the CPUID (that's what
> Cachegrind does when detecting the cache parameters). However, that's not
> so easy to do in assembly code, AFAIK.
You can check for CPUID support by playing with EFLAGS. There are
plenty of examples around if you google for it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-11-24 12:59:26
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> You can check for CPUID support by playing with EFLAGS. There are
> plenty of examples around if you google for it.
In fact there is sample code in the Intel CPUID application node
showing how to check for it. The application note is at:
http://www.intel.com/design/xeon/applnots/241618.htm
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dirk M. <dm...@gm...> - 2003-11-24 13:42:57
|
On Monday 24 November 2003 13:59, Tom Hughes wrote: > In fact there is sample code in the Intel CPUID application node > showing how to check for it. The application note is at: Thats nice. However the problem is that the application we valgrind might want to run the cpuid instruction and will then expect to receive a SIGILL. We can't just skip the instruction, since that will break the simulation. The case you're trying to fix is when valgrind calls itself cpuid to figure some things out. Thats a different issue though. |
|
From: Tom H. <th...@cy...> - 2003-11-24 14:10:46
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Monday 24 November 2003 13:59, Tom Hughes wrote:
>
>> In fact there is sample code in the Intel CPUID application node
>> showing how to check for it. The application note is at:
>
> Thats nice. However the problem is that the application we valgrind might want
> to run the cpuid instruction and will then expect to receive a SIGILL. We
> can't just skip the instruction, since that will break the simulation.
But if valgrind can check whether the instruction is there or not
then it could generate a SIGILL to the application it is running
couldn't it?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-24 14:16:11
|
On Mon, 24 Nov 2003, Tom Hughes wrote: > >> In fact there is sample code in the Intel CPUID application node > >> showing how to check for it. The application note is at: > > > > Thats nice. However the problem is that the application we valgrind might want > > to run the cpuid instruction and will then expect to receive a SIGILL. We > > can't just skip the instruction, since that will break the simulation. > > But if valgrind can check whether the instruction is there or not > then it could generate a SIGILL to the application it is running > couldn't it? We're talking about using CPUID when Valgrind starts up to determine what features the CPU supports (eg. SSE). So looking at EFLAGS is fine for this. If the client program calls CPUID itself, that passes through Valgrind untouched. N |
|
From: Tom H. <th...@cy...> - 2003-11-24 14:19:27
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> We're talking about using CPUID when Valgrind starts up to determine what
> features the CPU supports (eg. SSE). So looking at EFLAGS is fine for
> this. If the client program calls CPUID itself, that passes through
> Valgrind untouched.
Well almost untouched - valgrind masks out the 3dnow bit I believe.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dirk M. <dm...@gm...> - 2003-11-24 14:23:00
|
On Monday 24 November 2003 15:16, Nicholas Nethercote wrote: > features the CPU supports (eg. SSE). So looking at EFLAGS is fine for > this. If the client program calls CPUID itself, that passes through > Valgrind untouched. no, it doesn't, since we intercept it to fake the cpuid. |
|
From: Salim S. <ssa...@ti...> - 2003-11-24 11:16:53
|
> > ==21866== Invalid read of size 4 > > ==21866== at 0x402702E4: JudySLIns (src/JudySL/JudySL.c:630) > > ==21866== by 0x8048789: main (judySL_test.c:20) > > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > > ==21866== by 0x8048630: (within /home/ocadmin/salim/lab_RD/a.out) > > ==21866== Address 0x40D35020 is 4 bytes before a block of size 7 alloc'd > > ==21866== at 0x4002BB60: malloc (vg_replace_malloc.c:153) > > ==21866== by 0x40270009: JudySLIns (src/JudySL/JudySL.c:552) > > ==21866== by 0x8048789: main (judySL_test.c:20) > > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > > ==21866== > > ==21866== Invalid free() / delete / delete[] > > ==21866== at 0x4002BE5B: free (vg_replace_malloc.c:231) > > ==21866== by 0x40270378: JudySLIns (src/JudySL/JudySL.c:639) > > ==21866== by 0x8048789: main (judySL_test.c:20) > > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > > ==21866== Address 0x40D35020 is 4 bytes before a block of size 7 alloc'd > > ==21866== at 0x4002BB60: malloc (vg_replace_malloc.c:153) > > ==21866== by 0x40270009: JudySLIns (src/JudySL/JudySL.c:552) > > ==21866== by 0x8048789: main (judySL_test.c:20) > > ==21866== by 0x40296686: __libc_start_main (../sysdeps/generic/libc-start.c:129) > > File 'judySL_test.c', line 20: JudySLIns(), JU_ERRNO_* == 7, ID == 396 > > Assuming your test program isn't buggy, > you may have found a bug in the Judy library. > Either way, you probably want to take this up on the Judy mailing list... > - Dan It seems that the pointers used in Judy array are aligned on 8 bytes! And launching valgrind with the option --alignment=8 solves the problem. This paragraph, from "Judy IV Shop Manual", explains the mystery: ---------------------------------------------------------------------------- ------------ 4.2 Judy Array Pointer (JAP): A Judy Array Pointer (root pointer) is 1 word = 4 bytes [8 bytes] containing an ordinary pointer (memory address) that points to a Judy array, except that it always references an object aligned to at least a 2-word = 8-byte [16-byte] boundary. Hence the 3 [or 4] least significant bits of the root pointer would always be 0, and are usable to encode the type of object to which the root pointer points. [In fact only the least 3 bits are needed and used, even on 64-bit systems.] Best regards, __salim |
|
From: Nicholas N. <nj...@ca...> - 2003-11-24 11:32:31
|
On Mon, 24 Nov 2003, Salim SAYOURI wrote: > It seems that the pointers used in Judy array are aligned on 8 bytes! And > launching valgrind with the option --alignment=8 solves the problem. This is a fairly common problem... perhaps we should just change Valgrind's allocator to align heap blocks on 8-byte boundaries? I know that programs should, strictly speaking, be able to handle 4-byte alignments. But it does cause difficult-to-understand problems with Memcheck. Not sure. N |
|
From: Crispin F. <val...@fl...> - 2003-11-24 11:45:24
|
On Mon, 2003-11-24 at 11:32, Nicholas Nethercote wrote: > On Mon, 24 Nov 2003, Salim SAYOURI wrote: > > > It seems that the pointers used in Judy array are aligned on 8 bytes! And > > launching valgrind with the option --alignment=8 solves the problem. > > This is a fairly common problem... perhaps we should just change > Valgrind's allocator to align heap blocks on 8-byte boundaries? I know > that programs should, strictly speaking, be able to handle 4-byte > alignments. But it does cause difficult-to-understand problems with > Memcheck. Not sure. It would certainly help running some gnome programs, I know quite a few people who thought that valgrind couldn't run their programs (certainly the alignment is needed for galeon and epiphany). Crispin |
|
From: Jeffrey S. <fe...@xi...> - 2003-11-24 15:16:37
|
On Mon, 2003-11-24 at 06:32, Nicholas Nethercote wrote:
> On Mon, 24 Nov 2003, Salim SAYOURI wrote:
>
> > It seems that the pointers used in Judy array are aligned on 8 bytes! And
> > launching valgrind with the option --alignment=8 solves the problem.
>
> This is a fairly common problem... perhaps we should just change
> Valgrind's allocator to align heap blocks on 8-byte boundaries? I know
> that programs should, strictly speaking, be able to handle 4-byte
> alignments.
I'm not sure this is true. Most programs expect that malloc will return
a memory buffer aligned to be suitable for any data storage.
see the man page for malloc:
RETURN VALUE
For calloc() and malloc(), the value returned is a pointer to the
allo-
cated memory, which is suitably aligned for any kind of
variable, or
NULL if the request fails.
on x86, this would be 8.
Jeff
> But it does cause difficult-to-understand problems with
> Memcheck. Not sure.
>
> N
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|