M
mathog
I have run into one of those horrible bugs where the placement of
print statements affects a calculation. These always come down to
memory access issues or uninitialized variables, and this one is giving
me conniptions. The code does not generate any compiler warnings with
-Wall, nor any errors that gdb or Valgrind will flag, and adding range
check code before every array access did not show any out of range
memory accesses. The next step is to pull the code out of the larger
program and test it separately, where perhaps changing optimization
switches will let valgrind see something.
This did bring up an interesting point though. Valgrind will say when a
program accesses uninitialized memory or unallocated memory.
Neither are happening here, so the memory error is probably of
the type where a memory access goes to the wrong place, but there is a
valid variable there. In order to find this one would need a way to
move the memory which is used around, and especially to space it out,
such that something like:
int a,b,c; /* 4 byte integers */
double d; /* 8 byte doubles */
which is normally stored like:
a 0-3
b 4-7
c 8-11
d 12-19
is instead stored spaced out like:
- 0-16
a 16-19
- 20-31
b 32-35
- 36-47
c 48-51
- 52-55
d 60-67
- 68-71
- 72-87
A 32 or 64 byte space might be even better. If laid out in that manner,
with uninitialized, unused memory between the variables, valgrind might
find the problem.
Are there any compilers that have a switch that will induce this sort of
intentionally unpacked memory organization?
(Manually inserting dummy variables in all those positions might work,
although it would be a painful editing exercise, but more likely the
compiler would warn about them and then optimize those variables
out of existence.)
Thanks,
David Mathog
print statements affects a calculation. These always come down to
memory access issues or uninitialized variables, and this one is giving
me conniptions. The code does not generate any compiler warnings with
-Wall, nor any errors that gdb or Valgrind will flag, and adding range
check code before every array access did not show any out of range
memory accesses. The next step is to pull the code out of the larger
program and test it separately, where perhaps changing optimization
switches will let valgrind see something.
This did bring up an interesting point though. Valgrind will say when a
program accesses uninitialized memory or unallocated memory.
Neither are happening here, so the memory error is probably of
the type where a memory access goes to the wrong place, but there is a
valid variable there. In order to find this one would need a way to
move the memory which is used around, and especially to space it out,
such that something like:
int a,b,c; /* 4 byte integers */
double d; /* 8 byte doubles */
which is normally stored like:
a 0-3
b 4-7
c 8-11
d 12-19
is instead stored spaced out like:
- 0-16
a 16-19
- 20-31
b 32-35
- 36-47
c 48-51
- 52-55
d 60-67
- 68-71
- 72-87
A 32 or 64 byte space might be even better. If laid out in that manner,
with uninitialized, unused memory between the variables, valgrind might
find the problem.
Are there any compilers that have a switch that will induce this sort of
intentionally unpacked memory organization?
(Manually inserting dummy variables in all those positions might work,
although it would be a painful editing exercise, but more likely the
compiler would warn about them and then optimize those variables
out of existence.)
Thanks,
David Mathog