Thanks. > The above error is triggered because you are using the gnat 'used stack' > measurement package. This package 'paints' the stack to see what has > been consumed. It paints more than the program really uses (of course > :), > and so it is completely normal that memcheck reports an error.
OK, I have removed switch -fstack-usage and the error vanished. > As discussed above, the error 'looks' normal, and should IMO be ignored > (you might want to disable the stack measurement functionality). > > To see why your program is blocked, use vgdb as suggested by Ivo. > Then do 'info task' to see the status of the Ada tasks, and if they > are blocked, and on what. From info task, all tasks are in "Runnable" state. There are 39 in this list. From gdb the program seems blocked reading a file (libc read()). But when I list (l) in gdb it does not show the correct line. It seems the synchronization with the source file is not correct. > As you are using Ada/SPARK, I guess you use a special tasking profile > (e.g. ravenscar or similar). I have no idea how such tasking profile > interacts with the single thread at a time model of Valgrind. > > You might try --fair-sched=yes to see if that helps. I tried but without success. > Also, try also --tool=none, just to see if the problem/blockage status > is linked to memcheck, or to the valgrind scheduling and Ada/SPARK > interaction. With nulgrind it still "hangs" so I seems related to the tread issue you mention. 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
