[asterisk-bugs] [Asterisk 0015984]: QUEUE_MEMBER and QUEUE_MEMBER_COUNT tries to destroy queue, leading to segmentation fault

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15984 
====================================================================== 
Reported By:                atis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15984
Category:                   Applications/app_queue
Reproducibility:            have not tried
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 220631 
Request Review:              
====================================================================== 
Date Submitted:             2009-09-29 10:12 CDT
Last Modified:              2009-09-29 16:20 CDT
====================================================================== 
Summary:                    QUEUE_MEMBER and QUEUE_MEMBER_COUNT tries to destroy
queue, leading to segmentation fault
Description: 
Loops for queue_function_qac and queue_function_qac_dep are identical, so
both those functions should be affected.

Backtrace shows that queue_unref is calling destroy_queue, which however
calls queue_unref again, thus leading to recursion, limited by queue member
count.

Backtrace attached
====================================================================== 

---------------------------------------------------------------------- 
 (0111552) atis (reporter) - 2009-09-29 16:20
 https://issues.asterisk.org/view.php?id=15984#c111552 
---------------------------------------------------------------------- 
It might be significant, that this crash occured just the same second,
safe_asterisk started this instance (after different crash), and there were
some testing calls already knocking at the door.

However I tried just killing asterisk multiple times, and this couldn't be
reproduced that easy.

I also noticed that I have something in mmlog matching the time of this
core dump.

1254234079 - New session (2009-09-29 07:21:19)
WARNING: Freeing unused memory at 0x2aaaad9ac0b8, in __ao2_ref of
astobj2.c, line 290
WARNING: Freeing unused memory at 0x9d4dd8, in logger_thread of logger.c,
line 988
WARNING: Freeing unused memory at 0x2aaaad9abb38, in __ao2_ref of
astobj2.c, line 290
WARNING: Freeing unused memory at 0x9d4dd8, in logger_thread of logger.c,
line 988
WARNING: Freeing unused memory at 0x2aaaad9ac0b8, in __ao2_ref of
astobj2.c, line 290
WARNING: Freeing unused memory at 0x2aaaad9abb38, in __ao2_ref of
astobj2.c, line 290
WARNING: Freeing unused memory at 0x9d4dd8, in destroy_queue of
app_queue.c, line 1432
WARNING: Freeing unused memory at 0x2aaaad9ac0b8, in __ao2_ref of
astobj2.c, line 290
WARNING: Freeing unused memory at 0x2aaaad9abb38, in __ao2_ref of
astobj2.c, line 290
WARNING: Low fence violation at 0x2aaaad9abd18, in ..Z of logger.c, line
5950484
1254234098 - New session (2009-09-29 07:21:38) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-29 16:20 atis           Note Added: 0111552                          
======================================================================