2

I have just receive an output from valgrind that I do not quite understand:

==20290== Invalid read of size 1
==20290==    at 0x8C1D678: ???
==20290==    by 0x5D74C47: ???
==20290==  Address 0xee818c7d is not stack'd, malloc'd or (recently) free'd
==20290== 
==20290== 
==20290== Process terminating with default action of signal 11 (SIGSEGV)
==20290==  Access not within mapped region at address 0xEE818C7D
==20290==    at 0x8C1D678: ???
==20290==    by 0x5D74C47: ???
==20290==  If you believe this happened as a result of a stack
==20290==  overflow in your program's main thread (unlikely but
==20290==  possible), you can try to increase the size of the
==20290==  main thread stack using the --main-stacksize= flag.
==20290==  The main thread stack size used in this run was 8388608.
==20290==

Particularly, I am confused by these question marks. Typically what you get on this place is the location of errors valgrind has detected. I have used valgrind before and all the output was as describe in the manual. I have used this valgrind command:

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --track-origins=yes

The program itself yells a segmentation fault. Although valgrind does not tell me any location of the memory leak this time, from debugging I have determined the place where segmentation fault occurs. Unfortunately, it is within an ODE solver function from Intel ODE solver library (dodesol), and I have no access to it. I have carefully checked all the parameters I pass to this function many times and they seem to be ok (at least correspond to those in manual and examples I had before).

jww
  • 97,681
  • 90
  • 411
  • 885
Eugene B
  • 995
  • 2
  • 12
  • 27
  • Compile with `-g3` or `-g2` to ensure symbols are present. Compile with `-O1` or `-O0` to ensure accurate symbols. Also see [Preparing your Program](http://valgrind.org/docs/manual/quick-start.html#quick-start.prepare) in the Valgrind Quick Start Guide. – jww Jan 12 '18 at 17:48

2 Answers2

3

The ??? almost certainly mean that Valgrind wasn't able to find a symbol anywhere near the address in question. I suspect that you're executing code where there is no code. This could be the result of overwriting the return address on the stack, for example, perhaps as the result of a buffer overrun (but other pointer errors can trigger it) Valgrind is very good at problems with dynamically allocated memory, but it has a more difficult job with local variables, because it's not always possible for it to determine where an on stack array ends.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
1

One scenario where you'd get this result is if you're running Valgrind on a stripped binary/library and it finds an error within a local symbol (e.g. a static function).

Using the unstripped version of the binary/library that still contains information about all the local symbols will give the source file and line number in the Valgrind output.

Michael
  • 57,169
  • 9
  • 80
  • 125
  • Unfortunately this is not the case, my program is self-consistent, though uses some external libraries (gsl and intel ode solver, where the problem seems to be). It worked well before I attached intel ode solver to it. Thank you for your answer anyway! – Eugene B Mar 08 '13 at 16:10