Matthew Horsfall wrote: > I think I've got this right: Thank you. Sorry for putting you to the trouble. The valgrind output has just made something in my head click: > ==3474== Address 0x592fd20 is 16 bytes inside a block of size 1,024 free'd > ==3474== at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==3474== by 0x4BD3F7: Perl_safesysrealloc (util.c:244) > ==3474== by 0x4E5246: Perl_av_extend_guts (av.c:154) > ==3474== by 0x4E4FC0: Perl_av_extend (av.c:82) > ==3474== by 0x52AB5C: Perl_stack_grow (scope.c:38) > ==3474== by 0x55E26E: Perl_do_kv (doop.c:1268) > ==3474== by 0x4EB13E: Perl_pp_rv2av (pp_hot.c:934) > ==3474== by 0x4E7399: Perl_runops_standard (run.c:42) > ==3474== by 0x44046E: Perl_call_sv (perl.c:2746) > ==3474== by 0xA872F53: dc_call_sv1 (Data-Clone.xs:176) > ==3474== by 0xA8731E1: dc_clone_object (Data-Clone.xs:227) > ==3474== by 0xA873356: clone_rv (Data-Clone.xs:266) Data::Clone is calling the perl code that reallocated the stack, so I suspect the bug is there. Where is *it* not protecting things? (I suspect its use of call_sv is buggy and that the commit that supposedly broke it is a red herring.) I am trying to reproduce this on dromedary. The bad news is that I keep losing my ssh connection before I finish processing dependencies. But I seem to be getting closer each time....Thread Previous | Thread Next