From owner-freebsd-isdn@freebsd.org Fri Jul 13 19:50:19 2018 Return-Path: Delivered-To: freebsd-isdn@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A6E9104A5A6 for ; Fri, 13 Jul 2018 19:50:19 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D117758E5 for ; Fri, 13 Jul 2018 19:50:18 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id A6C803365 for ; Fri, 13 Jul 2018 21:50:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id UXzYrZFi_fa8 for ; Fri, 13 Jul 2018 21:50:08 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 062A83330 for ; Fri, 13 Jul 2018 21:50:08 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id AC751508E6 for ; Fri, 13 Jul 2018 21:50:07 +0200 (CEST) Message-ID: <5B49026F.8070407@incore.de> Date: Fri, 13 Jul 2018 21:50:07 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-isdn@freebsd.org Subject: chan_capi caused segmentation fault in asterisk Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 19:50:19 -0000 Hi Hans, I run asterisk and chan_capi latest version from your git repository. After upgrading my production PBX server from FreeBSD 8 to FreeBSD 10 Stable I saw some cores of asterisk, they all looked like this: Core was generated by `/usr/local/sbin/asterisk -n -F -U asterisk'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x28782f9d in strlen () from /lib/libc.so.7 [Current thread is 1 (Thread 29c55800 (LWP 100447))] (gdb) where #0 0x28782f9d in strlen () from /lib/libc.so.7 #1 0x28777f5d in __vfprintf () from /lib/libc.so.7 #2 0x286b369e in vsnprintf () from /lib/libc.so.7 #3 0x081a40dc in __ast_string_field_ptr_build_va (mgr=0x290719b0, pool_head=0x2907197c, ptr=0x29071980, format=0x28972e9e "CAPI/%s/%s-free", ap1=0xbb733ce0 "\v", ap2=0xbb733ce0 "\v") at utils.c:1968 #4 0x080a8d4f in __ast_channel_alloc_ap (needqueue=0, state=0, cid_num=0x0, cid_name=0x0, acctcode=0x0, exten=0x0, context=0x0, linkedid=0x0, amaflag=0, file=0x2896e23d "chan_capi.c", line=2023, function=0x28972e89 "cd_alloc_pbx_channel", name_fmt=0x28972e9e "CAPI/%s/%s-free", ap1=0xbb733ce0 "\v", ap2=0xbb733ce0 "\v") at channel.c:1273 #5 0x080a96e6 in __ast_channel_alloc (needqueue=0, state=0, cid_num=0x0, cid_name=0x0, acctcode=0x0, exten=0x0, context=0x0, linkedid=0x0, amaflag=0, file=0x2896e23d "chan_capi.c", line=2023, function=0x28972e89 "cd_alloc_pbx_channel", name_fmt=0x28972e9e "CAPI/%s/%s-free") at channel.c:1378 #6 0x2894f2f2 in cd_alloc_pbx_channel (name=0xb , dest=0xbb733e4e "4982892") at chan_capi.c:2022 #7 0x2893df39 in chan_capi_request (type=0xbb734990 "CAPI", format=8, requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) at chan_capi.c:3485 #8 0x080b620f in ast_request (type=0xbb734990 "CAPI", format=8, requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) at channel.c:5740 #9 0x28ab0328 in dial_exec_full (chan=0x2a45ad1c, data=0xbb735cdc "CAPI/ISDN_NT_EUMEX/4982892", peerflags=0xbb7358e8, continue_exec=0x0) at app_dial.c:2342 #10 0x28ab5050 in dial_exec (chan=0x2a45ad1c, data=0xbb735cdc "CAPI/ISDN_NT_EUMEX/4982892") at app_dial.c:3061 #11 0x0813cfff in pbx_exec (c=0x2a45ad1c, app=0x2a807800, data=0xbb735cdc "CAPI/ISDN_NT_EUMEX/4982892") at pbx.c:1479 #12 0x081468c5 in pbx_extension_helper (c=0x2a45ad1c, con=0x0, context=0x2a45b088 "capi_to_eumex", exten=0x2a45b0d8 "4982892", priority=1, label=0x0, callerid=0x2a429a90 "039831429096", action=E_SPAWN, found=0xbb739d70, combined_find_spawn=1) at pbx.c:4739 #13 0x081484f8 in ast_spawn_extension (c=0x2a45ad1c, context=0x2a45b088 "capi_to_eumex", exten=0x2a45b0d8 "4982892", priority=1, callerid=0x2a429a90 "039831429096", found=0xbb739d70, combined_find_spawn=1) at pbx.c:5381 #14 0x08148eb5 in __ast_pbx_run (c=0x2a45ad1c, args=0x0) at pbx.c:5484 #15 0x0814a9b5 in pbx_thread (data=0x2a45ad1c) at pbx.c:5825 #16 0x081a29c6 in dummy_start (data=0x2a429aa0) at utils.c:1173 (gdb) f 7 #7 0x2893df39 in chan_capi_request (type=0xbb734990 "CAPI", format=8, requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) at chan_capi.c:3485 3485 pbx_chan = cd_alloc_pbx_channel(cep->name, dest); (gdb) list 3480 3481 /* 3482 * Allocate a PBX channel before allocating the CAPI channel, 3483 * while unlocked: 3484 */ 3485 pbx_chan = cd_alloc_pbx_channel(cep->name, dest); 3486 3487 /* have to lock the CAPI application first! */ 3488 3489 cc_mutex_lock(&p_app->lock); 3490 3491 cep = cep_root_acquire(); So the core happens when cd_alloc_pbx_channel is called with parameter cep->name, because cep is not allocated at this time (first two lines later). After changing this call to pbx_chan = cd_alloc_pbx_channel("cep_name", dest) no dumps anymore. I think you will have a better solution for this. Andreas From owner-freebsd-isdn@freebsd.org Sat Jul 14 08:43:21 2018 Return-Path: Delivered-To: freebsd-isdn@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36C8B10465BB for ; Sat, 14 Jul 2018 08:43:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0DE370B0C for ; Sat, 14 Jul 2018 08:43:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9C5662600C1; Sat, 14 Jul 2018 10:43:18 +0200 (CEST) Subject: Re: chan_capi caused segmentation fault in asterisk To: Andreas Longwitz , freebsd-isdn@freebsd.org References: <5B49026F.8070407@incore.de> From: Hans Petter Selasky Message-ID: <4f793820-3d66-c6e0-e0fb-eb10c1eb7875@selasky.org> Date: Sat, 14 Jul 2018 10:42:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B49026F.8070407@incore.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 08:43:21 -0000 On 07/13/18 21:50, Andreas Longwitz wrote: > Hi Hans, > > I run asterisk and chan_capi latest version from your git repository. > After upgrading my production PBX server from FreeBSD 8 to FreeBSD 10 > Stable I saw some cores of asterisk, they all looked like this: > > Core was generated by `/usr/local/sbin/asterisk -n -F -U asterisk'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x28782f9d in strlen () from /lib/libc.so.7 > [Current thread is 1 (Thread 29c55800 (LWP 100447))] > (gdb) where > #0 0x28782f9d in strlen () from /lib/libc.so.7 > #1 0x28777f5d in __vfprintf () from /lib/libc.so.7 > #2 0x286b369e in vsnprintf () from /lib/libc.so.7 > #3 0x081a40dc in __ast_string_field_ptr_build_va (mgr=0x290719b0, > pool_head=0x2907197c, ptr=0x29071980, format=0x28972e9e "CAPI/%s/%s-free", > ap1=0xbb733ce0 "\v", ap2=0xbb733ce0 "\v") at utils.c:1968 > #4 0x080a8d4f in __ast_channel_alloc_ap (needqueue=0, state=0, > cid_num=0x0, cid_name=0x0, acctcode=0x0, exten=0x0, context=0x0, > linkedid=0x0, > amaflag=0, file=0x2896e23d "chan_capi.c", line=2023, > function=0x28972e89 "cd_alloc_pbx_channel", name_fmt=0x28972e9e > "CAPI/%s/%s-free", > ap1=0xbb733ce0 "\v", ap2=0xbb733ce0 "\v") at channel.c:1273 > #5 0x080a96e6 in __ast_channel_alloc (needqueue=0, state=0, > cid_num=0x0, cid_name=0x0, acctcode=0x0, exten=0x0, context=0x0, > linkedid=0x0, > amaflag=0, file=0x2896e23d "chan_capi.c", line=2023, > function=0x28972e89 "cd_alloc_pbx_channel", name_fmt=0x28972e9e > "CAPI/%s/%s-free") > at channel.c:1378 > #6 0x2894f2f2 in cd_alloc_pbx_channel (name=0xb memory at address 0xb>, dest=0xbb733e4e "4982892") at chan_capi.c:2022 > #7 0x2893df39 in chan_capi_request (type=0xbb734990 "CAPI", format=8, > requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) > at chan_capi.c:3485 > #8 0x080b620f in ast_request (type=0xbb734990 "CAPI", format=8, > requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) at channel.c:5740 > #9 0x28ab0328 in dial_exec_full (chan=0x2a45ad1c, data=0xbb735cdc > "CAPI/ISDN_NT_EUMEX/4982892", peerflags=0xbb7358e8, continue_exec=0x0) > at app_dial.c:2342 > #10 0x28ab5050 in dial_exec (chan=0x2a45ad1c, data=0xbb735cdc > "CAPI/ISDN_NT_EUMEX/4982892") at app_dial.c:3061 > #11 0x0813cfff in pbx_exec (c=0x2a45ad1c, app=0x2a807800, > data=0xbb735cdc "CAPI/ISDN_NT_EUMEX/4982892") at pbx.c:1479 > #12 0x081468c5 in pbx_extension_helper (c=0x2a45ad1c, con=0x0, > context=0x2a45b088 "capi_to_eumex", exten=0x2a45b0d8 "4982892", priority=1, > label=0x0, callerid=0x2a429a90 "039831429096", action=E_SPAWN, > found=0xbb739d70, combined_find_spawn=1) at pbx.c:4739 > #13 0x081484f8 in ast_spawn_extension (c=0x2a45ad1c, context=0x2a45b088 > "capi_to_eumex", exten=0x2a45b0d8 "4982892", priority=1, > callerid=0x2a429a90 "039831429096", found=0xbb739d70, > combined_find_spawn=1) at pbx.c:5381 > #14 0x08148eb5 in __ast_pbx_run (c=0x2a45ad1c, args=0x0) at pbx.c:5484 > #15 0x0814a9b5 in pbx_thread (data=0x2a45ad1c) at pbx.c:5825 > #16 0x081a29c6 in dummy_start (data=0x2a429aa0) at utils.c:1173 > > (gdb) f 7 > #7 0x2893df39 in chan_capi_request (type=0xbb734990 "CAPI", format=8, > requestor=0x2a45ad1c, data=0xbb7351a4, cause=0xbb734bcc) > at chan_capi.c:3485 > 3485 pbx_chan = cd_alloc_pbx_channel(cep->name, dest); > (gdb) list > 3480 > 3481 /* > 3482 * Allocate a PBX channel before allocating the CAPI > channel, > 3483 * while unlocked: > 3484 */ > 3485 pbx_chan = cd_alloc_pbx_channel(cep->name, dest); > 3486 > 3487 /* have to lock the CAPI application first! */ > 3488 > 3489 cc_mutex_lock(&p_app->lock); > 3490 > 3491 cep = cep_root_acquire(); > > So the core happens when cd_alloc_pbx_channel is called with parameter > cep->name, because cep is not allocated at this time (first two lines > later). After changing this call to > pbx_chan = cd_alloc_pbx_channel("cep_name", dest) > no dumps anymore. > > I think you will have a better solution for this. > Hi, The name of the channel is updated a few lines down of that location. Using "" should be sufficient. Can you try this patch: https://github.com/hselasky/chan_capi/commit/c07f9ba0c6f18b4d782c9418a20cb76e60fb59bf --HPS