Summary: | ASTERISK-19941: Crash in res_config_ldap when used with realtime extensions | ||||
Reporter: | Slava Bendersky (volga629) | Labels: | realtime | ||
Date Opened: | 2012-06-01 19:10:30 | Date Closed: | 2017-02-17 12:35:05.000-0600 | ||
Priority: | Critical | Regression? | |||
Status: | Closed/Complete | Components: | Resources/res_config_ldap | ||
Versions: | 1.8.11.1 11.5.1 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | Asterisk Now 2.2 GUI and LDAP Imap voicemail registration | Attachments: | ( 0) backtrace.txt | ||
Description: | Asterisk trying to modify entries in LDAP server DS 389. Also when I got sip user registered and I trying place call it just silence, I don't see any attempts to dial in logs. [2012-05-28 00:07:18] ERROR[25975]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=,ou=People,dc=,dc= because No such attribute -- Registered SIP 'sbendersky' at 10.16.130.45:32899 [2012-05-28 00:07:20] ERROR[26001]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=sbendersky,ou=People,dc=networklab,dc=ca because Object class violation -- Unregistered SIP 'sbendersky' [2012-05-28 00:07:26] ERROR[26001]: res_config_ldap.c:1328 update_ldap: Couldn't modify 'name'='sbendersky', dn:uid=sbendersky,ou=People,dc=networklab,dc=ca because No such attribute Extension conf [users] switch => Realtime/@ [voicemail] switch => Realtime/@ [realtime-ldap] include => users include => voicemail Extconfig conf [settings] sipusers => ldap,"ou=People,dc=networklab,dc=ca",sip sippeers => ldap,"ou=People,dc=networklab,dc=ca",sip extensions => ldap,"ou=NetLabExtensions,dc=networklab,dc=ca",extensions voicemail => ldap,"ou=NetLabVoicemail,dc=networklab,dc=ca",voicemail | ||||
Comments: | By: Rusty Newton (rnewton) 2012-06-04 13:51:07.870-0500 Thanks for your comments. This does not appear to be a bug report and we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise your question in one of the resources here http://www.asterisk.org/support. I know you filed this as an Information Request, but I don't see any clear question. Rather this appears to be a "I'm seeing errors, tell me whats wrong" request, which is a support issue that someone in the community may be able to help you with. By: Slava Bendersky (volga629) 2012-06-08 18:40:23.458-0500 This last crash from June 8 2012 By: Slava Bendersky (volga629) 2012-06-08 18:44:07.188-0500 The request information was because asterisk crash constantly. And no information available about LDAP integration. I am whole asking people in irc and forums about LDAP extensions and context integration with real time LDAP driver and nobody can point into right place. Please see attached backtrace. By: Matt Jordan (mjordan) 2012-06-19 07:55:03.910-0500 Thank you for attaching the backtrace for this issue. Please note that both realtime extensions and res_config_ldap are extended support modules [1]. As such, development efforts for them come from the Asterisk Developer community, and response times may reflect that. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States By: Tzafrir Cohen (tzafrir) 2013-10-10 23:39:38.382-0500 Dominik George reported a similar issue to the Debian bug tracker: http://bugs.debian.org/725925 A few lines from the trace: #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 #1 0x00007fffa72be5d1 in realtime_multi_ldap (basedn=<optimized out>, table_name=0x7fffc6043980 "sip", ap=0x7fffc6043868) at res_config_ldap.c:976 #2 0x0000000000488dfd in ast_load_realtime_multientry (family=family@entry=0x7fffa2c6002b "sippeers") at config.c:2677 strlen is part of the ast_strdupa macro called in realtime_multi_ldap(). It is called on a variable retrieved from the variable-args struct. But is aparantly corrupted. However, the variable-args are retrieved in a previous call a few lines up to realtime_ldap_base_ap(). So I have no idea how that code should work. By: Chris Ridd (cjr) 2014-04-01 09:58:37.257-0500 I think there's a problem with the va_list (ap) being passed down into the realtime_ldap_base_ap() function, which might mutate it. The following link, which references the C standard, suggests the results of doing this are indeterminate for the caller: https://www.securecoding.cert.org/confluence/display/seccode/MSC39-C.+Do+not+call+va_arg()+on+a+va_list+that+has+an+indeterminate+value This patch fixes the problem on our servers: \[Edit: mjordan\] Removed inline patch. By: Chris Ridd (cjr) 2014-06-03 10:26:28.650-0500 Is anyone able to verify the fix I proposed and commit it? By: Matt Jordan (mjordan) 2014-06-03 11:03:29.308-0500 Patches cannot be accepted in-line. They must be attached to the issue in unified diff format after signing a license contributor agreement. Once a patch is attached to this issue, you can submit it for code review on Review Board. Please see https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process for more information. By: Jeremy Lainé (sharky) 2014-08-07 04:44:57.163-0500 Any progress on fixing this bug? By: Chris Ridd (cjr) 2014-08-07 05:46:21.525-0500 Looking at the trunk it would appear that the code was changed in r386731 to avoid this buggy behaviour: {quote} r386731 | file | 2013-04-27 13:01:29 +0100 (Sat, 27 Apr 2013) | 11 lines Add support for a realtime sorcery module. This change does the following: 1. Adds the sorcery realtime module 2. Adds unit tests for the sorcery realtime module 3. Changes the realtime core to use an ast_variable list instead of variadic arguments 4. Changes all realtime drivers to accept an ast_variable list Review: https://reviewboard.asterisk.org/r/2424/ {quote} That change is in the version 12 branch but not the version 11 branch. By: Sean Bright (seanbright) 2017-02-16 14:36:51.632-0600 Can anyone confirm whether or not this is an issue in Asterisk 13? I am not able to reproduce this. By: Sean Bright (seanbright) 2017-02-17 12:35:05.202-0600 As pointed out by Chris Ridd, the segfault you were seeing was most likely caused by using {{va_list}}s inappropriately, and that code was replaced in April 2013 in r386731. If you experience this crash with Asterisk 13 or later, please feel free to re-open. |