Client/Server pthreads program not executing under Valgrind. Runs fine normally

I have a C server program that creates & opens the write end of a named pipe (in /var/run), and interrupts on a SIGIO signal for a tty uart, pushing data into the pipe from that interface.

This program also spawns a secondary pthread, which opens the read end of a separate pipe (again, in /var/run), reads from it (blocking), and passes that data back to my main thread for writing out over my tty.

Data is shared between these using a mutex-locked struct. I also have a testing client program that handles the other end of this. Permissions/file access is valid.

This appears to work great running in bash.

I want to make doubly sure with Valgrind, though, specifically with the memcheck and helgrind tools, for memory leaks and thread errors. But when I start my server program in valgrind, it hangs and doesn’t run when my client starts up. I don’t even see my initial startup printf from the server at the start of the program. Valgrind just sits there, until I kill it.

I’m running with the following options:

valgrind --tool=helgrind ./server

and

valgrind --undef-value-errors=no ./server

Output is as follows (for both commands):

==7577== Memcheck, a memory error detector
==7577== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==7577== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7577== Command: ./server
==7577== 
--7577-- WARNING: Serious error when reading debug info
--7577-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--7577-- Ignoring non-Dwarf2/3/4 block in .debug_info
--7577-- WARNING: Serious error when reading debug info
--7577-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--7577-- Last block truncated in .debug_info; ignoring

Suppressing undef-value-errors because ld.so has a ton, and it was flooding my output.

Is there anything you could think of that I may be doing wrong? Maybe the lack of debug info in the ld library? I can dump code if need be, or elaborate further.

Thank you.

Answer

It looks like your valgrind version is rather old:

==7577== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==7577== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info

Assuming that ld-2.24.so is from glibc, that’s around five years of toolchain development, and who knows what kind of improvements when into the gcc and binutils versions which were used to compile that glibc.

Advertisement

Answer