Valgrind Users, Many thanks to Philippe and John for helping me out with this. As rightly pointed out, valgrind shouldn't and doesn't alter the working directory so it was, indeed, something else preventing access to the data files. By using valgrind + vgdb I stepped through the code and found that the config file wasn't being opened because the code uses the process name to determine what 'conf' file to open. Clearly, under valgrind (default) the process name is not the program name and is in fact memcheck-x86-li.
Having sorted the above issue valgrind successfully determined where the heap corruption was occurring - a silly coding error in the test harness. Regards, Mark **** Triathlete, climber, and mediocre pianist - aspiring to be just a little bit better than last year --- Co-founder of Woodland Friends: www.woodlandfriends.co.uk - replanting native British woodland for the benefit of communities and wildlife On 10/09/15 21:36, Philippe Waroquiers wrote: > On Thu, 2015-09-10 at 09:40 +0100, Mark Chimley wrote: >> Folks, >> >> This is hopefully a question with an easy answer. I've got a program >> which seems to cause heap corruption so I thought valgrind would be able >> to tell me where this occurs. The trouble is the program uses data files >> from the running directory for configuration purposes and running the >> program under valgrind seems to prevent it finding these data files. I >> therefore cannot reproduce the conditions which cause the problem. >> >> I've looked in the manual, help and FAQs for how to set the working >> directory but I cannot find anything related to this. I feel I must be >> missing something quite obvious as this would appear to be quite a >> fundamental issue. >> > For sure, if valgrind would fiddle with the working directory, > then a lot of things would not work properly. > As an example, doing > valgrind pwd > properly shows the current working directory where you launch valgrind. > > So, something else must happen. > > What you could do is to run your application with > valgrind --trace-syscalls=yes .... > and see e.g. which open syscall is unexpectedly failing. > > Alternatively, start your application with valgrind+vgdb, > and put breakpoints at the relevant places to see why the > required files are not being opened. > (see > http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver > for more info about debugging your application running under valgrind). > > > Philippe > > > > ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
