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 <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 >
