4

First, I am aware that another question with virtually the same title exists, but the answers to that question is not useful here. Another question gets close, but again the solution is not one I can user here.

My application uses a shared library that Valgrind really does not like. It generates:

Program Exception - illegal instruction
Image              PC                Routine            Line        Source             
libirc.so          000000000405ED3C  Unknown               Unknown  Unknown
libhdf5.so.7       00000000061338E2  Unknown               Unknown  Unknown
libhdf5.so.7       00000000061A73CE  Unknown               Unknown  Unknown
libhdf5.so.7       00000000061A9D6F  Unknown               Unknown  Unknown
libhdf5_fortran.s  0000000006B23233  Unknown               Unknown  Unknown
libhdf5_fortran.s  0000000006B19FF9  Unknown               Unknown  Unknown
les3d.x            00000000006D815C  Unknown               Unknown  Unknown

and dies before it even gets into my application (well, it gets into my application but the first thing we do is call a routine to initialize the shared library, which is where it dies). Running without Valgrind doesn't cause an illegal instruction, but I do get bizarre segfaults and hence the need for a memory checker. So it is totally unusable which is why error suppression won't work.

Is it possible to actually prevent Valgrind from operating on shared libraries called by an application? Not suppress the output, but actually not descend into it. If not, is there a memory checker that can be prevented?

Community
  • 1
  • 1
tpg2114
  • 14,112
  • 6
  • 42
  • 57

1 Answers1

3

First things first you should report this problem - there is information on how to do this at the valgrind web site.

What you are seeing suggests that valgrind's JIT is generating an instruction that is not valid on your machine, which really shouldn't be able to happen.

To answer your direct question, no there is no way of doing what you want, because it wouldn't make any sense - unless valgrind is able to see all the reads and writes that your program does it can't track the state of the memory properly and can't detect errors in the parts of the program it is monitoring. You would get both false positives and false negatives.

TomH
  • 8,900
  • 2
  • 32
  • 30
  • Good point, it's always frustrating when the tool to help fix a problem causes others. Or when running with debug compiler flags fails to reproduce the problem that occurs with release flags :( – tpg2114 Nov 28 '12 at 21:52