klwilson227 opened a new issue #7565:
URL: https://github.com/apache/pulsar/issues/7565


   **Describe the bug**
   After the execution of the close method, a segmentation violation can be 
seen from time to time when either the keepAliveTimer or the consumerStatsTimer 
pops during or soon after the close operation. The segv shows the following 
stack trace:
   
   Signal: [0x000000000000000b] PID: [0x0000000000048988] PC: 
[0x00007f02e615c1b6] FP: [0x00007f02c40d0180] SIGSEGV: SEGV_MAPERR SI_ADDR : 
[0x0000000000000000]
   (_ZN6Basics9Backtrace11DoBacktraceEiiPvS1_+0x8f1) [0x4074ca1]
   (_ZN6Basics20GlobalSignalHandlers14logFatalSignalEiPvS1_+0xd2) [0x40c91b2]
   (_ZN6BasicsL26sigHandler_withinATryCatchEiP7siginfoPv+0x2c2) [0x40ca6b2]
   (_ZN6BasicsL10sigHandlerEiP7siginfoPv+0xe) [0x40ca77e]
   (_L_unlock_13+0x34) [0x7f03dc81e5d0]
   
(_ZN5boost4asio20basic_deadline_timerINS_10posix_time5ptimeENS0_11time_traitsIS3_EENS0_22deadline_timer_serviceIS3_S5_EEE16expires_from_nowERKNS2_13time_durationE+0x16)
 [0x7f02e615c1b6]
   (UNKNOWN) [0x7f02e61d3768]
   (UNKNOWN) [0x7f02e61d3de3]
   (_ZN5boost4asio3ssl7contextD1Ev+0xdc1) [0x7f02e61e57b1]
   (_ZN5boost4asio6detail15task_io_service3runERNS_6system10error_codeE+0x311) 
[0x7f02e6121331]
   
(_ZNSt14_Function_base13_Base_managerISt5_BindIFSt7_Mem_fnIMN6pulsar12ConsumerImplEFvNS3_6ResultENS3_9MessageIdESt8functionIFvS5_S6_EEEESt10shared_ptrIS4_ESt12_PlaceholderILi1EESF_ILi2EES9_EEE10_M_managerERSt9_Any_dataRKSL_St18_Manager_operation+0xaf6)
 [0x7f02e611e2c6]
   
(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFSt7_Mem_fnIMN6pulsar15ExecutorServiceEFvSt10shared_ptrIN5boost4asio10io_serviceEEEEPS5_SA_EEvEEE6_M_runEv+0x52)
 [0x7f02e6122772]
   
(_ZNSt11this_thread11__sleep_forENSt6chrono8durationIlSt5ratioILl1ELl1EEEENS1_IlS2_ILl1ELl1000000000EEEE+0x1c0)
 [0x7f03dcde2070]
   (start_thread+0xc5) [0x7f03dc816dd5]
   (clone+0x6d) [0x7f03dc13402d]
   
   Steps to reproduce the behavior:
   This problem is difficult to reproduce without tweaking the source base. As 
this exception is based on timing. 
   To stress the environment add a short sleep to the ClientConnection::close() 
just after the mutex has been granted. This will give a long window for all of 
the timers to pop and align on the mutex if necessary. 
   
   **Expected behavior**
   Even with the sleep in place the timers should pop and be handled. So that 
they do not cause a segmentation violation and bring down the application for 
which the client is embedded with. 
   
   **Screenshots**
   N/A
   
   **Desktop (please complete the following information):**
    - OS: Centos
   
   **Additional context**
   Add any other context about the problem here.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to