I had QA run a UTT with some debug code to force a core dump at the time that PCode::getInstruction(...) detects that the current PCode instruction is not valid. When a looked at the core dump, I found that we were doing the pcode generation for an hbase expr. So, this appears to be a problem introduced with the PCode changes for hbase and not a problem that existed in the past.
I also found that the current PCode instruction was a EQ comparison instruction with only 1 operand. All comparison-type pcode instructions should have at least 3 operands ... two to actually compare and one for where to store the result of the comparison.
I believe this is why the PCode::getInstruction(...) method decided that the instruction was invalid.
So, the next step is to figure out how we managed to generate an EQ comparison instruction with only 1 operand. This may involve building a new UTT which more debug code to catch the problem sooner, but that remains to be seen.
I had QA run a UTT with some debug code to force a core dump at the time that PCode:: getInstruction( ...) detects that the current PCode instruction is not valid. When a looked at the core dump, I found that we were doing the pcode generation for an hbase expr. So, this appears to be a problem introduced with the PCode changes for hbase and not a problem that existed in the past.
I also found that the current PCode instruction was a EQ comparison instruction with only 1 operand. All comparison-type pcode instructions should have at least 3 operands ... two to actually compare and one for where to store the result of the comparison. getInstruction( ...) method decided that the instruction was invalid.
I believe this is why the PCode::
So, the next step is to figure out how we managed to generate an EQ comparison instruction with only 1 operand. This may involve building a new UTT which more debug code to catch the problem sooner, but that remains to be seen.