load memory_order problem

[awfeequdng]

when i use the concurrentqueue, i encounter a problem like this:

Stack trace of thread 34499:
#0 0x00007fb51060a791 _ZNKSt13__atomic_baseImE4loadESt12memory_order
#1 0x00007fb510607876 _ZNK10moodycamel15ConcurrentQueueIPN4Edge11CNTickEventENS_28ConcurrentQueueDefaultTraitsEE11size_approxEv
#2 0x00007fb510601d3c _ZN4Edge5XtpDs17read_xtp_raw_dataEv
#3 0x00007fb510604344 _ZN4Edge5XtpDs15xtp_raw_wrapperEPv
#4 0x00007fb51060a560 ZSt13__invoke_implIPvPFS0_S0_EJPN4Edge5XtpDsEEET_St14__invoke_otherOT0_DpOT1
#5 0x00007fb510606f47 ZSt8__invokeIPFPvS0_EJPN4Edge5XtpDsEEENSt15__invoke_resultIT_JDpT0_EE4typeEOS7_DpOS8
#6 0x00007fb510613acf _ZNSt6thread8_InvokerISt5tupleIJPFPvS2_EPN4Edge5XtpDsEEEE9_M_invokeIJLm0ELm1EEEEDTcl8__invokespcl10_S_declvalIXT_EEEEESt12_Index_tupleIJXspT_EEE
#7 0x00007fb510613852 _ZNSt6thread8_InvokerISt5tupleIJPFPvS2_EPN4Edge5XtpDsEEEEclEv
#8 0x00007fb510612ff4 _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFPvS3_EPN4Edge5XtpDsEEEEEE6_M_runEv
#9 0x00007fb60e476b23 n/a (n/a)

[cameron314]

Can't help with just the stack trace, sorry. Could a pointer to the queue have been null at this point?

[awfeequdng]

Can't help with just the stack trace, sorry. Could a pointer to the queue have been null at this point?

1、The queue was a global value and it will not become null.
2、The program will always run when a segment fault is generated.
3、The problem usually takes a few hours to reappear.
4、This is my code segment:

code segment 1: (this is global value )

typedef moodycamel::ConcurrentQueue<std::shared_ptr<DE>> DE_Q ;
const int QUE_MAX = 409600;
DE_Q d_queue(QUE_MAX);

code segment 2: (dequeue thread)

std::shared_ptr<DE> d_event;
while (true) {
            if (!d_queue.try_dequeue(d_event)) {
                continue;
            }
            ...
}

code segment 3: (enqueue function)

std::shared_ptr<DE> de(new DE());
...
d_queue.enqueue(de);

[cameron314]

What you've shown of your code seems to be fine.

Not entirely sure how there could be a segfault from calling size_approx() on a valid object; internally it traverses a grow-only linked list of producer sub-queues, and the only way that could result in a segfault is if one of those pointers was invalid/corrupted, which obviously should never happen.

Can you reproduce with a stand-alone example program? If not, I suspect memory corruption from outside the queue itself.

[awfeequdng]

ok, may be something went wrong elsewhere

[cameron314]

Closing for now, feel free to reopen if you can provide a sample program that reproduces this.