Re: [Valgrind-developers] Valgrind callgrind failure

[Carl L. <ce...@li...>]

Valgrind developers:

I ran gdb on the valgrind command and let it run until it hit the segmentation error.

gdb --args  valgrind   --tool=callgrind   python3 bench_hnsw-short.py 1 hnsw_sq
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-20.el8

<snip>

Type "apropos word" to search for commands related to "word"...
Reading symbols from valgrind...done.
(gdb) r
Starting program: /home/carll/bin/valgrind --tool=callgrind python3 bench_hnsw-short.py 1 hnsw_sq
process 2378416 is executing new program: /home/carll/libexec/valgrind/callgrind-ppc64le-linux
Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-236.el8_9.12.ppc64le
==2378416== Callgrind, a call-graph generating cache profiler
==2378416== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==2378416== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright info
==2378416== Command: python3 bench_hnsw-short.py 1 hnsw_sq
==2378416== 
==2378416== For interactive control, run 'callgrind_control -h'.

Program received signal SIGSEGV, Segmentation fault.
0x000000100303740c in ?? ()
(gdb) where
#0  0x000000100303740c in ?? ()
#1  0x0000001003036e2c in ?? ()
#2  0x000000005809c480 in vgPlain_post_syscall (tid=42609792) at m_syswrap/syswrap-main.c:2620
#3  0x0000000000000000 in ?? ()


Looking at the code I see:

  /* Because the post handler might have changed the status (eg, the           
      post-handler for sys_open can change the result from success to           
      failure if the kernel supplied a fd that it doesn't like), once           
      again dump the syscall result back in the guest state.*/
   if (!(sci->flags & SfNoWriteResult))
      putSyscallStatusIntoGuestState( tid, &sci->status, &tst->arch.vex );   << Line 2620

   /* Do any post-syscall actions required by the tool. */
   if (VG_(needs).syscall_wrapper) {
      UWord tmpv[8];
      tmpv[0] = sci->orig_args.arg1;
      tmpv[1] = sci->orig_args.arg2;
      tmpv[2] = sci->orig_args.arg3;
      tmpv[3] = sci->orig_args.arg4;
      tmpv[4] = sci->orig_args.arg5;
      tmpv[5] = sci->orig_args.arg6;
      tmpv[6] = sci->orig_args.arg7;
      tmpv[7] = sci->orig_args.arg8;
      VG_TDICT_CALL(tool_post_syscall, tid,
                    sysno,
                    &tmpv[0], sizeof(tmpv)/sizeof(tmpv[0]),
                    sci->status.sres);
   }

So, it would seem we are having an issue with a file descriptor.

                              Carl 

On 4/19/24 08:33, Carl Love wrote:
> 
> Valgrind developers:
> 
> I ran into an issue with the valgrind callgrind tool running a python AI benchmark:
> 
>  valgrind   --tool=callgrind   python3 bench_hnsw-short.py 1 hnsw_sq
> ==2282131== Callgrind, a call-graph generating cache profiler
> ==2282131== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
> ==2282131== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright info
> ==2282131== Command: python3 bench_hnsw-short.py 1 hnsw_sq
> ==2282131== 
> ==2282131== For interactive control, run 'callgrind_control -h'.
> ==2282131== 
> ==2282131== Process terminating with default action of signal 11 (SIGSEGV)
> ==2282131==  Bad permissions for mapped region at address 0x6B50000
> ==2282131==    at 0x43962B8: __memset_power10 (in /usr/lib64/glibc-hwcaps/power9/libc-2.28.so)
> ==2282131==    by 0x1013FBFF: PyTuple_New (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x10262083: r_object (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x102619AF: r_object (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x10262053: r_object (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x1026360B: read_object (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x10263A7B: marshal_loads (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x10022D1B: _PyEval_EvalFrameDefault (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x10213103: _PyEval_Vector (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x100A991B: _PyFunction_Vectorcall (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x100AA99B: object_vacall (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> ==2282131==    by 0x100AABF3: PyObject_CallMethodObjArgs (in /home/carll/anaconda3/envs/faiss/bin/python3.11)
> 
> 
> Just starting to try and dig into the issue.  I was wondering if anyone who is familar with the callgrind tool might have any ideas or suggestions on what the issue might be?  Thanks.
> 
>                                Carl