https://bugs.kde.org/show_bug.cgi?id=352130
--- Comment #3 from Godmar Back <god...@gmail.com> ---
I am seeing the same or a very similar issues in valgrind 3.18.1 on Ubuntu
20.04 LTS with GNU LibC 2.5
The attached test program results in:
```c
==952377== Helgrind, a thread error detector
==952377== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==952377== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==952377== Command: ./ptest
==952377==
thread1
==952377== ---Thread-Announcement------------------------------------------
==952377==
==952377== Thread #1 is the program's root thread
==952377==
==952377== ---Thread-Announcement------------------------------------------
==952377==
==952377== Thread #2 was created
==952377== at 0x49BE282: clone (clone.S:71)
==952377== by 0x48812EB: create_thread (createthread.c:101)
==952377== by 0x4882E0F: pthread_create@@GLIBC_2.2.5 (pthread_create.c:817)
==952377== by 0x4846FBA: pthread_create_WRK (hg_intercepts.c:445)
==952377== by 0x48480BD: pthread_create@* (hg_intercepts.c:478)
==952377== by 0x109203: main (in /home/gback/cs3214/dutchblitz/ptest)
==952377==
==952377== ----------------------------------------------------------------
==952377==
==952377== Possible data race during write of size 1 at 0x5292193 by thread #1
==952377== Locks held: none
==952377== at 0x484C812: mempcpy (vg_replace_strmem.c:1668)
==952377== by 0x492E7B1: _IO_new_file_xsputn (fileops.c:1236)
==952377== by 0x492E7B1: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1197)
==952377== by 0x4923677: puts (ioputs.c:40)
==952377== by 0x10920F: main (in /home/gback/cs3214/dutchblitz/ptest)
==952377== Address 0x5292193 is 3 bytes inside a block of size 1,024 alloc'd
==952377== at 0x483E8D5: malloc (vg_replace_malloc.c:381)
==952377== by 0x4920E83: _IO_file_doallocate (filedoalloc.c:101)
==952377== by 0x493104F: _IO_doallocbuf (genops.c:347)
==952377== by 0x49300AF: _IO_file_overflow@@GLIBC_2.2.5 (fileops.c:745)
==952377== by 0x492E834: _IO_new_file_xsputn (fileops.c:1244)
==952377== by 0x492E834: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1197)
==952377== by 0x4923677: puts (ioputs.c:40)
==952377== by 0x1091C4: thread1 (in /home/gback/cs3214/dutchblitz/ptest)
==952377== by 0x48471B2: mythread_wrapper (hg_intercepts.c:406)
==952377== by 0x4882608: start_thread (pthread_create.c:477)
==952377== by 0x49BE292: clone (clone.S:95)
==952377== Block was alloc'd by thread #2
==952377==
main
==952377==
==952377== Use --history-level=approx or =none to gain increased speed, at
==952377== the cost of reduced accuracy of conflicting-access information
==952377== For lists of detected and suppressed errors, rerun with: -s
==952377== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 19 from 19)
```
The bug fix Mark proposed in 2015 included a suppression. I have been looking
for related suppressions in the 3.18.1 codebase, finding
```
{
helgrind-glibc-io-xsputn-mempcpy
Helgrind:Race
fun:__GI_mempcpy
fun:_IO_*xsputn*
obj:*/lib*/libc-2.*so*
}
```
and
```
Ubuntu804-hack-1
Memcheck:Overlap
fun:mempcpy
fun:_IO_default_xsputn
obj:/lib*/libc-2.*so*
}
```
Running with `--gen-suppressions=yes` however, generates:
```
{
<insert_a_suppression_name_here>
Helgrind:Race
fun:mempcpy
fun:_IO_new_file_xsputn
fun:_IO_file_xsputn@@GLIBC_2.2.5
fun:puts
fun:main
}
```
which appears incompatible with those suppressions if I read this correctly.
Should this bug be reopened or a new bug be filed, or is there some other
explanation?
--
You are receiving this mail because:
You are watching all bug changes.
