Apache2 mod_jk segfaults with OS X Mavericks - macos

I upgraded to Mavericks just yesterday, and had to reinstall mod_jk for my development environment. Compiling it from source was a bit of a pain. I found this page on a previously-asked question about mod_jk on OS X, but there were a couple extra hoops I had to jump through. For some reason, apxs thinks that gcc lives at:
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain/usr/bin/cc
But that exact folder doesn't exist; I had to symlink the existing XcodeDefault.xctoolchain directory:
sudo ln -s XcodeDefault.xctoolchain/ OSX10.9.xctoolchain
Then I tried running configure:
./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/sbin/apxs
However, configure failed because it couldn't find <stdio.h>, so I symlinked the OS X 10.9 toolchain as so:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ /usr/include
I was able to then compile and install the module by running sudo make install -f Makefile.apxs in the apache-2.0 subdirectory. However, when I started up Apache via sudo apachectl start, it immediately crashes with a segfault:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff875fb866 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff8b8a435c pthread_kill + 92
2 libsystem_c.dylib 0x00007fff92480bba abort + 125
3 libsystem_c.dylib 0x00007fff92480d31 abort_report_np + 181
4 libsystem_c.dylib 0x00007fff924a48c5 __chk_fail + 48
5 libsystem_c.dylib 0x00007fff924a48d5 __chk_fail_overlap + 16
6 libsystem_c.dylib 0x00007fff924a4906 __chk_overlap + 49
7 libsystem_c.dylib 0x00007fff924a4ad1 __strcpy_chk + 64
8 mod_jk.so 0x0000000105a0c631 jk_map_get_int + 225
9 mod_jk.so 0x0000000105a1f7f1 jk_get_worker_maintain_time + 33
10 mod_jk.so 0x0000000105a17683 wc_open + 755
11 mod_jk.so 0x0000000105a2f13f init_jk + 1151
12 mod_jk.so 0x0000000105a28b7e jk_post_config + 1566
13 httpd 0x000000010568b7d5 ap_run_post_config + 133
14 httpd 0x00000001056947c7 main + 2567
15 libdyld.dylib 0x00007fff9176e5fd start + 1
Has anyone had success compiling/running mod_jk with Mavericks yet? Is there something I'm missing or not doing quite right?

The aforementioned bug reported against Tomcat has a proposed patch which is likely to be applied soon. Feel free to use any of the patches described in that bug -- they will all work.

Download latest Tomcat Connectors source from tomcat.apache.org/download-connectors.cgi
Per https://issues.apache.org/bugzilla/show_bug.cgi?id=55696
change the method below in ./native/common/jk_maps.c to what you see here:
int jk_map_get_int(jk_map_t *m, const char *name, int def)
{
const char *rc;
int int_res;
rc = jk_map_get_string(m, name, NULL);
if(NULL == rc) {
int_res = def;
} else {
size_t len = strlen(rc);
int multit = 1;
if (len) {
char buf[100];
char *lastchar;
strncpy(buf, rc, 100);
lastchar = buf + len - 1;
if ('m' == *lastchar || 'M' == *lastchar) {
*lastchar = '\0';
multit = 1024 * 1024;
}
else if ('k' == *lastchar || 'K' == *lastchar) {
*lastchar = '\0';
multit = 1024;
}
int_res = multit * atoi(buf);
}
else
int_res = def;
}
return int_res;
}
Install command line tools
xcode-select --install
Create missing symlink
sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain
cd ./native
./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/sbin/apxs
chmod 755 scripts/build/instdso.sh
make
sudo make install

WORKAROUND - NOT A SOLUTION
I am encountering the same thing and was unable to get mod_jk to run inside of Apache.
As an alternative to simply get it to work locally and keep moving forward, I changed a few of the apache directives around to use mod_proxy_ajp instead.
LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_ajp_module libexec/apache2/mod_proxy_ajp.so
ProxyPassMatch ^(/.*\.(jsp|json))$ ajp://localhost:8009/$1
ProxyPass /aircharge ajp://localhost:8009/aircharge
...
Since the AJP protocol is still being used, the same connector for Tomcat can be used without modification.

