| Summary: | ASTERISK-21786: Segfault in MyODBC MySQL connector during reconnect attempt when connection is lost | ||
| Reporter: | A. Iglesias (arcanos) | Labels: | |
| Date Opened: | 2013-05-14 04:16:03 | Date Closed: | 2013-05-21 08:55:52 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_odbc |
| Versions: | 11.2.2 11.3.0 | Frequency of Occurrence | Occasional |
| Related Issues: | |||
| Environment: | Debian wheezy Realtime with MySQL and odbc | Attachments: | ( 0) backtrace.txt |
| Description: | Sporadically, we get a segfault in asterisk, that seems related to libmysqlclient liblibmyodbc:
Apr 22 12:43:34 servidor kernel: [64998.226065] asterisk[1011]: segfault at 4e7671 ip 00007f1088d657c0 sp 00007f1062730fb8 error 7 in libmysqlclient.so.18.0 May 14 08:04:41 servidor kernel: [1949064.842298] asterisk[31908]: segfault at 1bb8 ip 00007fb969704443 sp 00007fb94717bf50 error 4 in libmyodbc.so[7fb9696eb9696e2000+3c000] Always happens with incomings call: we receive a call, phones start ringing but asterisk is crashed. This is the dialplan for incoming calls: {noformat} exten => s,1,Set(LOCUCION=invierno) same => n,Goto(EnterCall) same => n(Festivo),Set(LOCUCION=invierno) same => n,Goto(EnterCall) same => n(Verano),Set(LOCUCION=verano) same => n,Goto(EnterCall) same => n(EnterCall),Background(locuciones/bienvenida) same => n,Dial(SIP/internalname1&SIP/internalname2&SIP/internalname3&SIP/internalname4,10,two) same => n,PlayBack(locuciones/${LOCUCION}) same => n,PlayBack(locuciones/buzon) same => n,VoiceMail(0,s) same => n,HangUp() {noformat} Find attached the backtrace file. Let me know if you need more info. Regards Alberto | ||
| Comments: | By: Matt Jordan (mjordan) 2013-05-21 08:54:26.501-0500 This crash is occurring during a reconnect attempt when the connection to the MySQL database is lost. The backtrace shows the diagnostic message received from the underlying library when this occurs: {noformat} diagnostic = "[MySQL][ODBC 5.1 Driver][mysqld-5.5.30-1.1]MySQL server has gone away\000\000\000AcX\000\000\000\000\000\225��N�\177\000\000\227��N�\177\000\000\v\000\000\000�\002\000\000\064��N�\177\000\000(\000\000\000\060\000\000\000��\027G�\177\000\000\000�\027G�\177\000\000pe!l�\177\000\000\030�\201l�\177\000\000�\003\000\000\000\000\000\000j�\210l�\177\000\000��\211l�\177\000\000\000\000\000\000\000\000\000\000��\211l�\177\000\000\030\000\000\000\060\000\062\000"... {noformat} When the underlying connection is broken, Asterisk attempts a reconnect. If the connection is not up, it disposes of the old connection by calling SQLDisconnect on the existing connection object. This is the correct action to take: while the previous execution of a statement failed, that doesn't imply that the underlying connection object has been properly disposed of. Unfortunately, this is where the crash occurs. It appears as if this is a bug in the MySQL ODBC connector. It should not be crashing during a SQLDisconnect after execution of a SQL statement has failed. You should report this but to the MySQL ODBC project here: http://bugs.mysql.com/ By: Matt Jordan (mjordan) 2013-05-21 08:55:52.896-0500 As this is not a bug in Asterisk, I'm going to go ahead and close this out as "Not a bug". However, please feel free to comment on this issue with any feedback you receive from the MySQL team, as that will help others who run into this problem with the MySQL ODBC connector. | ||