Try compiling --without-machine-code and --with-valgrind, this will get rid of most of the false positives.
arne
On 03/03/16 10:50, Chris Angelico wrote:
On Thu, Mar 3, 2016 at 7:13 PM, Arne Goedeke el@laramies.com wrote:
Try running that test with valgrind, it should tell you more reliably what the issue is. You will either have to compile pike --with-valgrind or use --smc-check=all so that valgrind is able to deal with the generated machine code. Another useful valgrind option is --track-origin=yes, which will try to tell you e.g. where undefined values came from and more info about the origin of things on the heap.
Hmm. Even without triggering the exception, valgrind produces a boatload of response data, finishing with:
==15612== ERROR SUMMARY: 775 errors from 287 contexts (suppressed: 0 from 0)
But after triggering the exception, this keeps coming up:
==15647== Conditional jump or move depends on uninitialised value(s) ==15647== at 0x7D0B0F9: ??? ==15647== by 0x6234048: ??? ==15647== by 0x75B5FBF: ??? ==15647== by 0x6760FFF: ??? ==15647== by 0x65DA11F: ??? ==15647== by 0x6233EC7: ??? ==15647== by 0x6335B2F: ??? ==15647== by 0x7D0B104: ??? ==15647== by 0x41D526: eval_instruction (interpret.c:1685) ==15647== by 0x41D526: catching_eval_instruction (interpret.c:2722) ==15647== by 0x41F06F: inter_return_opcode_F_CATCH (interpret.c:1269) ==15647== by 0x7D09227: ??? ==15647== by 0xFFF000037: ???
The second number, 0x6234048, keeps increasing - this error *spins*. Very interesting. Will investigate further. Thanks Arne.
ChrisA