Closed #2286.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2286#event-3259192174___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
OK. Reopen if pops up again.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2286#issuecomment-617599039___
Kamailio (SER) - Development Mailing List
I manually cherry-picked the patch into my clone of 5.3 before it was
backported, and haven’t had a crash since.
However, I also hadn’t had a crash the few days prior.
So, it remains to be seen what happens. But I am optimistic this will fix the
issue. Thank you very much to you both!
—
Sent
@abalashov can you try with latest version from stable branch? @grumvalski
backported the patch. The avps lists should be no longer there.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@grumvalski - you can backport to the branches relevant fo the fix. If not, I
will do it before next releases.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Sorry the mail was sent before ending by accident.
Thanks for looking into it and fixing it Daniel. For sure it should be
backported.
Cheers,
Federico
On Sat, Apr 18, 2020 at 9:23 AM Federico Cabiddu
wrote:
> Hi Daniel,
> you are absolutely right and that part of code is for sure wrong.
Hi Daniel,
you are absolutely right and that part of code is for sure wrong. Those
lines have been there since the beginning and for sure due to my lack of
understanding of transactions's internals and avps (don't remember why
sincerely).
For the records, I've been using mixed suspended/not
@miconda To answer a few other questions:
1. I always set `$http_req(suspend) = 1` on async HTTP client transactions;
2. There are no `event_routes` anywhere;
3. The flow is complex, though. After this async HTTP query, there is another
_synchronous_ HTTP query using the normal `http_client`
Hi, thank you very much for investigating this!
Unfortunately, the causes of the crash do not appear to arise dependably; as
luck has it, there hasn't been one in the days since I submitted this issue.
So, all I can do is cherry-pick this patch into the source and hope for the
best.
I will
I think I found something that could have been caused the issue, respectively
setting the AVPs lists from transaction in the process context inside the http
async callback function. It was done for the case when transaction was
suspended and no cleaned up, living further in the context of the
@abalashov have you checked if you set suspend field always? any new crash?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Looking at the backtrace, the execution continues with a `faked_msg` structure:
```
#14 0x0048e205 in run_top_route (a=0x7f3f732aa9c0, msg=0xb04f60
<_faked_msg>, c=0x0) at core/action.c:1661
#15 0x7f3f705f7d0e in async_http_cb (reply=0x7f3f2b7ee620,
param=0x7f3f2b7eca18) at
Just had another crash -- identical backtrace; it seems any attempt to access
this AVP explodes:
```
(gdb) print *avp
Cannot access memory at address 0xabcdefed
```
```
Program terminated with signal 11, Segmentation fault.
#0 0x005d479b in match_by_name (avp=0xabcdefed, id=45,
Hi -- thanks for the response!
Alas, nothing has really changed that I know of.
Actually, this is a scenario where multiple HTTP queries are being run as well;
this is the first stage, but subsequently the scenario is more complicated and
requires use of the synchronous 'http_client', so it's
Hi Alex,
yes, avp should be persistent. I've never seen a crash like this in 5.2.x (the
release I'm using in prod) and I'm using avp in resume routes, even
suspending/resuming twice a single transaction (I have a scenario where two
http queries are run).
Have anything changed in your system
Version: 5.3.3 `065668`
Platform: CentOS 7 (3.10.0-862.14.4.el7.x86_64)
I seem to have a persistent intermittent crash on all five gateways which use
`http_async_client` to query an HTTP API.
In all cases, the crash is on attempt to access or reference an AVP called
`$avp(is_subscribe)`:
```
16 matches
Mail list logo
