SHOWPLAN related changes Reworked the fix for bug 1392522 - mxosrvr core dumped doing showplan (with N.E. enabled), plus other related code changes. 1) The native code (also known as native expression), if generated, is stored in the expression's constant area. SHOWPLAN will dump the native code in the assembly format. The display can be disabled by CQD PCODE_NE_IN_SHOWPLAN to "OFF". It is "ON" by default. This part had been reviewed by Jim Capps and Mike Hanlon. 2) Add several SHOWPLAN statements in core/TEST019 without logging the output. This is to ensure no core generated when getting executor operator (TDBs) info via SHOWPLAN. 3) A temporary fix to ComTdbHbaseAccess::displayRowId(). The current way of retrieving begin or end row IDs from the HbaseScanRows for SHOWPLAN does not match with the way those row IDs are generated (see HbaseAccess::genListsOfRows), causing core dumps in some cases.
Fix #1336979, #1342954, #1340400, #1342945, and #1315194 There are 6 things done by this change set: * Uses a mutex to prevent use of the LLVM library code by more than 1 thread at a time. * Links libjsig.so into sqlci and tdm_arkcmp to use signal chaining so that both Java and LLVM can have signal handlers for SIGSEGV (and several other signals). * Ensures that LLVM's signal handlers are in effect when LLVM is being used and not in effect when LLVM is not in use. (One would think that LLVM would ensure this, but it currently does not.) * Enables the Native Expressions feature by default. * #ifdef's out the code in SQLMXConnection.cpp which was disabling the Native Expressions feature for the multithreading T2 driver. * Changes from default JIT code generation (generating for the specific x86 chip the SQL Compiler is running on) to generating code for a generic x86-64 chip. This should prevent the 'invalid' instructions which were seen on some of the Jenkins slave** machines.
Libjsig.so is part of the Java package that we are using. The changes being made to the makefiles are to get libjsig.so linked into the executables before Java and before LLVM. A short description of libjsig is at: http://docs.oracle.com/javase/7/docs/technotes/ guides/vm/signal-chaining.html
The way that LLVM currently handles various signals is a little strange: The first time that you call the LLVM library, it saves off the signal handlers for 11 different signals and establishes its own handler for these signals. [Specifically, it does this when our code calls llvm::verifyFunction().] The LLVM library code does not restore the signal handlers before returning! (It will restore them only if its signal handler ever gets called. Basically, LLVM believes that if any of those 11 signals occurs while in LLVM code, then LLVM has basically "crashed" and it wants to possibly delete some intermediate files and essentially shut things down.)
Java, on the other hand, uses these signals for its own purposes - particularly SIGSEGV. We do not want Java threads calling LLVM's signal hander. So it is important to not leave LLVM's signal hander established as the handler for these signals when the LLVM library is not currently in use.
This has been pre-reviewed by Justin, Qifan, and Selva, except for: * the 13 lines of changes to sql/exp/ExpPCodeOptsNativeExpr.cpp for getting the JIT compiler to generate code for a generic x86-64 chip, and * the changes to conn/jdbc_type2/native/SQLMXConnection.cpp to re-enable Native Expressions for the multi-threading T2 driver.
All dev regressions were run several times on a workstation and several times via EC with no core files being produced. Phoenix tests and multi-threaded T2 tests were also run several times. Also, the Jenkins "check tests" (including Phoenix tests) were run several times -- until the 'core' regression suite ran successfully on slave07 (which is one of the machine where the 'invalid' machine instruction was produced previously.)