Hi Daniel,
Did you manage to get a chance to look at all the dumps I sent?
Cheers,
Dirk
On 18-07-16 11:58, Daniel-Constantin Mierla wrote:
> If you didn't get other crashes, I can't think of anything else that can
> help from the backtrace.
>
> Cheers,
> Daniel
>
On 07/18/2016 11:58 AM, Daniel-Constantin Mierla wrote:
>
> OK -- just to have full picture -- did you experienced more crashes than
> the two ones you reported?
Yes, we experienced three more crashes
I will send you these gdb bt full crashes directly.
> I see -- can you describe a bit the chan
On 18/07/16 11:23, Dirk Teurlings - Signet B.V. wrote:
> On 07/18/2016 10:49 AM, Daniel-Constantin Mierla wrote:
>> have you run with -x qm before reverting to 4.2?
> No we didn't, as I didn't know what the effects would be, it's a live
> server so we don't want to try changes before testing.
OK
On 07/18/2016 10:49 AM, Daniel-Constantin Mierla wrote:
> have you run with -x qm before reverting to 4.2?
No we didn't, as I didn't know what the effects would be, it's a live
server so we don't want to try changes before testing.
> Is the same config you run with 4.2 and 4.4?
Not at the moment,
Hello,
have you run with -x qm before reverting to 4.2?
Is the same config you run with 4.2 and 4.4?
The version 4.2.8 has qm as default memory manager. In 4.4, fm is the
default one but qm can be selected at startup with -x. The main
difference is that qm has more safety checks for detecting do
Hi Daniel,
Had to revert back to our old 4.2.5 for now, we can't cope with these
crashes. Anyway, here are all the modules currently loaded by our config.
sqlops
db_mysql
mi_fifo.so
kex.so
corex.so
tm.so
tmx.so
sl.so
rr.so
pv.so
maxfwd.so
usrloc.so
registrar.so
textops.so
siputils.so
xlog.so
sani
The content of dlg is not valid, likely freed. Can you run with -x qm
and see if you get new error messages?
Also, what modules are you using, specially interested in those using
dialog module, such as cnxcc or presence dialog info?!?!
Cheers,
Daniel
On 15/07/16 13:06, Dirk Teurlings - Signet B
(gdb) frame 1
#1 dlg_unref (dlg=dlg@entry=0x7f585c494b40, cnt=cnt@entry=1) at
dlg_hash.c:921
921 dlg_lock( d_table, d_entry);
(gdb) p *dlg
$1 = {ref = 793790803, next = 0xa0d4b4f20303032, prev =
0x504953203a616956, h_id = 808333871, h_entry = 1346655535, state =
774976288, lifetime = 7
From the second crash, can you get:
frame 1
p *dlg
So far it looks like either to a double free or some buffer overflow...
Cheers,
Daniel
On 15/07/16 10:51, Dirk Teurlings - Signet B.V. wrote:
> Just got another segfault.
>
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db
Hi, first crash:
(gdb) info locals
cb =
__FUNCTION__ = "run_dlg_callbacks"
(gdb) bt full
#0 run_dlg_callbacks (type=type@entry=64, dlg=dlg@entry=0x7fceb400e2f0,
req=req@entry=0x7fced4f093c8, rpl=rpl@entry=0x0, dir=,
dlg_data=dlg_data@entry=0x0)
at dlg_cb.c:253
cb =
__FUNCTIO
Hello,
can you send the output of gdb commands:
info locals
bt full
Cheers,
Daniel
On 15/07/16 10:06, Dirk Teurlings - Signet B.V. wrote:
> Hi,
>
> Running Kamailio on Debian from the Kamailio repository with 4.4.2
> stable (unpatched). Getting some random segfaults with it now, here's
> the
Just got another segfault.
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_get (v=0x7f6264d11378) at
Hi,
Running Kamailio on Debian from the Kamailio repository with 4.4.2
stable (unpatched). Getting some random segfaults with it now, here's
the relevant backtrace from the generated core.
Core was generated by `/usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.'.
Pro
13 matches
Mail list logo
