I am beginner to the kamailio opensource project..i want to crash the kamailio manually to generate core file and debug it later ...I have tried using abort() and printing character array with integer identifier but no success..
can anybody know how to do it?
First: note that MI control interface was deprecated many years ago and all related code was removed starting with Kamailio version 5.0.0 (released in February 2017) -- that included removal of mi_xmlrpc module. So you work on a very old release (v4.4.x or older), no longer maintained.
To your actual question: look at the cfgutils module, it implements the abort() function that should crash kamailio. Note also that you may not get the core dump file on some operating systems if you do not run kamailio under root (privileged) user and you do not have lifted the limit for core file size (use 'ulimit -c unlimited' before starting kamailio). Moreover, some applications such as apparmor can 'hide' the crash result.
Related
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
UPDATE
Problem persists in some PC's with Windows 7 and 10. Wireshark states that the requests are getting done with Tlsv1.0.
I read that there is a workaround adding registry keys, but though I tried it and none of them work (disabling Tls1.0 and enabling Tls1.1 and 1.2), I don't want my clients to do such a procedure. I want to tell my app to use 1.2 only.
EOU
I wrote an app using Qt, which performs standard get requests to my website in https://www.myprefix.mydomain.com.
Now, the deployed app on Windows works on computers with TLS version 1.2, but the request gets blocked if the computer has TLS 1.0 enabled. To conclude this I wrote a minimal app (hello world, are u there server?) and checked the Wireshark entries in both computers and that appears to be the only difference. According to Wireshark, if TLS1.0 is available, then my app uses TLS1.0 (regardless of the presence of 1.2) and gets blocked.
I know that 1.0 is no longer considered secure, so I want to tell my Qt app to use only TLS1.+.
I would rather not use http (later I'll get sensitive information) and not tell my clients to disable TLS1.0. Can this be hardcoded into the Qt app?
I have tried with this:
QSslConfiguration config = QSslConfiguration::defaultConfiguration();
config.setProtocol(QSsl::TlsV1_2);
QSslConfiguration::setDefaultConfiguration(config);
But the app still uses TLS1.0 when available, and the server blocks the request (rightly so).
The pre-built packages of Qt supports OpenSSL (on Windows and Linux, macOS uses the SecureTransport framework by default) but they don't provide it as there are specific restrictions in some countries regarding software with cryptographic capabilities.
Therefore, if you have your application working and didn't specifically install OpenSSL on your Windows machine, it means that there's a copy of it laying around in your system. You should find it and if possible remove the containing folder from your PATH environment variable.
Next, you should grab a recent version of OpenSSL. Then you can either copy the dlls in your application folder to ensure they get picked modify the PATH environment variable in Qt Creator (the Run part of the Project panel) so your application can find it.
Note that you currently have to use OpenSSL 1.0.X. If you want 1.1 support you can get it starting with Qt 5.10 but you would have to re-build Qt yourself.
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I believe I have hit a bug on the IBM JDK on its JNI implementation.
I'm working on Apache ActiveMQ Artemis and we recently had to make this following fix as we were having issues on the IBM JDK 1.8:
https://github.com/apache/activemq-artemis/commit/18e41963b61a5ef6dbcdb150e27c07c062deaa66
The issue is around acquiring NewGlobalRef on a methodID, which presumably is an object as well. If you acquire a NewGlobalRef(MethodID) through Sun JDK everything is fine, but if you do it on an IBM JDK, then you would get a GPF.
I could fix Artemis Native layer by removing the NewGlobalRef (as I believe I didn't need in the end), but still the JVM shouldn't core dump because of this.
I have put together a project replicating the issue:
https://github.com/clebertsuconic/simple-JNI-bug
if you revert the last commit, or comment the code around the NewGlobalRef on the method ID everything will pass.
MethodIds aren't Objects. There is no reason to get a GlobalRef to them. Remove the newGlobalRef call and it will work fine on both vms.
I don't know why Oracle doesn't crash (maybe checking the value against the heap range?)
Are you aware of the -Xcheck:jni option? It will help detect and warn about incorrect jni usage.
When I use Subversion in Cygwin to update some repository, some directories update with success, while some other one gets a failure with the error message:
svn: E200030: sqlite: disk I/O error
When doing svn update again for the same repository, a different directory can get the same error. Sometimes, there is a SVN instruction after the above error message.
This happened due to a change someone wanted in Cygwin's SQLite package. I was the maintainer of that package when this question was asked, and I made the change that caused this symptom.
The change was released as Cygwin SQLite version 3.7.12.1-1, and it fixed that one person's problem, but it had this bad side effect of preventing Cygwin's Subversion package from cooperating with native Windows Subversion implementations.
What Happened?
The core issue here is that Subversion 1.7 changed the working copy on-disk format. Part of that change involves a new SQLite database file, .svn/wc.db. Now, in order to implement SQLite's concurrency guarantees, SQLite locks the database file while it is accessing it.
That's all fine and sensible, but you run into a problem when you try to mix Windows native and POSIX file locking semantics. On Windows, file locking almost always means mandatory locking, but on Linux systems — which Cygwin is trying to emulate — locking usually means advisory locking instead.
That helps understand where the "disk I/O error" comes from.
The Cygwin SQLite 3.7.12.1-1 change was to build the library in "Unix mode" instead of "Cygwin mode." In Cygwin mode, the library uses Windows native file locking, which goes against the philosophy of Cygwin: where possible, Cygwin packages call POSIX functions instead of direct to the Windows API, so that cygwin1.dll can provide the proper POSIX semantics.
POSIX advisory file locking is exactly what you want with SQLite when all the programs accessing the SQLite DBs in question are built with Cygwin, which is the default assumption within Cygwin. But, when you run a Windows native Subversion program like TortoiseSVN alongside a pure POSIX Cygwin svn, you get a conflict. When the TortoiseSVN Windows Explorer shell extension has the .svn/wc.db file locked with a mandatory lock and Cygwin svn comes along and tries an advisory lock on it, it fails immediately. Cygwin svn assumes a lock attempt will either succeed immediately or block until it can succeed, so it incorrectly interprets the lock failure as a disk I/O error.
How Did We Solve This Dilemma?
Within Cygwin, we always try to play nice with Windows native programs where possible. The trick was to find a way to do that, while still playing nice with Cygwin programs, too.
Not everyone agreed that we should attempt this. "Cygwin SQLite is part of Cygwin, so it only needs to work well with other Cygwin programs," one group would say. The counterpartisans would reply, "Cygwin runs on Windows, so it has to perform well with other Windows programs."
Fortunately, we came up with a way to make both groups happy.
As part of the Cygwin SQLite 3.7.17-x packaging effort, I tested a new feature that Corinna Vinschen added to cygwin1.dll version 1.7.19. It allowed a program to request mandatory file locking through the BSD file locking APIs. My part of the change was to make Cygwin SQLite turn this feature on and off at the user's direction, allowing the same package to meet the needs of both the Cygwin-centric and Windows-native camps.
This Cygwin DLL feature was further improved in 1.7.20, and I released Cygwin SQLite 3.7.13-3 using the finalized locking semantics. This version allowed a choice of three locking strategies: POSIX advisory locking, BSD advisory locking, and BSD/Cygwin mandatory locking. So far, the latter strategy has proven to be completely compatible with native Windows locking.
Later, when Jan Nijtmans took over maintenance of Cygwin SQLite, he further enhanced this mechanism by fully integrating it with the SQLite VFS layer. This allowed a fourth option: the native Windows locking that Cygwin SQLite used to use before we started on this journey. This is mostly a hedge against the possibility that the BSD/Windows locking strategy doesn't cooperate cleanly with a native Windows SQLite program. So far as I know, no one has ever needed to use this option, but it's nice to know it's there.
Alternate Remedy
If the conflict you're having is between Cygwin's command line svn and the TortoiseSVN Windows Explorer shell extension, there's another option to fix it. TortoiseSVN ships with native Windows Subversion command-line programs as well. If you put these in your PATH ahead of Cygwin's bin directory, you shouldn't run into this problem at all.
Having encountered the same problem, it appears (in my case at least) to be an interaction with TortoiseSVN. Disabling TortoiseSVN's status icon cache (Settings > Icon Overlays > Status cache "None" > Apply) has everything working just fine for me.
(That obviously doesn't resolve the underlying problem, which appears to be due to the SQL package that Cygwin's Subversion package relies on changing its mode of access. As I write, there's active [if slow] discussion on the Cygwin mailing list about how to resolve this.)
ldd /usr/bin/svn shows that SVN depends on /usr/bin/cygsqlite3-0.dll.
After I change libsqlite3 from 3.7.12 back to 3.7.3, the problem seems to go away. So this may be a SQLite library problem.
Using TortoiseSVN, ticking off Refresh shell overlays at clean up solved the problem for me.
For others reference, I just had this same error (svn: E200030: sqlite: disk I/O error) and found that one of my log files was taking up all my space (and could not write to the HDD because there was no free space).
Run (to make sure you have enough disk space)
df -h
(If you don't delete some large files (I just removed some backup and log files)
Then I just needed to run:
svn cleanup
This resolved the error for me.