Hi @AVFedorov , @petekelly - I'm taking over this issue.
If any of you could describe how to reproduce this crash (like what kind of
call needs to be canceled, etc), it will be great to sort it out asap.
Thanks and regards,
Bogdan
---
Reply to this email directly or view it on GitHub:
Hi @ar45 , most probably because of historical reasons. May I ask what seems to
be the problem in your case ?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/576#issuecomment-127941488___
Devel mailing
@seanchann , any way to reproduce the kind of errors you get ?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/551#issuecomment-127941714___
Devel mailing list
Devel@lists.opensips.org
@dsandras , the problem was narrowed down to mi_json module when handling ASYNC
MI commands. I'm trying to reach @shimaore (the author of the module) to sort
this out.
In the mean while, should I try a patch for make mi_json to run all MI commands
in SYNC mode (to avoid the existing problem
@liviuchircu , that will happen when you try to use any Variable exported by a
module (not provided by core) without loading that particular module.
It is not particular to json module only.
---
Reply to this email directly or view it on GitHub:
Hi Bogdan, following @mqandeel, xmlrpc-ng would suffer of the same bug.
From my point of view, things could be done in SYNC mode... Thanks for having
a look !
---
Reply to this email directly or view it on GitHub:
@dsandras, not so sure about @mqandeel report (if indeed related to this or
something completely different) as the error you reported is 100% generated by
mi_json:
Jun 11 15:55:45 golgoth05 opensips[31577]:
ERROR:**mi_json**:mi_json_flush_data: Unexpected NULL mi handler!
and mi_json has
Indeed. But I am not sure if it is a bug in mi_json or in the sublayer shared
by all mi modules actually.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/552#issuecomment-127948815___
Devel mailing
@DMOsipov, this happens due a poor implementation of the b2b auth in
combination with usage of local route (for b2b INVITEs). Unfortunately the fix
is not trivial - to be honest, I do not even have a straight solution to this.
Nevertheless, I will try to come up with a something on this.
During running a sipp-scenario against an opensips2.1 doing tls-udp
traversing we are able to easily crash this opensips within seconds. As soon as
we disable tcp_accept_aliases the crashes are gone. We are heavily generating
new tls-sessions (around 1000 per second), so we will reuse
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSIPS/opensips/pull/590
-- Commit Summary --
* added extended usrloc events, provided extended information
* Added version field in the header of bin protocol, to avoid compatibility
problems
*
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 3dfc83cb254f150d2e6dbbb49f48ec9927be3a3c
https://github.com/OpenSIPS/opensips/commit/3dfc83cb254f150d2e6dbbb49f48ec9927be3a3c
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-05 (Wed, 05 Aug
Closed #587 via 3dfc83cb254f150d2e6dbbb49f48ec9927be3a3c.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/587#event-374389191___
Devel mailing list
Devel@lists.opensips.org
Hi Bogdan, yes, latest 2.1code from GIT was used. requested output:
```
#0 0x0052247a in tcpconn_add_alias (id=1358, port=5063, proto=3) at
net/net_tcp.c:766
c = 0x7f311a308470
hash = 938
a = 0x7f31115f35d8
__FUNCTION__ = tcpconn_add_alias
```
---
Reply
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 570d7d749f2f0f03eb86bdd10425d08679dce625
https://github.com/OpenSIPS/opensips/commit/570d7d749f2f0f03eb86bdd10425d08679dce625
Author: root evilla...@gmail.com
Date: 2015-08-05 (Wed, 05 Aug 2015)
15 matches
Mail list logo
