Matthew J. Roth escribió:
Miguel Molina wrote:
I recently upgraded a production machine to asterisk 1.4.25. It seems
quite stable but after ~5 days of normal operation it core dumped with
this result:
(gdb) bt
#0 0x00516402 in __kernel_vsyscall ()
#1 0x005b3d20 in raise () from /lib/libc.so.6
#2 0x005b5631 in abort () from /lib/libc.so.6
#3 0x005ebe6b in __libc_message () from /lib/libc.so.6
#4 0x005f3b16 in _int_free () from /lib/libc.so.6
#5 0x005f7070 in free () from /lib/libc.so.6
#6 0x005e2876 in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#7 0x0809eb2a in filestream_destructor (arg=0xb1f0f200) at file.c:340
#8 0x0806e412 in ao2_ref (user_data=0xb1f0f200, delta=-1) at astobj2.c:229
#9 0x0809c1e9 in ast_closestream (f=0xb1f0f200) at file.c:902
#10 0x00b03422 in local_ast_moh_stop (chan=0xb2150fd0) at
res_musiconhold.c:1058
--- SNIP --- SNIP --- SNIP --- SNIP --- SNIP --- SNIP --- SNIP --- SNIP ---
It looks like a very random situation, as this was not a high load moment.
Also the asterisk log showed this message in the exact instant of the
failure:
[Jun 8 13:21:13] ERROR[21601] astobj2.c: refcount -1 on object 0xb1f0f200
I understand that a core dump generated by asterisk compiled with
(standard) optimized values is marked as useless information, but IMHO
it still helps to know what's failing inside it. I appreciate any input
about this, could be this a bug? A library problem? Or a server memory
problem?
Miguel,
It looks like you are running into an acknowledged bug. There are open
issues in the bug tracker for both the 1.4 and 1.6 branches:
* https://issues.asterisk.org/view.php?id=15109
* https://issues.asterisk.org/view.php?id=15195
Please create an account and add your information to the bug tracker.
Regards,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
Thank you very much for identifying this known bug. I already have an
account, so I will be posting my info on the bugtracker tomorrow.
Regarding the trace and the error asterisk throws,
[Jun 8 13:21:13] ERROR[21601] astobj2.c: refcount -1 on object 0xb1f0f200
And what astobj2.c comments say on here:
00223/* this case must never happen */
00224if (current_value 0)
00225 ast_log
http://www.asterisk.org/doxygen/1.4/logger_8c.html#0eb07c73aa8c3475ef05c5465d9b5703(LOG_ERROR
http://www.asterisk.org/doxygen/1.4/logger_8h.html#91193576ec6eae864eeba838a8c821f5, refcount
%d on object %p\n, current_value, user_data
http://www.asterisk.org/doxygen/1.4/structastobj2.html#cf53b89bb38cfc4a89c83c743970553c);
I think mmichelson is right, quoting him on bug 15123: I think, though,
that this particular issue is due to poor refcounting practices present
in Asterisk 1.4.22 (which have been fixed already, btw).. So this may
be confirming his assumption.
Regards,
--
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
