Skip to content

task-comm-15 fails when run with multiple threads #737

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
brson opened this issue Jul 25, 2011 · 3 comments
Closed

task-comm-15 fails when run with multiple threads #737

brson opened this issue Jul 25, 2011 · 3 comments

Comments

@brson
Copy link
Contributor

brson commented Jul 25, 2011

With RUST_THREADS=16, task-comm-15 occasionally produces valgrind errors like

==8944== Thread 3:
==8944== Invalid read of size 4
==8944==    at 0x4AC73CD: pthread_mutex_lock (pthread_mutex_lock.c:50)
==8944==    by 0x4A2E415: pthread_mutex_lock (forward.c:182)
==8944==    by 0x48E0D27: lock_and_signal::lock() (lock_and_signal.cpp:46)
==8944==    by 0x48E10C1: scoped_lock::scoped_lock(lock_and_signal&) (lock_and_signal.cpp:121)
==8944==    by 0x48E7BF8: rust_chan::send(void*) (rust_chan.cpp:82)
==8944==    by 0x48E9D11: upcall_send (rust_upcall.cpp:203)
==8944==    by 0x8048A24: start (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048DD7: main::spawn_wrapper5 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x48E72B0: task_start_wrapper (rust_task.cpp:128)
==8944==    by 0xDEADBEEE: ???
==8944==  Address 0x712bebc is 132 bytes inside a block of size 152 free'd
==8944==    at 0x48CCC02: free (vg_replace_malloc.c:366)
==8944==    by 0x48EE42C: rust_srv::free(void*) (rust_srv.cpp:12)
==8944==    by 0x48F14E1: memory_region::free(void*) (memory_region.cpp:58)
==8944==    by 0x48EE9D6: rust_kernel::free(void*) (rust_kernel.cpp:213)
==8944==    by 0x48E95E9: upcall_del_port (rust_internal.h:173)
==8944==    by 0x8048F88: glue_free11 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048F42: glue_drop10 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048C63: _rust_main (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048FBB: _rust_main_wrap (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0xDEADBEEE: ???
==8944==
==8944== Invalid read of size 4
==8944==    at 0x4AC6DAF: __pthread_mutex_lock_full (pthread_mutex_lock.c:139)
==8944==    by 0x4A2E415: pthread_mutex_lock (forward.c:182)
==8944==    by 0x48E0D27: lock_and_signal::lock() (lock_and_signal.cpp:46)
==8944==    by 0x48E10C1: scoped_lock::scoped_lock(lock_and_signal&) (lock_and_signal.cpp:121)
==8944==    by 0x48E7BF8: rust_chan::send(void*) (rust_chan.cpp:82)
==8944==    by 0x48E9D11: upcall_send (rust_upcall.cpp:203)
==8944==    by 0x8048A24: start (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048DD7: main::spawn_wrapper5 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x48E72B0: task_start_wrapper (rust_task.cpp:128)
==8944==    by 0xDEADBEEE: ???
==8944==  Address 0x712bebc is 132 bytes inside a block of size 152 free'd
==8944==    at 0x48CCC02: free (vg_replace_malloc.c:366)
==8944==    by 0x48EE42C: rust_srv::free(void*) (rust_srv.cpp:12)
==8944==    by 0x48F14E1: memory_region::free(void*) (memory_region.cpp:58)
==8944==    by 0x48EE9D6: rust_kernel::free(void*) (rust_kernel.cpp:213)
==8944==    by 0x48E95E9: upcall_del_port (rust_internal.h:173)
==8944==    by 0x8048F88: glue_free11 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048F42: glue_drop10 (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
==8944==    by 0x8048C63: _rust_main (in /home/banderson/Dev/rust/build/test/run-pass/task-comm-15.stage1)
@msullivan
Copy link
Contributor

Is this still true with the new reworking of tasking and channels?

@msullivan
Copy link
Contributor

It looks like this is caused by #627.

@msullivan
Copy link
Contributor

I ran this test a lot and didn't get any failures. Between that and having identified #627 as the original root cause, I'm going to close this bug and ask eholk about the status of #627.

keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
pdietl pushed a commit to pdietl/rust that referenced this issue Apr 23, 2020
repr(transparent): mention align=1 requirement
bjorn3 added a commit to bjorn3/rust that referenced this issue Apr 22, 2022
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…nsupported construct was found to be reachable (rust-lang#737)

* Update check results from SUCCESS to UNDETERMINED if one or more unsupported constructs were found to be reachable

* Block execution paths that go through unimplemented functions
tgross35 pushed a commit to tgross35/rust that referenced this issue Jun 3, 2025
`compiler_builtins` fails to compile to amdgpu if f128 is enabled.
The reason seems to be that compiler_builtins uses libcalls in the
implementation. I’m not really familiar with what libcalls are, but the
LLVM amdgpu backend explicitly does not support them.

Error message:
```
LLVM ERROR: unsupported libcall legalization
```
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants