Re: [Valgrind-developers] Valgrind callgrind failure

[Paul F. <pj...@wa...>]

On 26-04-24 15:45, Carl Love wrote:
> Paul:
> 
> I tried the --sanity-level=4  option with valgrind.  The output was identical to running without that option.
> 
> 
> Using gdb on valgrind, we make a call to  VG_(client_syscall).  I have put some print statements in the
> routine to print the syscall number.  The function eventually calls  putSyscallStatusIntoGuestState.  I have print statements in  putSyscallStatusIntoGuestState to print how many times I have called this function.  I have stepped thru putSyscallStatusIntoGuestState and it seems to be fine (note, I have not yet looked at the contents of SyscallInfo and ThreadState data structures but I will work on that).  Eventually the call to putSyscallStatusIntoGuestState gets to running code in the guest state.  The segfault occurs after we have been running in the guest state for awhile.  One thing is the seg fault varies, sometime it happens on sysnum 90 which looks to be mmap, other times it is on syscall 6.  I wonder if there are actually two threads running and I can't tell which thread actually hits the segfault.  Further more, I see each of these system calls being made 10 to 20 times before the seg fault.  Not sure how we woule get the call correct multiple times and then mess it up.  But, checking the SyscallInfo and ThreadState data structures for each call might give some clues.  The variability of which syscall we are on when the segfault occurs and the fact that it isn't the first time we process that syscall makes it a little harder in gdb to see what is happening when things fail as you don't know exactly when it is going to fail.
> 
> Do you know if there are actually multiple valgrind threads running when we are doing syscalls?  I thought the execution of valgrind was all single threaded but I can't say for sure.
> 
> I will add some more prints to dump the SyscallInfo and ThreadState data structures to see if I can see any issues between a call that succeeds and one where things fail.  Thanks for the suggestions, I will let you know what I find.


Hi Carl

Valgrind does run multiple threads, but it schedules them as though 
there were only one core. So only one thread is active at a time.

There are three situations where the scheduler can switch threads

1. After a certain amount of code has been executed, controlled by 
--scheduling-quantum with a default of 100000 basic blocks.
2. Before each client syscall
3. After client syscalls that set SfYieldAfter in sci->flags (fork and 
thread creation).

Do you see the same problem with older versions of Valgrind?

A+
Paul