Related

unrecognised selector sent to instance when attaching GLFW Cocoa Window to IPlugView (VST3SDK)

I'm doing some work with the Steinberg VST3SDK and have bumped into an error I don't really understand:
[GLFWWindow window]: unrecognized selector sent to instance 0x7fe10430a830
2022-12-22 08:11:08.981 MyHost[1593:20791] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[GLFWWindow window]: unrecognized selector sent to instance 0x7fe10430a830'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff37903a17 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff70468a9e objc_exception_throw + 48
2 CoreFoundation 0x00007fff37982e36 -[NSObject(NSObject) __retain_OA] + 0
3 CoreFoundation 0x00007fff37868190 ___forwarding___ + 1427
4 CoreFoundation 0x00007fff37867b68 _CF_forwarding_prep_0 + 120
5 Digitalis 0x000000010a9dc990 GetPluginFactory + 1922288
6 Digitalis 0x000000010a9dbb85 GetPluginFactory + 1918693
7 Digitalis 0x000000010a80db6e GetPluginFactory + 26318
8 MyHost 0x000000010a624641 _ZN6Plugin4loadERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEE + 2065
9 MyHost 0x000000010a624e9d main + 61
10 libdyld.dylib 0x00007fff71608cc9 start + 1
11 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
i guess this leads me to question whether the kPlatformType “NSView” is equivalent to glfwGetCocoaWindow()'s “NSWindow” return value?
heres the snippet of code thats causing me errors:
if (!glfwInit()) {
std::cout << "Failed to initialise Editor Window" << std::endl;
return false;
}
auto view = controller->createView(Steinberg::Vst::ViewType::kEditor);
Steinberg::ViewRect dimensions;
view->getSize(&dimensions);
editorWindow = glfwCreateWindow(dimensions.getWidth(), dimensions.getHeight(), "VST 3 SDK", nullptr, nullptr);
view->attached(glfwGetCocoaWindow(editorWindow), Steinberg::kPlatformTypeNSView);
can also confirm that the windows equivalent of this works fine:
view->attached(glfwGetWin32Window(editorWindow), Steinberg::kPlatformTypeHWN
any type of explanation whether it be for debugging the error message itself or the VST3SDK side would be greatly appreciated!
i tried:
view->attached(glfwGetCocoaWindow(editorWindow), Steinberg::kPlatformTypeNSView);
and expected the vst3 view to be attached to my GLFW window

What does $INSIDE_EMACS do for bash

I saw here that bash 4.4 looks for the variable $INSIDE_EMACS to determine if it is running in a comint mode buffer. However I can't seem to find what this changes about bash behavior. What changes does $INSIDE_EMACS make?
According to emacs doc:
Emacs sets the environment variable INSIDE_EMACS in the subshell to version,comint, where version is the Emacs version (e.g., 24.1). Programs can check this variable to determine whether they are running inside an Emacs subshell.
Took a look at bash's source code and there's no much magic:
575 /*
576 * M-x term -> TERM=eterm-color INSIDE_EMACS='251,term:0.96' (eterm)
577 * M-x shell -> TERM='dumb' INSIDE_EMACS='25.1,comint' (no line editing)
578 *
579 * Older versions of Emacs may set EMACS to 't' or to something like
580 * '22.1 (term:0.96)' instead of (or in addition to) setting INSIDE_EMACS.
581 * They may set TERM to 'eterm' instead of 'eterm-color'. They may have
582 * a now-obsolete command that sets neither EMACS nor INSIDE_EMACS:
583 * M-x terminal -> TERM='emacs-em7955' (line editing)
584 */
585 if (interactive_shell)
586 {
587 char *term, *emacs, *inside_emacs;;
588 int emacs_term, in_emacs;
589
590 term = get_string_value ("TERM");
591 emacs = get_string_value ("EMACS");
592 inside_emacs = get_string_value ("INSIDE_EMACS");
593
594 if (inside_emacs)
595 {
596 emacs_term = strstr (inside_emacs, ",term:") != 0;
597 in_emacs = 1;
598 }
599 else if (emacs)
600 {
601 /* Infer whether we are in an older Emacs. */
602 emacs_term = strstr (emacs, " (term:") != 0;
603 in_emacs = emacs_term || STREQ (emacs, "t");
604 }
605 else
606 in_emacs = emacs_term = 0;
607
608 /* Not sure any emacs terminal emulator sets TERM=emacs any more */
609 no_line_editing |= STREQ (term, "emacs");
610 no_line_editing |= in_emacs && STREQ (term, "dumb");
611
612 /* running_under_emacs == 2 for `eterm' */
613 running_under_emacs = in_emacs || STREQN (term, "emacs", 5);
614 running_under_emacs += emacs_term && STREQN (term, "eterm", 5);
615
616 if (running_under_emacs)
617 gnu_error_format = 1;
618 }
UPDATE:
Just found the original request (in bug-bash mailing list) for bash to deal with INSIDE_EMACS: Bash should look at INSIDE_EMACS not just EMACS
At the very least, it causes bash to disable line editing, since presumably you will be using emacs's own editing facilities to edit a command line.

Kernel Debugging: Gdb not able to set breakpoints and no effect of SIGINT to bring back in Debugging Session

Linux Kernel : 4.13-rc7 x86_64
Configured Buildroot and Qemu for Linux Kernel Debugging.
Launch Qemu using following Command:
qemu-system-x86_64 -kernel linux-4.13-rc7/arch/x86/boot/bzImage -initrd buildroot-2017.02.5/output/images/rootfs.cpio -append "root=/dev/ram0 console=tty0 kgdboc=ttyS0,9600 kgdbwait" -chardev pty,id=pty -device isa-serial,chardev=pty
Now, In Next terminal window, launch gdb and proceed following gdb commands:
`
gdb-peda$ file vmlinux
Reading symbols from vmlinux...done.
warning: File "/root/drive/linux-4.13-rc7/scripts/gdb/vmlinux-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /root/drive/linux-4.13-rc7/scripts/gdb/vmlinux-gdb.py
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
gdb-peda$ target remote /dev/pts/3
Remote debugging using /dev/pts/3
Warning: not running or target is remote
0xffffffffbd6f65af in ?? ()
gdb-peda$ b start_kernel
Breakpoint 1 at 0xffffffff81f79ad7: file init/main.c, line 510.
gdb-peda$ c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0xffffffff81f79ad7
Command aborted.
gdb-peda$ `
I also tried in Qemu machine:
echo "g" > /proc/sysrq-trigger. But, nothing happened .
Also, tried to set Hardware Breakpoints using hbreak on start_kernel, but nothing happened.
I figured out the solution by own , I did the following things to get working solution:
Apply patch to gdb then recompile it with patch in <$GDB_FOLDER>/gdb/remote.c file.
GDB Patch to resize its internal buffer :
`
root# diff -u gdb-8\ \(1\).0/gdb/remote.c gdb-8.0/gdb/remote.c
--- "gdb-8 (1).0/gdb/remote.c" 2017-06-04 21:24:54.000000000 +0530
+++ gdb-8.0/gdb/remote.c 2017-09-05 23:27:46.487820345 +0530
## -7583,7 +7583,27 ##
/* Further sanity checks, with knowledge of the architecture. */
if (buf_len > 2 * rsa->sizeof_g_packet)
- error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
+ //error (_("Remote 'g' packet reply is too long: %s"), rs->buf); #patching
+ {
+ warning (_("Assuming long-mode change. [Remote 'g' packet reply is too long: %s]"), rs->buf);
+ rsa->sizeof_g_packet = buf_len ;
+
+ for (i = 0; i < gdbarch_num_regs (gdbarch); i++)
+ {
+ if (rsa->regs[i].pnum == -1)
+ continue;
+
+ if (rsa->regs[i].offset >= rsa->sizeof_g_packet)
+ rsa->regs[i].in_g_packet = 0;
+ else
+ rsa->regs[i].in_g_packet = 1;
+ }
+
+ // HACKFIX: Make sure at least the lower half of EIP is set correctly, so the proper
+ // breakpoint is recognized (and triggered).
+ rsa->regs[8].offset = 16*8;
+ }
+
/* Save the size of the packet sent to us by the target. It is used
as a heuristic when determining the max size of packets that the`
Build the minimal RootFS by Buildroot.
Launch Qemu by following command and launch new gdb then load vmlinux file .
In one terminal :
root# qemu-system-x86_64 -kernel /root/drive/linux-4.13-rc7/arch/x86/boot/bzImage -initrd /root/drive/buildroot-2017.02.5/output/images/rootfs.cpio -S -s
In another terminal :
gdb -q /root/drive/linux-4.13-rc7/vmlinux -ex "target remote localhost:1234"
Now set break point at start_kernel and continue, It will automatically hit the breakpoint.

Creating an OSX PyQt app using Pyinstaller 2, PyQt4 and Qt5

I am trying to package a PyQt program for OSX using PyInstaller 2, where PyQt4 (4.10) has been built against Qt 5.0.2 (from Git). The following simple example doesn't work.
import sys
from PyQt4.QtGui import QApplication, QMessageBox
def main():
print "Hello"
a = QApplication(sys.argv)
m = QMessageBox(QMessageBox.Information, "Title", "Hello")
m.exec_()
if __name__=="__main__":
main()
Spec file generated using pyinstaller-2.0/utils/MakeSpec.py and modified to add the BUNDLE class.
a = Analysis(['hello.py'],
pathex=['/Users/glenn/rp/src/demo'],
hiddenimports=[],
hookspath=None)
pyz = PYZ(a.pure)
exe = EXE(pyz,
a.scripts,
exclude_binaries=1,
name=os.path.join('build/pyi.darwin/hello', 'hello'),
debug=False,
strip=None,
upx=True,
console=False )
coll = COLLECT(exe,
a.binaries,
a.zipfiles,
a.datas,
strip=None,
upx=True,
name=os.path.join('dist', 'hello'))
app = BUNDLE(coll,
name=os.path.join('dist', 'hello.app'),
appname="Hello",
version = '0.1'
)
Packaging command
> python pyinstaller.py --windowed hello.spec
Running the binary directly from the terminal gives this output before it crashes:
$ ./dist/hello.app/Contents/MacOS/hello
Hello
Failed to load platform plugin "cocoa". Available platforms are:
Abort trap: 6
and this is the stack trace:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x9a671a6a __pthread_kill + 10
1 libsystem_c.dylib 0x93163b2f pthread_kill + 101
2 libsystem_c.dylib 0x9319a4ec abort + 168
3 QtCore 0x03db156b qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 11
4 QtCore 0x03db19df QMessageLogger::fatal(char const*, ...) const + 63
5 QtGui 0x068abceb QGuiApplicationPrivate::createPlatformIntegration() + 3547
6 QtGui 0x068abd16 QGuiApplicationPrivate::createEventDispatcher() + 38
7 QtCore 0x03f4f2c4 QCoreApplication::init() + 100
8 QtCore 0x03f4f23b QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) + 59
9 QtGui 0x068aa0d0 QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) + 32
10 QtWidgets 0x06c695de QApplication::QApplication(int&, char**, int) + 238
11 PyQt4.QtGui.so 0x06394454 init_QApplication + 196
12 sip.so 0x007bc7d5 sipSimpleWrapper_init + 266
13 Python 0x0385c174 type_call + 340
14 Python 0x0380d401 PyObject_Call + 97
15 Python 0x0389c093 PyEval_EvalFrameEx + 10131
16 Python 0x038a0490 fast_function + 192
17 Python 0x0389beae PyEval_EvalFrameEx + 9646
18 Python 0x038998b2 PyEval_EvalCodeEx + 1922
19 Python 0x03899127 PyEval_EvalCode + 87
20 Python 0x038be06e PyRun_StringFlags + 126
21 Python 0x038bdfb1 PyRun_SimpleStringFlags + 81
22 Python 0x038bf619 PyRun_SimpleString + 25
23 hello 0x00003240 runScripts + 240
24 hello 0x0000280a main + 442
25 hello 0x00001eb9 _start + 224
26 hello 0x00001dd8 start + 40
The issue appears to be that it can't find the libqcocoa.dylib plugin. This is not surprising as it is not packaged. Is that the actual issue here and do I need to include this plugin? If so where does it need to go? I have tried putting it in demo.app/Contents/plugins but that doesn't help.
The right place to put libqcocoa.dylib is in Contents/MacOS/qt4_plugins/platforms:
extralibs = [("qt4_plugins/platforms/libqcocoa.dylib", "/path/to/libqcocoa.dylib", "BINARY")
]
coll = COLLECT(exe,
a.binaries + extralibs,
a.zipfiles,
a.datas,
strip=None,
upx=False,
name=os.path.join('dist', 'hello'))
The app now starts but the dialog window never appears. Edit: This is because PyInstaller (v 2.0) adds LSBackgroundOnly=true to the apps Info.plist. Removing this allows the window to show.
Try adding (but changed for PyQt):
from PySide import QtCore, QtGui
At least that works for me (PySide 1.1.1, Qt 4.8.1, latest dev Pyinstaller, OSX 10.7.5, with no changes to the spec file and --onefile --windowed arguments to pyinstaller.) And without this snippet, it also crashes for me.
I suppose that pulls in more dependencies.
Found this in another answer.

