After the last few days activities it is now possible to run the entire Pike testsuite in valgrind without any errors in Pike (though the gdbm lib has some problems).
And there was much rejoicing!
/ David Hedbor
Previous text:
2003-10-02 15:56: Subject: valgrind
After the last few days activities it is now possible to run the entire Pike testsuite in valgrind without any errors in Pike (though the gdbm lib has some problems).
/ Martin Nilsson (saturator)
I recompiled with dmalloc though and got tons of printouts...
It appears that DO_HASHMEM reads outside of its buffer. Is this a good fix?
diff -c -r1.46 pike_memory.h *** pike_memory.h 13 May 2003 19:34:31 -0000 1.46 --- pike_memory.h 2 Oct 2003 15:21:39 -0000 *************** *** 191,196 **** --- 191,198 ---- #endif /* sizeof(char *) == 4 */
/* NB: RET should be an lvalue of type size_t. */ + /* NB2: A is evaluated twice (since that is usually a compile + time operation compared to adjusting a). */ #define DO_HASHMEM(RET, A, LEN, MLEN) \ do { \ const unsigned char *a = A; \ *************** *** 230,236 **** DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)a; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \ --- 232,238 ---- DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)A; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \
/ Martin Nilsson (saturator)
Previous text:
2003-10-02 17:12: Subject: valgrind
And there was much rejoicing!
/ David Hedbor
Last time I checked that problem I believe it was due to hashing the uninitialized padding bytes within the bounds of a struct. I don't remember the details but I believe it was harmless.
/ Jonas Walldén
Previous text:
2003-10-02 17:42: Subject: valgrind
I recompiled with dmalloc though and got tons of printouts...
It appears that DO_HASHMEM reads outside of its buffer. Is this a good fix?
diff -c -r1.46 pike_memory.h *** pike_memory.h 13 May 2003 19:34:31 -0000 1.46 --- pike_memory.h 2 Oct 2003 15:21:39 -0000
*** 191,196 **** --- 191,198 ---- #endif /* sizeof(char *) == 4 */
/* NB: RET should be an lvalue of type size_t. */
- /* NB2: A is evaluated twice (since that is usually a compile
- time operation compared to adjusting a). */
#define DO_HASHMEM(RET, A, LEN, MLEN) \ do { \ const unsigned char *a = A; \
*** 230,236 **** DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)a; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \ --- 232,238 ---- DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)A; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \
/ Martin Nilsson (saturator)
Wouldn't that be almost as bad, since the hash is not a hash but a random value. Since I don't know exactly what DO_HASHMEM is supposed to do, and how its arguments relates I just guessed that the increment of "a" was not considered in the loops in DO_IF_ELSE_UNALIGNED_MEMORY, where uninitialized memory is affecting "ret".
/ Martin Nilsson (saturator)
Previous text:
2003-10-02 17:48: Subject: valgrind
Last time I checked that problem I believe it was due to hashing the uninitialized padding bytes within the bounds of a struct. I don't remember the details but I believe it was harmless.
/ Jonas Walldén
Hmm, come to think of it, that was probably not the DO_HASHMEM macro but some other code. Details are vague at this time but I think the uninitialized bytes didn't matter as long as they remained the same for the lifetime of that struct.
The DO_HASHMEM implementation lacks comments so I cannot tell if it's taking care of data at the start of the loop in a special way and therefore adjusts the counters correspondingly.
/ Jonas Walldén
Previous text:
2003-10-02 17:59: Subject: valgrind
Wouldn't that be almost as bad, since the hash is not a hash but a random value. Since I don't know exactly what DO_HASHMEM is supposed to do, and how its arguments relates I just guessed that the increment of "a" was not considered in the loops in DO_IF_ELSE_UNALIGNED_MEMORY, where uninitialized memory is affecting "ret".
/ Martin Nilsson (saturator)
It looks like it's intentional that b should be initialized from the modified a since the first seven bytes already has contributed to the hash value. I think the problem rather is that the end condition for the loop is wrong.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-02 17:42: Subject: valgrind
I recompiled with dmalloc though and got tons of printouts...
It appears that DO_HASHMEM reads outside of its buffer. Is this a good fix?
diff -c -r1.46 pike_memory.h *** pike_memory.h 13 May 2003 19:34:31 -0000 1.46 --- pike_memory.h 2 Oct 2003 15:21:39 -0000
*** 191,196 **** --- 191,198 ---- #endif /* sizeof(char *) == 4 */
/* NB: RET should be an lvalue of type size_t. */
- /* NB2: A is evaluated twice (since that is usually a compile
- time operation compared to adjusting a). */
#define DO_HASHMEM(RET, A, LEN, MLEN) \ do { \ const unsigned char *a = A; \
*** 230,236 **** DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)a; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \ --- 232,238 ---- DO_IF_ELSE_UNALIGNED_MEMORY_ACCESS( \ { \ size_t *b; \ ! b=(size_t *)A; \ \ for(DIVIDE_BY_2_CHAR_P(mlen);mlen--;) \ { \
/ Martin Nilsson (saturator)
pike-devel@lists.lysator.liu.se
-
David Hedbor ＠ Pike developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum