[Home]

Summary:ASTERISK-08841: Coredump from 1.4-svn in ast_channel_free()
Reporter:slimey (slimey)Labels:
Date Opened:2007-02-19 10:59:25.000-0600Date Closed:2007-06-06 19:41:03
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk 1.4-SVN coredumped.

Not sure if you can do anything with this, but I've got the coredump, and here's what looks like the relevant bits... Let me know if you want any extra info.





****** ADDITIONAL INFORMATION ******

(gdb) bt full
#0  0xb7cdad89 in free () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x08077f4b in ast_channel_free (chan=0x8275188) at channel.c:1136
       fd = -7
       headp = (struct varshead *) 0x1
       name = '\0' <repeats 72 times>, "??*\b??\234?"
#2  0x08078957 in ast_hangup (chan=0x8275188) at channel.c:1706
       res = 0
#3  0x080c0a80 in __ast_pbx_run (c=0x8275188) at pbx.c:2501
       dst_exten = '\0' <repeats 32 times>, "\220?\234?\204\026\f\b\000\000\000\000\000\000\000\000|\033?? ???\000\000\000\000SJ\022\b\024\225'\b\024\225'\b,?\234?\000\000\000\0000?\234?4?\234?\000\000\000\000@?\234?8?\234?<?\234?$??", '\0' <repeats 12 times>, "J", '\0' <repeats 19 times>, "\020\000 ?D??\020\000 ?\220\017??(?\234???\020\000 ?\220\017??$??xF#\b?;\025\b\020\000\000\000@??\200??@??????h?\234?\224??@??\f\000\000\000????\001\000\f\000\000\000P"...
       pos = 0
       digit = 0
       found = 1
       res = -1
       error = 0
#4  0x080c1651 in pbx_thread (data=0xfffffff9) at pbx.c:2561
No locals.
ASTERISK-1  0x080eebf9 in dummy_start (data=0x0) at utils.c:545
       _buffer = {__routine = 0x8067760 <ast_unregister_thread>, __arg = 0xb69cfbb0, __canceltype = -1231225936, __prev = 0x0}
       ret = (void *) 0x8279810
       a = {start_routine = 0x80c1640 <pbx_thread>, data = 0x8275188, name = 0x8279810 "pbx_thread", ' ' <repeats 11 times>, "started at [ 2585] pbx.c ast_pbx_start()"}
ASTERISK-2  0xb7ed9b63 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
ASTERISK-3  0xb7d4118a in clone () from /lib/tls/libc.so.6
No symbol table info available.




(gdb) up
#1  0x08077f4b in ast_channel_free (chan=0x8275188) at channel.c:1136
1136                    free(chan->tech_pvt);

(gdb) print chan->tech_pvt
$1 = (void *) 0x1