Xcode 4.4 Lion inconsistent newline behavior in C++ with GCC vs LLVM

I've been using the following bit of code for years to consume characters from cin up and including the next newline.
void skip_rest_of_line()
{
while (cin.get() != '\n') {}
}
I would call this after a catching an exception and clearing the cin state, as in:
catch (Error& error) {
cout << error.msg << endl;
cin.clear();
skip_rest_of_line();
}
The next read from cin skips the remaining newline as whitespace.
I've just changed to Xcode 4.4.1 under Lion. Using LLVM GCC 4.2 GNU++98, libstdc++(GNU C++ standard library), it works like it always did.
But using Apple LLVM Compiler 4.0, c++11, libc++ (LLVM C++ standard library with C++11 support) it looks like there are multiple problems with recognizing the newline. The same code as above requires a second return keystroke to satisfy the loop! The same problem appears with the alternative:
cin.ignore(numeric_limits<streamsize>::max(), '\n');
Finally, using getchar instead of cin.get() in the while loop works like it always did!
Is this a bug in libc++? Or have I missed something either in Xcode or C++11?
In response to Howard Hinnant, here is a little test case that shows what happens without any exceptions, etc. in the picture:
#include <iostream>
#include <vector>
using namespace std;
int main()
{
for(int count = 0; count < 2; count++) {
cout << "ready for input: " << endl;
int i;
vector<int> v;
while(cin >> i) {
v.push_back(i);
if(i == 3) {
while(cin.get() != '\n') {}
break;
}
}
for(auto it = v.begin(); it != v.end(); ++it)
cout << *it << ' ';
cout << endl;
}
cout << "done" << endl;
return 0;
}
It reads and saves ints until it's saved a 3, whereupon it reads and discards through the next newline, and then repeats the whole thing, so you can see that the stuff after the 3 gets discarded from the input stream. With Xcode 4.4.1 Lion with GNU++98 || GNU++11, libstd++, I get what I expect when I put in these two lines each terminated by a space followed by a RETURN keystroke:
1 2 3 4 5
6 7 8 3
and I get in the output window of Xcode:
ready for input:
1 2 3 4 5
1 2 3
ready for input:
6 7 8 3
6 7 8 3
done
But with C++11, libc++, nothing happens with the first line until I enter a SECOND RETURN keystroke, after both lines of input, but the proper discarding has still happened. So the extra space below after each input line is what the second keystroke looks like.
ready for input:
1 2 3 4 5
1 2 3
ready for input:
6 7 8 3
6 7 8 3
done
The very same behavior happens with using the above cin.ignore call instead of the while loop around cin.get(). So the problem is "Why is the second RETURN keystroke needed?"
I think this is a bug in libc++ on Lion, and fixed on Mountain Lion. But it is difficult to be certain without a complete test case.
Update
Thanks for the test case. Confirmed bug on Lion and fixed on Mountain Lion.

Resources