https://bugs.kde.org/show_bug.cgi?id=480040

            Bug ID: 480040
           Summary: Empty /proc/self/cmdline with multiple threads
    Classification: Developer tools
           Product: valgrind
           Version: 3.22.0
          Platform: RedHat Enterprise Linux
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: memcheck
          Assignee: jsew...@acm.org
          Reporter: c.mau...@gmx.at
  Target Milestone: ---

Created attachment 165033
  --> https://bugs.kde.org/attachment.cgi?id=165033&action=edit
Creates two threads reading /proc/self/cmdline 1000 times

SUMMARY
When reading "/proc/self/cmdline" in parallel we occasionally get an empty file
back.

STEPS TO REPRODUCE
1. compile main.cpp
2. valgrind --tool=memcheck --fair-sched=yes myProgram

OBSERVED RESULT
$ valgrind --tool=memcheck --fair-sched=yes myProgram
==1000== Memcheck, a memory error detector
==1000== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1000== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1000== Command: /home/myUser/myProgram
==1000==
......................................................................................................................................................................................................................................Cmdline
was empty!
..................................................................................................................................................................................................................................................Cmdline
was empty!
................................................................................................Cmdline
was empty!
.......................................................................................................................................Cmdline
was empty!
......................................................................................................................................................................................................................................................Cmdline
was empty!
..............................................................................................Cmdline
was empty!
................................................................................................................................................................................................................................................................................................................................................................................................................................Cmdline
was empty!
.........................................................................................................................................................................................................................................................................................................................Cmdline
was empty!
............................................................................................................................................................................................................................==1000==
==1000== HEAP SUMMARY:
==1000==     in use at exit: 0 bytes in 0 blocks
==1000==   total heap usage: 13,982 allocs, 13,982 frees, 18,256,592 bytes
allocated
==1000==
==1000== All heap blocks were freed -- no leaks are possible
==1000==
==1000== For lists of detected and suppressed errors, rerun with: -s
==1000== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

EXPECTED RESULT
No 'Cmdline was empty!' message.

SOFTWARE/OS VERSIONS
Linux: RHEL 9

ADDITIONAL INFORMATION
* There is no such problem when executing the program without valgrind.
* Without fair-sched we get the error too, but it seems to happen less often.
* Our guess is, that 
** the file-descriptor which is 'cooked up at startup (in m_main)' is 'dup'ed
(two times) and fseek'ed to zero. 
** afterwards the threads read the fd sequentially and the first thread gets
the file, the second thread gets eof.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to