Open GoogleCodeExporter opened 8 years ago
Thank you for the patch. I'm considering including it, but I suspect that the
problem
lies elsewhere since the libflam3 library shouldn't (re)alloc on those
structures.
This sounds like it's either a Qt problem or you've found a flame that breaks
libflam3. If you can produce a backtrace that should narrow it down.
Original comment by bit...@gmail.com
on 22 Dec 2008 at 10:05
yeah, I was surprised that fixing the memory issues helped, too. I just wanted
to
start with the first errors, and work my way down to the "important" errors but
after
fixing the memory mismatches, valgrind stopped complaining and the program
stopped
crashing. so far. you know how that goes.
I was just trying the random flames, and different variations - the seg fault
was
consistent with the about "10 flames/variations/undock mutations window" I
tried ...
and honestly, I was undocking and re-docking the mutations window, as a way to
get it
to update, before I figured out how it works ... so it could be a case of "sit a
monkey down in front of a program and he'll break it!" :-)
I'll try to get the original version to seg again, and get a backtrace.
Original comment by jill.ump...@gmail.com
on 23 Dec 2008 at 8:21
(line numbers are as of qosmic 1.4.8)
the problem is that flam3_copy calls (which frequently segfault in
mutation.c:445,487 - not sure about line 265) actually does a memcopy over the
passed structs and the attached xforms. existing xforms are free'd and
malloc/realloc'd again which seems to give different results than with new.
Also I noticed that adding 1 to the image size (mutation.c:250 image =
(unsigned char *) malloc...) helped reduce or even overcome the segmentation
faults for flam3_render calls (mutation.c:448), while flam3_copy still breaks
because it's unrelated.
Original comment by mysat...@gmail.com
on 29 Sep 2011 at 9:41
Original issue reported on code.google.com by
jill.ump...@gmail.com
on 21 Dec 2008 at 8:48Attachments: