PKG_MEM is not defined or use anywhere else in the code, so assuming
`PKG_MALLOC` is meant here.
You can merge this Pull Request by running:
git pull https://github.com/shimaore/opensips pkg_mem_events
Or you can view, comment on it, or merge it online at:
This is a minor documentation correction.
You can merge this Pull Request by running:
git pull https://github.com/shimaore/opensips db_http_timeout_doc
Or you can view, comment on it, or merge it online at:
https://github.com/OpenSIPS/opensips/pull/141
-- Commit Summary --
* Corrected
This changeset modifies the `mathops` module by adding a `math_rpn` function
which provides access (in an easily extensible way) to many more operations
than the default `math_eval` parser, especially functions (the need for `exp`
was the reason I wrote this). The `math_rpn` parser produces its
Thank you for your comments.
Reverse Polish notation is hideous.
YMMV. :) As an HP (RPN) user and someone who has written a Forth interpreter in
his formative years, I don't have issues moving between RPN and infix. I saw a
RPN evaluator, I needed to add a function to it, it was faster to
I haven't looked at the details in the code of the rabbitmq module yet, but saw
in logs that it doesn't appear to deal properly with URI-encoding in usernames
(and passwords I assume, but haven't tested).
For example if I use
For a (very simple) test that exhibits the problem, see
https://github.com/shimaore/ccnq3/commit/ed9b47cce334dd19df5ee0144837e99876a14def
(essentially you had to load `drouting` and opensips would segfault).
---
Reply to this email directly or view it on GitHub:
This is actually the issue I think we encountered originally with `drouting.c`
and which I was trying to fix with #153 ; obviously this is a different issue.
At line 484 of drouting.c:
if ( (gw-flags DR_DST_STAT_DIRT_FLAG)==0 )
`gw` was the variable used in the loop above (line 454 to
(Using git HEAD) OpenSIPS crashes and reports segfault in libc.so due to
invalid offset:
/* copy the rest of the message */
memcpy(new_buf+offset, buf+s_offset, len-s_offset);
with len = 614 and s_offset = 642.
---
Reply to this email directly or view it on GitHub:
Another one with len = 617 anf s_offset = 662. Happens on BYE messages here.
Trying to analyze with gdb.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/155#issuecomment-31574015___
Devel mailing list
(gdb) up
#1 0x0043e344 in build_req_buf_from_sip_req (
msg=msg@entry=0x7f6107e03660,
returned_len=returned_len@entry=0x7fff7e5ac434,
send_sock=send_sock@entry=0x7f6107dec340, proto=optimized out,
flags=flags@entry=1) at msg_translator.c:1539
Got many of them now, in all of them `s_offset-len` is always 45. Happens with
BYE and ACK message processing.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/155#issuecomment-31574873___
Devel mailing
@bogdan-iancu I need to have our testbed be put back together. Those traces
were collected during an attempt at migrating a production machine the script
is a few hundred lines long so it's pretty hard to say without live testing.
---
Reply to this email directly or view it on GitHub:
@bogdan-iancu none yet, I haven't been able to reproduce in the lab (using
sipp, and a replica of the production database); even trying with broken
headers etc didn't lead to a crash. We're going to do another upgrade tomorrow
morning on one of the production systems to try to capture data
Got a first crash after 32 minutes (last time it only took a few seconds),
syslog reports:
Feb 6 04:42:18 cs2 kernel: [ 5489.499019] opensips[28672]: segfault at
7c2000 ip 7f26ca592b0f sp 7fff0f704e28 error 4 in
libc-2.17.so[7f26ca506000+1a3000]
Feb 6 04:42:18 cs2
The coredump is similar to the ones we got last time (same line in the code, 45
bytes offset). I tried to reproduce the issue by replaying the packets (using a
custom sipp script) for the Call-ID that crashed, with the same opensips
script, but I can't get OpenSIPS to crash that way. Also can't
FWIW there are two locations in mem/f_malloc.c that might have problems with
`n->prev` being NULL before calling `fm_remove_free`:
- The first one is [line
353](https://github.com/OpenSIPS/opensips/blob/2.1/mem/f_malloc.c#L353) if `n`
=== `frag`.
- The other one is the one where this issue goes
This is using opensips 2.1 at commit ee99ac71d8718c93c29e28e6a5266287491f17a5
in a production environment. OpenSIPS is configured to generate coredump,
[core.txt](https://github.com/OpenSIPS/opensips/files/56763/core.txt) has `bt
full` + `print` of variables in last 3 stack entries.
The issue
PR #722 has a workaround for the condition experienced in this case. However
this might lead to fragments not being re-used iff `->prev` is already NULL,
which might lead to memory leak / memory exhaustion.
This would need to be reviewed by someone more conversant with memory
management. :)
This is a workaround for #721
This doesn't address the base question (why would a fragement have `->prev` set
to NULL), so this isn't a fix, but it should prevent crashes for this case.
You can view, comment on, or merge this pull request online at:
Sounds like the critical sections of the memory allocator could use mutexes,
then?
Is there another allocator I could select at compile time that would be
thread-safe?
---
Reply to this email directly or view it on GitHub:
OK, so OpenSIPS architecture hasn't changed from what I knew, which is good :)
Could this happen if the outcome of a shm `malloc` was given to the pkg `free`
(or the other way around) for example?
---
Reply to this email directly or view it on GitHub:
@razvancrainea yes, we had the issue maybe every hour or so (on one server) on
the day it first appeared (we also had it on other servers with a lesser rate).
I hadn't done much work with the internals of OpenSIPS so didn't know about the
memory debugging allocator, and since it was a SIGSEGV
Thank you @liviuchircu -- this should be in [my
build](https://github.com/shimaore/docker.opensips/blob/master/Dockerfile#L29);
I'll report if I see anything.
@razvancrainea We haven't had a crash yet since I applied #722 to our
production code last night — I know it's not a real fix but it's
Assuming this scenario... is it possible to tag _shm_ vs _pkg_ pointers inside
the memory allocator, so that when a module tries to `free`/`realloc`/.. a
pointer with the wrong type, OpenSIPS reports it (hopefully with data about
where the operation was done)?
---
Reply to this email directly
24 matches
Mail list logo
