chashmap issueshttps://gitlab.redox-os.org/redox-os/chashmap/-/issues2022-08-05T22:26:22Zhttps://gitlab.redox-os.org/redox-os/chashmap/-/issues/14Unsoundness in owning_ref2022-08-05T22:26:22ZAlan SomersUnsoundness in owning_refowning_ref 0.4.4 has several documented soundness issues. These trigger alerts in every project using chashmap. As owning_ref seems to be unmaintained, consumers will probably have to find another way. Current versions of parking_lot ...owning_ref 0.4.4 has several documented soundness issues. These trigger alerts in every project using chashmap. As owning_ref seems to be unmaintained, consumers will probably have to find another way. Current versions of parking_lot don't even use owning_ref. One option might be the fork owning-ref (note the dash instead of underscore).
https://rustsec.org/advisories/RUSTSEC-2022-0040https://gitlab.redox-os.org/redox-os/chashmap/-/issues/13Please release new minor version with updated `parking_lot` dependency2021-06-03T10:48:03ZNikolai GolubPlease release new minor version with updated `parking_lot` dependencyI've seen that parking lot was updated in this commit: https://gitlab.redox-os.org/redox-os/chashmap/-/commit/a241acaab2149af18a731b067ab8b25e2442cee4
Could you please release new version to crates.io?I've seen that parking lot was updated in this commit: https://gitlab.redox-os.org/redox-os/chashmap/-/commit/a241acaab2149af18a731b067ab8b25e2442cee4
Could you please release new version to crates.io?https://gitlab.redox-os.org/redox-os/chashmap/-/issues/12Different behavior between upsert and alter with regards to key identity2020-06-25T09:39:54ZRuslan MustakovDifferent behavior between upsert and alter with regards to key identityWith methods such as `upsert` and `alter` the important part of behavior is what they do with they key when the value if updated. Even if keys are equal, their identity may be (and often is) actually different and this is important for c...With methods such as `upsert` and `alter` the important part of behavior is what they do with they key when the value if updated. Even if keys are equal, their identity may be (and often is) actually different and this is important for certain applications.
In `chashmap` library it is not documented what happens to key in those methods. In the current implementation they do opposite things: `upsert` preserves the old key on updates, while `alter` always inserts the new key. The behavior of `upsert` makes much more sense to me.
At the very least this should be documented, and ideally the behavior should be consistent.https://gitlab.redox-os.org/redox-os/chashmap/-/issues/11Async await support2020-05-22T08:07:36ZRakshith RaviAsync await supportWould be great to have async await support in this, so that we can do things like:
```rust
let mut map = CHashMap::new();
let item = map.get("test").await;
map.insert("test2", "some value").await;
```Would be great to have async await support in this, so that we can do things like:
```rust
let mut map = CHashMap::new();
let item = map.get("test").await;
map.insert("test2", "some value").await;
```https://gitlab.redox-os.org/redox-os/chashmap/-/issues/10Implement Sync + Send for Write/Read Guard2020-03-03T18:43:47ZlinxiuleiImplement Sync + Send for Write/Read GuardImplement Sync + Send for Write/Read Guard, so the users could invoke async function with keysImplement Sync + Send for Write/Read Guard, so the users could invoke async function with keyshttps://gitlab.redox-os.org/redox-os/chashmap/-/issues/9scan_xxx method could panic2021-08-04T17:17:23ZAlexscan_xxx method could panicwhen buckets don't exist Bucket::Empty(), just Bucket::Removed() and Bucket::Contains(k,v) if we exec scan_xxx method,
the key doesn't match every existed bucket then the scan_xxx method will trigger panic.when buckets don't exist Bucket::Empty(), just Bucket::Removed() and Bucket::Contains(k,v) if we exec scan_xxx method,
the key doesn't match every existed bucket then the scan_xxx method will trigger panic.https://gitlab.redox-os.org/redox-os/chashmap/-/issues/8Support returning additional data from `CHashMap::alter`2020-02-09T15:50:16ZDiggory BlakeSupport returning additional data from `CHashMap::alter`Something like:
```rust
pub fn alter_and_return<F, R>(&self, key: K, f: F) -> R
where F: FnOnce(Option<V>) -> (Option<V>, R);
```
This allows the caller to make use of the fact that the passed function will be called precisely once...Something like:
```rust
pub fn alter_and_return<F, R>(&self, key: K, f: F) -> R
where F: FnOnce(Option<V>) -> (Option<V>, R);
```
This allows the caller to make use of the fact that the passed function will be called precisely once. The workaround right now is to capture an `Option<R>` by mutable reference and then populate the option from within the closure, but it means that the caller must unwrap the option later on and handle the `None` case which is not actually possible.https://gitlab.redox-os.org/redox-os/chashmap/-/issues/7Hashers2020-01-20T22:39:21ZTom KaitchuckHashersI wanted to try out chashmap with [aHash](https://github.com/tkaitchuck/aHash) but I noticed that the hasher which is used is not configurable as it is with the standard HashMap.
Is there any interest in making this configurable or just ...I wanted to try out chashmap with [aHash](https://github.com/tkaitchuck/aHash) but I noticed that the hasher which is used is not configurable as it is with the standard HashMap.
Is there any interest in making this configurable or just switching to aHash outright?
If so, I can send a PR.https://gitlab.redox-os.org/redox-os/chashmap/-/issues/5Race Condition using CHashMap::alter with many (40+) threads2019-11-19T18:09:20ZJonas BushartRace Condition using CHashMap::alter with many (40+) threadsI am using CHashMap as the backing storage for memorization of expensive computation. The computation is parallelized with Rayon and stored in the hashmap, if the result does not exist yet. For this I use the `CHashMap::alter` function, ...I am using CHashMap as the backing storage for memorization of expensive computation. The computation is parallelized with Rayon and stored in the hashmap, if the result does not exist yet. For this I use the `CHashMap::alter` function, as it allows me to perform a `get_or_insert_new` type of operation.
If I scale this to many threads, I can reliably cause thread panics.
```
thread '<unnamed>' panicked at 'No free buckets found', src/libcore/option.rs:1187:5
```
The stacktrace does not mention any function of chashmap, probably due to inlining, which is why I ommit it here.
However, the error message points to this line in [lib.rs:333](https://gitlab.redox-os.org/redox-os/chashmap/blob/master/src/lib.rs#L333).
I cannot reproduce this issue if I set `RAYON_NUM_THREADS=30`, but with 40 threads it is already quite reliable if not 100% reproducible. More threads make the problem better reproducible.https://gitlab.redox-os.org/redox-os/chashmap/-/issues/4Overflowing Add during `insert`?2019-09-22T01:00:52ZSpencer JudgeOverflowing Add during `insert`?Hello - have run into this panic a few times and unfortunately I'm totally unable to narrow down a repro but I wanted to call it to your attention in any case. If I get any better information I will update this ticket. Thanks for your wo...Hello - have run into this panic a few times and unfortunately I'm totally unable to narrow down a repro but I wanted to call it to your attention in any case. If I get any better information I will update this ticket. Thanks for your work on this crate!
```
---- client_tests::some_test stdout ----
thread 'xxx' panicked at 'attempt to add with overflow', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:955:19
stack backtrace:
0: 0x5652428d9d33 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6485381528590a55
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: 0x5652428d560b - std::sys_common::backtrace::_print::h49a82ae9552e35c7
at src/libstd/sys_common/backtrace.rs:71
2: 0x5652428d8a26 - std::panicking::default_hook::{{closure}}::he20974adbefcc046
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: 0x5652428d874e - std::panicking::default_hook::he4af6af4ac7fef7b
at src/libstd/panicking.rs:208
4: 0x5652428d912f - std::panicking::rust_panic_with_hook::h057ff03eb4c8000f
at src/libstd/panicking.rs:474
5: 0x5652428d8cb1 - std::panicking::continue_panic_fmt::ha6d6ae144369025b
at src/libstd/panicking.rs:381
6: 0x5652428d8b95 - rust_begin_unwind
at src/libstd/panicking.rs:308
7: 0x5652428ee8bc - core::panicking::panic_fmt::hc4f83bfed80aeabd
at src/libcore/panicking.rs:85
8: 0x5652428ee7fb - core::panicking::panic::h62fdcfa056e70982
at src/libcore/panicking.rs:49
9: 0x5652423ee204 - chashmap::CHashMap<K,V>::expand::he7a23d818ea1d4af
at /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:955
10: 0x5652423ee3c7 - chashmap::CHashMap<K,V>::insert::h1f25a247704603f4
at /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:806
```https://gitlab.redox-os.org/redox-os/chashmap/-/issues/3May have race condition2019-07-24T07:31:41ZCloudsMay have race conditionI'm running get_mut and contains_key at same time and it crashed warning
thread 'main' panicked at '`CHashMap` scan failed! No entry found.'
here's some backtrace
```
thread 'main' panicked at '`CHashMap` scan failed! No entry found.', /...I'm running get_mut and contains_key at same time and it crashed warning
thread 'main' panicked at '`CHashMap` scan failed! No entry found.'
here's some backtrace
```
thread 'main' panicked at '`CHashMap` scan failed! No entry found.', /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:246:9
stack backtrace:
thread '<unnamed>' panicked at '`CHashMap` scan_mut failed! No entry found.', /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:270:9
0: 0x55d3eaffb083 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6485381528590a55
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: 0x55d3eaff698b - std::sys_common::backtrace::_print::h49a82ae9552e35c7
at src/libstd/sys_common/backtrace.rs:71
2: 0x55d3eaff9d36 - std::panicking::default_hook::{{closure}}::he20974adbefcc046
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: 0x55d3eaff9ac9 - std::panicking::default_hook::he4af6af4ac7fef7b
at src/libstd/panicking.rs:211
4: 0x55d3eaffa43f - std::panicking::rust_panic_with_hook::h057ff03eb4c8000f
at src/libstd/panicking.rs:474
5: 0x55d3eaf77e47 - std::panicking::begin_panic::h1520528c0316001e
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:408
6: 0x55d3ead998fa - chashmap::Table<K,V>::scan::h7ebf45dd7a7b8eab
at /home/clouds/Projects/test/<::std::macros::panic macros>:4
7: 0x55d3ead99a7b - chashmap::Table<K,V>::lookup::h387b6bccf8779723
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:344
8: 0x55d3ead9a6fd - chashmap::CHashMap<K,V>::contains_key::hc7390491d5027d06
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:742
9: 0x55d3ead9a4aa - chashmap::CHashMap<K,V>::insert_new::h1534ec6ef723f81f
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:772
12: 0x55d3eae339fe - test::main::{{closure}}::h697741818c002ad8
at trade/src/main.rs:179
13: 0x55d3eadbf226 - crossbeam_utils::thread::scope::{{closure}}::h556837b14d3cdef4
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-utils-0.6.5/src/thread.rs:161
14: 0x55d3eaddb19f - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::hc88dde0b2d08071f
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panic.rs:315
15: 0x55d3eadefd84 - std::panicking::try::do_call::h6b17391b68d20804
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:293
16: 0x55d3eaffd169 - __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:85
17: 0x55d3eadefb78 - std::panicking::try::hec3cda4721e08fee
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:272
18: 0x55d3eaddb221 - std::panic::catch_unwind::hea1fcc97098536d8
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panic.rs:394
19: 0x55d3eadbebee - crossbeam_utils::thread::scope::hbad7e7bd19e60eca
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-utils-0.6.5/src/thread.rs:161
20: 0x55d3eae4786f - test::main::hd838a638ee2d5a42
at test/src/main.rs:173
21: 0x55d3eae2866f - std::rt::lang_start::{{closure}}::h672f29521b2597ed
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
22: 0x55d3eaff9e42 - std::panicking::try::do_call::hc3d8373a0b215f51
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:293
23: 0x55d3eaffd169 - __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:85
24: 0x55d3eaffaa0c - std::rt::lang_start_internal::he5218c8b95d395f2
at src/libstd/panicking.rs:272
at src/libstd/panic.rs:394
at src/libstd/rt.rs:48
25: 0x55d3eae28648 - std::rt::lang_start::h5d5746182b8a73da
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
26: 0x55d3eae47bd9 - main
27: 0x7fae4d426ee2 - __libc_start_main
28: 0x55d3ead7d16d - _start
29: 0x0 - <unknown>
stack backtrace:
0: 0x55d3eaffb083 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6485381528590a55
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: 0x55d3eaff698b - std::sys_common::backtrace::_print::h49a82ae9552e35c7
at src/libstd/sys_common/backtrace.rs:71
2: 0x55d3eaff9d36 - std::panicking::default_hook::{{closure}}::he20974adbefcc046
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:197
3: 0x55d3eaff9ac9 - std::panicking::default_hook::he4af6af4ac7fef7b
at src/libstd/panicking.rs:211
4: 0x55d3eaffa43f - std::panicking::rust_panic_with_hook::h057ff03eb4c8000f
at src/libstd/panicking.rs:474
5: 0x55d3eaf77e47 - std::panicking::begin_panic::h1520528c0316001e
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/panicking.rs:408
6: 0x55d3ead99d0a - chashmap::Table<K,V>::scan_mut::h3ee39527562190b8
at /home/clouds/Projects/test/<::std::macros::panic macros>:4
7: 0x55d3ead9862b - chashmap::Table<K,V>::lookup_mut::hffa9a0625e034afd
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:365
8: 0x55d3ead9b0af - chashmap::CHashMap<K,V>::get_mut::{{closure}}::haf8c62ff3ba35133
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:716
9: 0x55d3eadd833f - owning_ref::OwningHandle<O,H>::new_with_fn::hda28a60b929e5513
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/owning_ref-0.3.3/src/lib.rs:832
10: 0x55d3ead9aed0 - chashmap::CHashMap<K,V>::get_mut::h8696c2733f298f57
at /home/clouds/.cargo/registry/src/github.com-1ecc6299db9ec823/chashmap-2.2.2/src/lib.rs:714
11: 0x55d3eae4786f - test::main::hd838a638ee2d5a42
at test/src/main.rs:206
```https://gitlab.redox-os.org/redox-os/chashmap/-/issues/1Deadlock on insert2019-09-22T13:18:55ZKilyén Attila ÖrsDeadlock on insertHi,
I was trying to use CHashMap for my genetic algorithm project, and I found out that insert deadlocks my code.
You can find the full code [here](https://github.com/AttilaOrs/_tempBug/commit/7d087eed8cecac718445cba03999bbeedc5c1585). (...Hi,
I was trying to use CHashMap for my genetic algorithm project, and I found out that insert deadlocks my code.
You can find the full code [here](https://github.com/AttilaOrs/_tempBug/commit/7d087eed8cecac718445cba03999bbeedc5c1585). (I'm planning to release under open-source license however in a more acceptable state.)
One may simply run the code with cargo run --release.
As you may see the code blocks at a "try to insert" print out after a while, never reaching the "insert done". Those print out are in "concurentMap_divider.rs".
I am doing multiple insertions at the same time. I suspect that the scanning and the inserting process is int conflict because:
* if I use insert_new the code never blocks
* after a short debug I think that at least one of the threads blocks at lines `if ret.is_none() { self.expand(lock);}`
If someone gives me some hints I can try to resolve myself, however, I feel a little bit lost. (And I have no idea how to debug further.)
Best regards,
Örshttps://gitlab.redox-os.org/redox-os/chashmap/-/issues/15CHashMap support Borrow?2023-10-15T18:22:18ZJeremy SollerCHashMap support Borrow?*Created by: sbant*
The std::collection::HashMap 's get function like this:
fn get<Q: ?Sized>(&self, k: &Q) -> Option<&V> where K: Borrow<Q>, Q: Hash + Eq
can CHashMap support the Borrow Trait?
let map = CHashMap::new();
let s =...*Created by: sbant*
The std::collection::HashMap 's get function like this:
fn get<Q: ?Sized>(&self, k: &Q) -> Option<&V> where K: Borrow<Q>, Q: Hash + Eq
can CHashMap support the Borrow Trait?
let map = CHashMap::new();
let s = "some str";
so can use map.get(s), not map.get(&s.to_string())