channel has race condition

[kbkpbot]

Describe the bug

read / write from a channel in multiple threads, can lead to race condition.

Reproduction Steps

tt.v

module main

fn main() {
        ch := chan int{cap: 10}
        expected := 42

        spawn fn [expected, ch] () {
                ch <- expected
        }()

        received := <-ch

        ch.close()

        dump(received)
}

v tt.v -cg -gc none
valgrind --tool=helgrind ./tt

Expected Behavior

valgrind should report no error.

Current Behavior

$ valgrind --tool=helgrind ./tt
==1914200== Helgrind, a thread error detector
==1914200== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==1914200== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==1914200== Command: ./tt
==1914200==
==1914200== ---Thread-Announcement------------------------------------------
==1914200==
==1914200== Thread #1 is the program's root thread
==1914200==
==1914200== ---Thread-Announcement------------------------------------------
==1914200==
==1914200== Thread #2 was created
==1914200==    at 0x49AAA23: clone (clone.S:76)
==1914200==    by 0x49AABA2: __clone_internal_fallback (clone-internal.c:64)
==1914200==    by 0x49AABA2: __clone_internal (clone-internal.c:109)
==1914200==    by 0x491D54F: create_thread (pthread_create.c:297)
==1914200==    by 0x491E1A4: pthread_create@@GLIBC_2.34 (pthread_create.c:836)
==1914200==    by 0x4854975: ??? (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==1914200==    by 0x62781A: main__main (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x627CE0: main (in /home/mars/v/bug/channel/tt)
==1914200==
==1914200== ----------------------------------------------------------------
==1914200==
==1914200== Possible data race during read of size 2 at 0x4A96150 by thread #1
==1914200== Locks held: none
==1914200==    at 0x485A4F0: memmove (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==1914200==    by 0x625DDA: sync__Channel_try_pop_priv (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x628824: __chan_int_popval (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x627880: main__main (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x627CE0: main (in /home/mars/v/bug/channel/tt)
==1914200==
==1914200== This conflicts with a previous write of size 2 by thread #2
==1914200== Locks held: none
==1914200==    at 0x485A4F3: memmove (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==1914200==    by 0x625735: sync__Channel_try_push_priv (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x62885A: __chan_int_pushval (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x60A67B: anon_fn_8f299def6e98b835__95 (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x60A3F4: anon_fn_void__thread_wrapper (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x4854B7A: ??? (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==1914200==    by 0x491DAA3: start_thread (pthread_create.c:447)
==1914200==    by 0x49AAA33: clone (clone.S:100)
==1914200==  Address 0x4a96150 is 0 bytes inside a block of size 40 alloc'd
==1914200==    at 0x48488A8: malloc (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)
==1914200==    by 0x615817: _v_malloc (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x6244CF: sync__new_channel_st (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x627744: main__main (in /home/mars/v/bug/channel/tt)
==1914200==    by 0x627CE0: main (in /home/mars/v/bug/channel/tt)
==1914200==  Block was alloc'd by thread #1
==1914200==
[tt.v:15] received: 42
==1914200==
==1914200== Use --history-level=approx or =none to gain increased speed, at
==1914200== the cost of reduced accuracy of conflicting-access information
==1914200== For lists of detected and suppressed errors, rerun with: -s
==1914200== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

Possible Solution

need mutex for channel opearation? or atomic operation?

Additional Information/Context

No response

V version

V 0.4.10 566d22a

Environment details (OS name and version, etc.)

V full version	V 0.4.10 566d22a
OS	linux, Ubuntu 24.04.2 LTS
Processor	8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
Memory	7.58GB/15.51GB
V executable	/media/HD/github/kbkpbot/v/v
V last modified time	2025-06-02 00:07:12
V home dir	OK, value: /media/HD/github/kbkpbot/v
VMODULES	OK, value: /home/mars/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/mars/v/bug/channel
Git version	git version 2.43.0
V git status	weekly.2025.17-228-g8f1bf53f-dirty
.git/config present	true
cc version	cc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
gcc version	gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
clang version	Ubuntu clang version 18.1.3 (1ubuntu1)
tcc version	tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 696c1d84
emcc version	N/A
glibc version	ldd (Ubuntu GLIBC 2.39-0ubuntu8.4) 2.39

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-23037

[enghitalo]

Good catch!!

[kbkpbot]

I found it is due to the C.memcpy is not an atomic memory copy. If change it to something like atomic_memcpy(), this bug can be solved.

[kbkpbot]

This is confirmed to be a tcc bug when generating code for atomic_load/atomic_store on x86.
I will submit a commit on tcc repo.

When this tt.v compiled with gcc or clang, it will cause no bug when using drd tool instead of helgrind tool.

$ valgrind --tool=drd ./tt
==2223959== drd, a thread error detector
==2223959== Copyright (C) 2006-2020, and GNU GPL'd, by Bart Van Assche.
==2223959== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==2223959== Command: ./tt
==2223959==
[tt.v:40] received: 42
==2223959==
==2223959== For lists of detected and suppressed errors, rerun with: -s
==2223959== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 4)