(gdb) print *chan
$3 = {tech = 0xb733abe0, tech_pvt = 0x1, __begin_field = 0x8275190, name = 0x82ae010 "IAX2/217.14.138.48:4569-1", language = 0x82ae02a "en", musicclass = 0x813558e "",
 accountcode = 0x813558e "", call_forward = 0x813558e "", uniqueid = 0x82ae000 "1171903031.1750", __end_field = 0x82751a8, __field_mgr = {pool = 0x82adff0, size = 128, space = 71,
   used = 57}, fds = {-1, -1, -1, -1, -1, -1, 31, -1}, music_state = 0x0, generatordata = 0x0, generator = 0x0, _bridge = 0x0, masq = 0x0, masqr = 0x0, cdrflags = 0,
 _softhangup = 0, whentohangup = 0, blocker = 0, lock = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 1, __m_lock = {__status = 0, __spinlock = 0}},
 blockproc = 0x0, appl = 0x0, data = 0x0, fdno = 0, sched = 0x0, streamid = -1, stream = 0x0, vstreamid = 0, vstream = 0x0, oldwriteformat = 0, timingfd = 31, timingfunc = 0,
 timingdata = 0x0, _state = AST_STATE_UP, rings = 0, cid = {cid_dnid = 0x822b8b8 "", cid_num = 0x8266090 "02077477689", cid_name = 0x8227d00 "02077477689",
   cid_ani = 0x81f3620 "02077477689", cid_rdnis = 0x8215bc0 "", cid_pres = 0, cid_ani2 = 0, cid_ton = 0, cid_tns = 0}, dtmfq = '\0' <repeats 79 times>, dtmff = {frametype = 0,
   subclass = 0, datalen = 0, samples = 0, mallocd = 0, mallocd_hdr_len = 0, offset = 0, src = 0x0, data = 0x0, delivery = {tv_sec = 0, tv_usec = 0}, frame_list = {next = 0x0},
   has_timing_info = 0, ts = 0, len = 0, seqno = 0}, context = "iax-incoming", '\0' <repeats 67 times>, exten = "01443882530", '\0' <repeats 68 times>, priority = 1,
 macrocontext = '\0' <repeats 79 times>, macroexten = '\0' <repeats 79 times>, macropriority = 0, dialcontext = '\0' <repeats 79 times>, pbx = 0x0, amaflags = 3, cdr = 0x0,
 adsicpe = AST_ADSI_UNAVAILABLE, zone = 0x0, monitor = 0x0, insmpl = 0, outsmpl = 0, fin = 0, fout = 0, hangupcause = 0, varshead = {first = 0x0, last = 0x0}, callgroup = 0,
 pickupgroup = 0, flags = 0, transfercapability = 0, readq = {first = 0x0, last = 0x0}, alertpipe = {-1, -1}, nativeformats = 2, readformat = 2, writeformat = 2, writetrans = 0x0,
 readtrans = 0x0, rawreadformat = 2, rawwriteformat = 2, spies = 0x0, whisper = 0x0, chan_list = {next = 0x0}, jb = {conf = {flags = 0, max_size = 0, resync_threshold = 0,
     impl = '\0' <repeats 11 times>}, impl = 0x0, jbobj = 0x0, timebase = {tv_sec = 0, tv_usec = 0}, next = 0, last_format = 0, logfile = 0x0, flags = 0},
 emulate_dtmf_digit = 0 '\0', emulate_dtmf_duration = 0, dtmf_begin_tv = {tv_sec = 0, tv_usec = 0}, datastores = {first = 0x0, last = 0x0}}
Comments:By: Serge Vecher (serge-v) 2007-02-19 13:48:24.000-0600

can you test with a more recent revision of svn (> 55400)?
By: slimey (slimey) 2007-02-19 16:21:44.000-0600

I've had a look at the SVN log for channels/chan_iax2.c and main/channel.c (the two source files implicated by the backtrace), and don't see any changes that look like they'd fix this bug (please correct me if I'm wrong).

However, I do see what looks like the problem. In main/channel.c ast_channel_free() it assumes that chan->tech_pvt is a pointer to a memory block, and passes it to free() if it's != NULL

But, channels/chan_iax2.c uses chan->tech_pvt as a storage for an int (callno) - which looks correct in the channel structure in the coredump.

So, either chan_iax2.c shouldn't use tech_pvt for an int, or ast_channel_free() shouldn't assume that it can pass tech_pvt to free() if it's != NULL

Hope this helps,

Simon
By: Joshua C. Colp (jcolp) 2007-02-20 09:22:31.000-0600

It is up to the channel driver to deallocate tech_pvt during the hangup process. If something goes wrong and it's not then the core gives an attempt to free it using free, and as you see it can be wrong/could leak memory/etc. The better question is - why did chan_iax2 not correctly clean it up? This could be better seen if there were core debug logs from when it happened.
By: slimey (slimey) 2007-03-16 08:16:52

I've just had another asterisk crash as a result of this "feature". I'm happy to come up with a patch to mask this problem - either not try to free(chan->tech_pvt) if the channel type is IAX, or force chan_iax to clear chan->tech_pvt during hangup.

Which would you prefer? As it looks like the repetition rate (for our normal office phones) is once a month, it's probably hard to test that it's fixed.
By: timrobbins (timrobbins) 2007-04-30 22:08:19

I've had this happen a bunch of times recently using the 1.4.2 release. I have a suspiscion that the crashes I saw were caused by some kind of race condition involving iax2_destroy(), possibly related to INVAL packets.

In any case, ast_channel_free() shouldn't be trying to free the channel private data - there's no way it could do it properly in the general case. It's probably better to leak memory rather than crash or corrupt the heap.
By: Joshua C. Colp (jcolp) 2007-06-06 19:41:01

This should be fixed in 1.4 as of revision 67715. If it's still an issue, please reopen. Thanks!