Created attachment 155882 [details] patch-modules__presence_mwi__add_events.c Attempting to load presence_mwi module results in the following: > kamailio -c loading modules under config path: /usr/local/lib/kamailio/modules/ 0(10733) ERROR: <core> [sr_module.c:597]: load_module(): could not open module </usr/local/lib/kamailio/modules/presence_mwi.so>: /usr/local/lib/kamailio/modules/presence_mwi.so: Undefined symbol "eat_sp_tab" 0(10733) : <core> [cfg.y:3423]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 52, column 12-28: failed to load module ERROR: bad config file (1 errors) eat_sp_tab and eat_printable are declared inline in modules/presence_mwi/add_events.c which I guess assumes GNU C89 in GCC and doesn't play nice with Clang The attached changes these to static inline which should resolve the issue A quick grep indicates the same may exist in a few other modules Hope this is of some use. Thanks for the port.
I'm also having problems with PRESENCE modules. When WITH_PRESENCE is defined in kamailio.cfg the server crashes randomly when an SIP client application is closed. Although my issue still occurs when it is compiled with GCC. Could you please attach your config file. Or at least the WITH_* definitions. I would like to reproduce your issue with presence_mwi. I do not get any errors at startup using WITH_PRESENCE alone. Update: I added loadmodule "presence_mwi.so" and got the same error myself. I may try patching all "inline" with "static inline" and see if it helps with my issue. However I think my issue is to do with loopback address 127.0.0.1 not being available in a jail. Kamailio's PRESENCE modules make reference to INADDR_LOOPBACK as found in files/patch-ip_addr_h.
Update: Done some extensive testing of Kamailio 4.2.4 built from latest port. My issue is hard to predictably trigger. It seems the crash is due to the WITH_PRESENCE defined (in use). If I disable WITH_PRESENCE, it never crashes (so far). I have done some debugging and now I don't think the INADDR_LOOPBACK has anything to do with it. It just seems as though the typical presence modules presence.so and presence_xml.so are not so stable, at least on FreeBSD. I am running the server behind a NAT, that may be a factor. However 4.1.0 compiled manually using gcc 4.6 is super stable, even with WITH_PRESENCE. Sorry to hijack the thread. Our issues may be related, but I'm doubtful. Having read into 'inline' with respect to GNU-C89 and C99, it seems this would only cause linking issues. Could the incorrect use of 'inline' on the clang compiler produce a successful build but cause runtime faults? There are way too many uses of 'inline' without 'static' and without a second declaraction (as there should be according to C99). I am focussing on my own issue at this stage.
(In reply to Euan Thoms from comment #2) As you mention, I believe the issue I highlighted would only cause linking issues and only when building with Clang. If you are building with GCC it should be irrelevant. The fault should show itself when loading the module into Kamailio at startup as the function is called. For what it's worth, I'm currently running kamailio-4.2.4 built from ports using poudriere on 10.1-RELEASE-p9 with the above patch applied. Both the presence and presence_mwi modules are loaded and in frequent use and I haven't (yet?) experienced any stability issues. It's a bit off-topic for this bug report but if you'd like to contact me directly I'd be interested in trying to replicate the problem you're having.
Tom, I'm still having major problems with kamailio/OpenSIPS. Actually I've made an OpenSIPS port (quite a bit fof work went into it). I've been trying to get a stable installation of OpenSIPS afer giving up on Kamailio. It has the same issues / symptoms. I fould that the main problem I had was with "fork=yes" and "children=4". It starts and run fine for a whil, bu then the processes crash. If I change to a single process via "children=1" it never crashes. It's clear cut, I've done a lot of testing. But I still have issues with the server, whilst the service keeps running, it's unusable, and client can't register. I wonder if it's because I'm using it in a jail. I have played around with private and shared memory settings. I've enabled SysV IPC shared memory on the jail. I've increased the hash table sizes from 9 (2 to the power of 9) to 11 and then 14. And now it seems to be effecting postgresql, my once rock solid server is now having issues elsewhere since messing around with OpenSIPS. So I would like to know why yours is so stable and mine isn't. I'm using FreeBSD 10.1, in a jail. I'm using the default memory systems for OPenSIPS 1.11 LTS, which are PKG for private and SHMEM for shared memory. I'm contemplating trying to use another cache method, perhaps memcached. I would realy appreciate some help. I'll send you an email soon. Is the one in your mailto tag here the best?
I just made an update to 4.3.1, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200352 and would learn if your problem is fixed with that update or whether the problem still persists.
A commit references this bug: Author: pi Date: Sun Sep 6 19:37:38 UTC 2015 New revision: 396230 URL: https://svnweb.freebsd.org/changeset/ports/396230 Log: net/kamailio: add some options, after tests - add PERL option - add SCTP option - patch to use atomic-ops PR: 199630 Changes: head/net/kamailio/Makefile head/net/kamailio/files/extra-patch-atomic-amd64 head/net/kamailio/files/extra-patch-atomic-i386 head/net/kamailio/files/patch-modules_app__perl_kamailioxs.xs head/net/kamailio/pkg-plist
Re: comment #1 Rereading your comment, I tested my installation with kamailio -c and was not able to reproduce the problem, so 4.3.1 solved your problem. While investigating, I added two options, where your hint on static declaration helped to build the app_perl module. There was an easy fix for the unknown atomic ops, which I also added. So I'm closing this bug now, it can be reopened, if the problem still happens.