On Thu, Mar 3, 2016 at 7:13 PM, Arne Goedeke <e...@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
