Then you have to understand what this task is doing. Isn't the backtrace pointing at what the code is doing and what this read could be ? Look at the file descriptor on which it is reading and see what this fd is ? Is it a real file ? (unlikely to be blocking then) Is it a pipe ? A tcp/ip connection ? Use lsof if you cannot determine in gdb what this fd is for.
[JMSS] It's a file. After I added some prints for debugging, the main thread seem to get unblocked (?) This can be false positive of course, and of course, this can be a true positive :). With only an address, no access to the code, no backtrace, no reproducer, there is not much feedback we can give. Let me just tell that at my work, we have added for helgrind a few suppression entries related to the 'low level implementation of the gnat runtime', to suppress false positive created by the low level inner working of the runtime. To see what you case is, the minimum needed would be the stack traces of the error msg. In summary, at this point, it looks like you have to debug your application when running under valgrind, and then you might determine if what you see is a real application bug, or a valgrind bug/limitation e.g. in the valgrind scheduler/signal handling/syscall handling or whatever. At this state, without further info, let's assume you have an application bug :) [JMSS] Yes, I think that we are now able to debug the application. It seems to run under nulgrind, helgrind and memcheck, so it should be "good" to go. [JMSS] I'll try to provide the patch for the configuration now. João M. S. Silva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
