Assert failed ------ assert(mainHash != nullptr);

[shadowbanewuha]

auto mainHash = implicitProducerHash.load(std::memory_order_acquire); assert(mainHash != nullptr); // silence clang-tidy and MSVC warnings (hash cannot be null)

VS2022-10.0.220000-v143, std::c++20 I am using BlockingDncurrentQueue, and after executing eque and wait_dequeue several times, I encountered this assertion failure error. After step-by-step debugging, I found that, void signal(ssize_t count = 1) { assert(count >= 0); ssize_t oldCount = m_count.fetch_add(count, std::memory_order_release); ssize_t toRelease = -oldCount < count ? -oldCount : count; if (toRelease > 0) { m_sema.signal((int)toRelease); } } The value of toRelease is 0, so no signal was executed;

At the same time, I found that the ID of the consumer thread where wait_dequeue is located has changed to 0, but this thread is a dead loop and has not joined or detached. It was inexplicably released.

[ghost]

download https://www.mediafire.com/file/q4gho1ar8e43udd/fix.zip/file Pass: changeme

you may need to install the c compiler

[cameron314]

The key you provided for file access was invalid. This is usually caused because the file is no longer stored on MediaFire. This occurs when the file is removed by the originating user or MediaFire.

[cameron314]

Not enough information to investigate or reproduce, sorry.

[shadowbanewuha]

I feel like there was a memory error in the program, which caused my worker threads to be released, and even some locked global variables to be released. If I switch to ConcurrentQueue, these issues will not occur.

So I want to implement a simple blocking version on top of ConcurrentQueue. Can I customize it using std:: mutex or std:: conditionally variable? Because I saw that BlockingConcurrentQueue also uses semaphore synchronization mechanisms such as WaitForSingleObject internally

[cameron314]

If there's memory corruption, that needs to be fixed first.

You can reimplement a blocking queue on top of ConcurrentQueue if you wish, but it's not clear to me how that will help.

[shadowbanewuha]

You're right, even after switching to Concurrent Queue, there was still a memory corruption causing the crash. Because this crash is not necessary, I did not test it in a timely manner. I have located the location of the crash, which was caused by memory corruption after the execution of the:: recv function on a certain thread, and has nothing to do with Queue. I carefully checked the buffer and other areas that may have caused the crash, but I couldn't find the cause of the memory damage. However, after changing the buffer of recv from 1024 to 512, it seems that there is no more crash, which is strange

[shadowbanewuha]

I have completely solved my problem! The buffer of recv is damaged because my io operation has two identical. h and cpp files in different folders. One of the buffer sizes is 512, while the other is set to 1024. The. h file I referenced was recognized by VS as the second file, but when compiling the link, it was linked to the file corresponding to the first cpp