Summary: | ASTERISK-13163: Asterisk can crash when database schema is changed | ||
Reporter: | Benny Amorsen (amorsen) | Labels: | |
Date Opened: | 2008-12-03 10:35:42.000-0600 | Date Closed: | 2011-06-07 14:00:17 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | CDR/cdr_adaptive_odbc |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | I had a CDR database on MySQL with a column userfield, which I wanted to change to be called hangupcause. I did this in MySQL: alter table cdr change column userfield hangupcause varchar(255) NOT NULL default ''; I got this: [Dec 3 17:20:12] WARNING[21039] res_odbc.c: SQL Execute returned an error -1: 42S22: [MySQL][ODBC 3.51 Driver][mysqld-5.0.51a-log]Unknown column 'userfield' in 'field list' (87) [Dec 3 17:20:12] WARNING[21039] res_odbc.c: SQL Execute error -1! Attempting a reconnect... [Dec 3 17:20:12] WARNING[21039] res_odbc.c: Connection is down attempting to reconnect... [Dec 3 17:20:12] DEBUG[21039] res_odbc.c: Disconnected 0 from cdr [cdr] And then this: Dec 3 17:20:12 lpbx02 kernel: asterisk[20978]: segfault at 430 ip 0013f9d9 sp b55e47f0 error 4 in libodbc.so.1.0.0[126000+70000] Having it as severity "crash" is perhaps overkill, since noone sane will change database schema while keeping asterisk running, but it DID crash... Fedora 10 with: asterisk-1.6.0.1-2.fc10.i386 asterisk-dahdi-1.6.0.1-2.fc10.i386 asterisk-odbc-1.6.0.1-2.fc10.i386 | ||
Comments: | By: Tilghman Lesher (tilghman) 2008-12-04 15:57:15.000-0600 I'm still going to need a backtrace, as required in the bug guidelines. By: Benny Amorsen (amorsen) 2008-12-05 01:59:07.000-0600 That is unfortunately impossible, since ulimit -c was 0. By: Tilghman Lesher (tilghman) 2008-12-15 18:14:29.000-0600 Unfortunately, without a backtrace, there is very little I can do. In fact, given that it crashes within libodbc, it is very likely either a UnixODBC crash or a crash of the backend driver. While this may have taken down Asterisk, the problem lies in a body of code outside of our control. |