[Home]

Summary:ASTERISK-07542: Asterisk crashes when the odbc connection is lost and res_odbc or cdr_odbc is enabled
Reporter:Morten Isaksen (misaksen)Labels:
Date Opened:2006-08-17 01:23:25Date Closed:2011-06-07 14:00:29
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt.txt
( 1) bt-20060906.txt
Description:SVN trunk rev. 39479 with patch http://bugs.digium.com/view.php?id=7693 installed.

When the database connection is down or just after a databse connection recovery asterisk sometimes crashes. As far as I can tell from gdb it is the call to SQLFreeHandle that sometimes makes it crash.

2 core-dumps is attached.

****** ADDITIONAL INFORMATION ******

Fedora Core 4
unixODBC 2.3.11
mysql-connector-odbc-3.51.12 compiled from source
MySQL 5.0.18

Comments:By: Morten Isaksen (misaksen) 2006-08-17 01:34:29

Hmm. I get APPLICATION ERROR ASTERISK-398 when I try to upload the core dump files.

You can get them from http://misak.dk/download/asterisk-coredumps/
By: Tilghman Lesher (tilghman) 2006-08-17 08:09:24

You cannot upload core dumps.  You must instead upload the corresponding stack backtraces.  Please read the notes under the MAIN section of Mantis.
By: Serge Vecher (serge-v) 2006-08-17 08:59:27

also, please read the backtrace section on the wiki:
http://www.voip-info.org/tiki-index.php?page=Asterisk%20debugging

just to be clear, the coredump will happen regardless of whether the patch for 7693 is applied or not?
By: Morten Isaksen (misaksen) 2006-08-20 11:43:26

The server is beeing moved to our datacenter. I will test this later next week.
By: Morten Isaksen (misaksen) 2006-08-24 00:43:43

I have uploadet the output from "bt full" in gdb.

vechers: I will try to test if this only happens when the patches from bug 7693 is applied later this week.
By: Tilghman Lesher (tilghman) 2006-09-05 15:58:21

Please retest with a SVN-1.2 checkout of 42054 or later.
By: Morten Isaksen (misaksen) 2006-09-05 17:31:39

The problem still exists. I have attached a new backtrace. I am using Asterisk SVN-trunk-r42058M.
By: jmls (jmls) 2006-09-10 12:58:19

I have tested this using a Progress (not postgres) odbc database connection. I am using this database for cdr. I stopped the database, made some calls (abount 20) and got errors saying that it couldn't connect. Restarted the database, made some more calls, all is fine.

Could not reproduce this bug with my configuration.
By: Serge Vecher (serge-v) 2006-09-13 09:27:19

misaksen: please do a *clean* checkout of 1.2 branch (i.e. delete the sources) or use the 1.2.12.1 tarballs and do not apply any patches for testing. Please report on the results.
By: Morten Isaksen (misaksen) 2006-09-19 13:20:16

Sorry for the delay.

I installed the 1.2.12.1 tar ball and after I shutdown MySQL for the 3. time I got a segmentation fault.

The backtrace:

(gdb) bt full
#0  ast_rtcp_fd (rtp=0x8fc2488) at rtp.c:161
No locals.
#1  0x00539593 in sip_new (i=0x8fbf868, state=0, title=0x8fc0204 "079999") at chan_sip.c:2806
       tmp = (struct ast_channel *) 0x8fa47e0
       v = Variable "v" is not available.
(gdb)
By: Serge Vecher (serge-v) 2006-09-19 14:10:01

hmm, you shutdown MySQL and the crash is in chan_sip, go figure ...
By: jmls (jmls) 2006-11-01 12:53:59.000-0600

I think that this problem was fixed in trunk sometime between July and now, as we used to have this problem, and don't now .. can someone confirm that ?
By: Tilghman Lesher (tilghman) 2007-01-09 08:29:40.000-0600

No response from reporter.  Assuming fixed by some other bug.  Reopen if this is not the case.