| Summary: | ASTERISK-07336: Asterisk dumped core on ast_db_put in db.c on no-load system | ||
| Reporter: | gblades (gblades) | Labels: | |
| Date Opened: | 2006-07-13 09:36:03 | Date Closed: | 2006-07-18 08:00:01 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Running 1.2.9.1 on two computers bot with a Digium PRI card fitted. The primary server has worked fine while running 1.2.9.1. However today the backup system core dumped. ****** ADDITIONAL INFORMATION ****** Backup system has no connections and it is stopped and started nightly while to configuration from the primary box is syncronised over. No messages were entered into the /var/log/asterisk/messages file. | ||
| Comments: | By: Serge Vecher (serge-v) 2006-07-13 09:39:00 ok: as per bug guidelines, we need a backtrace of a core, not the core file itself. Please review the backtrace section of http://www.voip-info.org/tiki-index.php?page=Asterisk%20debugging and provide the required backtrace. Note: Asterisk needs to be built with 'make dont-optimize' for backtrace to be more useful than not. By: gblades (gblades) 2006-07-13 10:12:22 #0 0xf6ebcd2d in memmove () from /lib/i686/libc.so.6 #1 0x080f408a in __bt_dleaf () #2 0x080f0a82 in __bt_put () #3 0x080c4ceb in ast_db_put (family=0xf6a77be2 <Address 0xf6a77be2 out of bounds>, keys=0x9642e50 "6152", value=0xf6a2a060 "10.0.250.197:5066:300:6152:sip:6152@10.0.250.197:5066;user=phone") at db.c:167 #4 0xf6a4cafa in ?? () ASTERISK-1 0xf6a77be2 in ?? () ASTERISK-2 0x09642e50 in ?? () ASTERISK-3 0xf6a2a060 in ?? () ASTERISK-4 0xf6a2a050 in ?? () ASTERISK-5 0x000013ca in ?? () ASTERISK-6 0x0000012c in ?? () ASTERISK-7 0x09643008 in ?? () ASTERISK-8 0x09643190 in ?? () ASTERISK-9 0x00000000 in ?? () (gdb) bt full #0 0xf6ebcd2d in memmove () from /lib/i686/libc.so.6 No symbol table info available. #1 0x080f408a in __bt_dleaf () No symbol table info available. #2 0x080f0a82 in __bt_put () No symbol table info available. #3 0x080c4ceb in ast_db_put (family=0xf6a77be2 <Address 0xf6a77be2 out of bounds>, keys=0x9642e50 "6152", value=0xf6a2a060 "10.0.250.197:5066:300:6152:sip:6152@10.0.250.197:5066;user=phone") at db.c:167 fullkey = "/SIP/Registry/6152\000`�����"��"�, '\0' <repeats 20 times>, "�232�000\000\000\000X\233�000\000\000�000\000\000\000<\233�n\000\000\000\000\000\000\000\000\000\000`6d\tUDM\231\b", '\0' <repeats 21 times>, "\021\224�\231\b\000\000\000\000\000��D��\000\000\000\000��]\t\000\000\000\000(\233�b�]\tX6d\t\004\000\000\230b\005\b�\t0\234�\234�"... key = {data = 0xf6a29a60, size = 19} data = {data = 0xf6a2a060, size = 65} res = Variable "res" is not available. 6152 is my desk phone which is configured to register on the backup system on one of its additional lines for testing purposes. I have just reconfigured some of the shortcuts on the phone (GZP-2000 rev 1.1.0.13) to use BLF (hints) and rebooted it. By: gblades (gblades) 2006-07-13 10:15:35 Note as part of the syncronisation process between askerish boxes the backup asterisk is shut down and the internal database is copied over from the live box and then the backup box restarted. This may have an impack on the bug as I see it is database related. We have been doing this syncronisation for a few weeks without problem but then I dont normally reboot my phone. My phone is the only one connected to the backup box aswell. By: Matt O'Gorman (mogorman) 2006-07-13 15:57:47 can you give another trace with make dont-optimize , build so that we can see everything. By: gblades (gblades) 2006-07-14 02:45:06 I have installed the dont-optimize version on our backup box. I cant do a backtrace as the software is different and I dont get anything meaningfull. If it crashes again I will update this ticket but it took a few weeks to crash last time. By: gblades (gblades) 2006-07-14 03:00:29 Managed to reproduce the problem. (gdb) bt full #0 0xf6ebcd2d in memmove () from /lib/i686/libc.so.6 No symbol table info available. #1 0x080ec7aa in __bt_dleaf () No symbol table info available. #2 0x080e91a2 in __bt_put () No symbol table info available. #3 0x080bbe90 in ast_db_put (family=0xf6a79d5f <Address 0xf6a79d5f out of bounds>, keys=0x9c7b440 "6152", value=0xf6a38620 "10.0.250.197:5066:300:6152:sip:6152@10.0.250.197:5066;user=phone") at db.c:167 fullkey = "/SIP/Registry/6152\000�\206�037�\206�037�, '\0' <repeats 20 times>, "\200�000\000\000\000H\201�000\000\000�000\000\000\000,\201�n\000\000\000\000\000\000\000\000\000\000�200�\001", '\0' <repeats 22 times>, "\237e\005\b\222ND�\001\000\\MD���t��\000\000\000\000b�\t(\030�030\201�c\005\b\230�t\000\000\000\000H\201�f\005\b\230�tH�t\000\000\000\00010.0.250.197\000\201�\030"... key = {data = 0xf6a38060, size = 19} data = {data = 0xf6a38620, size = 65} res = -157056624 fullkeylen = 18 __PRETTY_FUNCTION__ = "ast_db_put" #4 0xf6a57530 in ?? () No symbol table info available. ASTERISK-1 0xf6a79d5f in ?? () No symbol table info available. ASTERISK-2 0x09c7b440 in ?? () No symbol table info available. ASTERISK-3 0xf6a38620 in ?? () No symbol table info available. ASTERISK-4 0xf6a38610 in ?? () No symbol table info available. ASTERISK-5 0x000013ca in ?? () No symbol table info available. ASTERISK-6 0x0000012c in ?? () No symbol table info available. ASTERISK-7 0x09c7b5f8 in ?? () No symbol table info available. ASTERISK-8 0x09c7b780 in ?? () No symbol table info available. ASTERISK-9 0x00000000 in ?? () No symbol table info available. By: Tilghman Lesher (tilghman) 2006-07-16 15:11:45 Please delete /var/lib/asterisk/astdb and restart Asterisk on this machine and see if you can reproduce this issue. By: gblades (gblades) 2006-07-18 04:30:19 If I delete the file and start asterisk I cannot reproduce the crash. This is as I would expect because if it crashes after the overnight syncronisation then upon restarting it wont crash again until the syncronisation happens the following day. It is not a big problem for me and oviously caused by the database being copied from another box. The ability to copy the database between boxes is a usefull feature though as we use the built in database in the dialplan to decide where received faxes should be sent to etc.. By: Tilghman Lesher (tilghman) 2006-07-18 08:00:01 Correct. This crash relates entirely to hot-copying the database in an inconsistent state. I'd suggest that you either find another way to copy your database (such as using AMI to query all the rows and inserting each on the other side) or else convert to using an SQL-driven database and replicate changes between the databases. See http://www.asterisk.org/func_odbc for a module that will allow you to do this. | ||