Summary:ASTERISK-11666: segfaults when calling ber_bvecfree()
Reporter:Tuomas Jormola (tjormola)Labels:
Date Opened:2008-03-17 12:06:12Date Closed:2008-03-19 15:17:26
Versions:Frequency of
Environment:Attachments:( 0) res_ldap.conf
( 1) test.ldif
Description:I'm experiencing a segfault with each call to ber_bvecfree() in res_config_ldap.c. I'm not sure how to handle that correctly. For my testing, I just commented out these calls, but that's hardly a long-term solution due to memory leaking. Asterisk is compiled against OpenLDAP 2.4.8 and OpenSSL 0.9.8g.

The asterisk I'm using is patched with patches found in these bug reports

I've attached my res_ldap.conf and an LDIF of a test SIP user. Asterisk is started with command

sudo -u asterisk asterisk -C /path/to/asterisk.conf -d -f

and the segfault is triggered with sipsak

sipsak -a test -U -s sip:test@

(test user in the LDAP has password test)

Here's the gdb backtrace

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226515568 (LWP 17596)]
0xb7cde3ca in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7cde3ca in free () from /lib/tls/i686/cmov/libc.so.6
#1  0xb78ff34a in ber_memfree_x () from /opt/local/lib/liblber-2.4.so.2
#2  0xb78ff9b7 in ber_bvfree_x () from /opt/local/lib/liblber-2.4.so.2
#3  0xb78ffa37 in ber_bvecfree_x () from /opt/local/lib/liblber-2.4.so.2
#4  0xb78ffa85 in ber_bvecfree () from /opt/local/lib/liblber-2.4.so.2
ASTERISK-1  0xb794781d in realtime_ldap_result_to_vars (table_config=0x81c4e58, ldap_result=0x82205f8, entries_count_ptr=0x0) at res_config_ldap.c:329
ASTERISK-2  0xb7948db7 in realtime_ldap_base_ap (entries_count_ptr=0x0, basedn=<value optimized out>, table_name=<value optimized out>, ap=0xb6e4a2b4 "ù\fï¶~¤ä¶¹\023ï¶\2305ï¶")
   at res_config_ldap.c:812
ASTERISK-3  0xb79497c7 in realtime_ldap (basedn=0xb6e4a198 "dc=sipusers,dc=asterisk,dc=test,dc=net", table_name=0xb6e4a098 "sip", ap=0xb6e4a2b4 "ù\fï¶~¤ä¶¹\023ï¶\2305ï¶") at res_config_ldap.c:901
ASTERISK-4  0x08099041 in ast_load_realtime (family=0xb6ef0766 "sippeers") at config.c:2024
ASTERISK-5  0xb6ec05b6 in find_peer (peer=0xb6e4a47e "test", sin=0x0, realtime=1) at chan_sip.c:3538
ASTERISK-6 0xb6eddbdd in handle_request_register (p=0x821e438, req=0xb6e4c020, sin=0xb6e4d258, e=<value optimized out>) at chan_sip.c:10234
ASTERISK-7 0xb6eec6f4 in handle_incoming (p=0x821e438, req=0xb6e4c020, sin=0xb6e4d258, recount=0xb6e4bed4, nounlock=0xb6e4bed0) at chan_sip.c:17879
ASTERISK-8 0xb6eee5fa in handle_request_do (req=0xb6e4c020, sin=0xb6e4d258) at chan_sip.c:18028
ASTERISK-9 0xb6eeead7 in sipsock_read (id=0x81c1928, fd=12, events=1, ignore=0x0) at chan_sip.c:17956
ASTERISK-10 0x080ccd34 in ast_io_wait (ioc=0x81df878, howlong=1000) at io.c:287
ASTERISK-11 0xb6ed46a3 in do_monitor (data=0x0) at chan_sip.c:18345
ASTERISK-12 0x081322eb in dummy_start (data=0x81e16c8) at utils.c:870
ASTERISK-13 0xb7c544fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
ASTERISK-14 0xb7d458ee in clone () from /lib/tls/i686/cmov/libc.so.6

Comments:By: Tilghman Lesher (tilghman) 2008-03-19 15:17:25

Since the patches in those reports are not licensed, there is no way that I can test this report.