Summary:ASTERISK-08844: [patch] conf_free freed conf
Reporter:klasstek (klasstek)Labels:
Date Opened:2007-02-19 13:28:43.000-0600Date Closed:2007-06-30 09:20:05
Versions:Frequency of
Environment:Attachments:( 0) bug
Description:Reproduce following these directions:

Relevant dialplan
exten => _4XXX,1,Meetme(${EXTEN},cDTX)

1. A calls 4666
2. A enters pin 666 (conference created)
3. B calls 4666
4. B enters invalid pin
5. A hangs up
6. B hangs up
7. core


(gdb) bt
#0  0x0000003f8702e21d in raise () from /lib64/tls/libc.so.6
#1  0x0000003f8702fa1e in abort () from /lib64/tls/libc.so.6
#2  0x0000003f87063291 in __libc_message () from /lib64/tls/libc.so.6
#3  0x0000003f87068eae in _int_free () from /lib64/tls/libc.so.6
#4  0x0000003f870691f6 in free () from /lib64/tls/libc.so.6
ASTERISK-1  0x000000000041b69f in ast_channel_free (chan=0xa021d0) at channel.c:954
ASTERISK-2  0x0000000000421bec in ast_hangup (chan=0xa021d0) at channel.c:1391
ASTERISK-3  0x0000002a9b1c8201 in conf_free (conf=0xb8ae40) at app_meetme.c:789
ASTERISK-4  0x0000002a9b1cc28e in conf_exec (chan=0x2a9ba9c7d0, data=Variable "data" is not available.
) at app_meetme.c:2015
ASTERISK-5  0x000000000044572f in pbx_extension_helper (c=0x2a9ba9c7d0, con=Variable "con" is not available.
) at pbx.c:553
ASTERISK-6 0x00000000004467e2 in __ast_pbx_run (c=0x2a9ba9c7d0) at pbx.c:2230
ASTERISK-7 0x0000000000448049 in pbx_thread (data=Variable "data" is not available.
) at pbx.c:2517
ASTERISK-8 0x0000003f8810610a in start_thread () from /lib64/tls/libpthread.so.0
ASTERISK-9 0x0000003f870c68b3 in clone () from /lib64/tls/libc.so.6
ASTERISK-10 0x0000000000000000 in ?? ()
(gdb) exit
Comments:By: Serge Vecher (serge-v) 2007-02-19 14:25:41.000-0600

what about 1.2.15. If asterisk was not built with "make don-optimize", it needs to be rebuilt and bt redone.

By: klasstek (klasstek) 2007-02-19 17:22:34.000-0600

Yes it will occur with 1.2.15


Is the only change to meetme between releases.

The steps to reproduce it can be used to verify the issue on any asterisk running as early as 1.2.9 - current 1.2.x which is as long as we've been having the issue.
I've provided a patch that should protect just the instance that occured this morning, but a more thorough evaluation of that section of code must be performed by the maintainer to ensure that the rest of the code is safe from similar circumstances.

I've recomplied with dont-optimize, but I also have my fix in place so I don't anticipate having the issue again. I may be able to revert during a maintenance window, but the bug can be independantly verifyed with the instructions provided.


By: Serge Vecher (serge-v) 2007-02-20 09:14:43.000-0600

thanks for the note, Karl.

By: Russell Bryant (russell) 2007-02-20 10:45:55.000-0600

The patch in 7647 should solve this issue.