On Sat, 2004-08-28 at 05:45, John Cliff wrote:
--- Bryce Harrington <bryce@...260...> wrote:
We also need to have people test each of the nightly builds, going back in time until we find the first Win32 CVS version that crashes, so we can do a diff to find out which changes went into that version.
for me using the autobuilds to track it, last working build was the one from the 4th, the first broken one was the 6th, the autobuild didnt run on the 5th.
Okay, I've been looking over the deltas between the 4th and 5th, and the 5th and 6th.
Here is what changed:
August 4th -> August 5th:
* I made Inkscape::Refcounted a subclass of Inkscape::GC::FinalizedObject, which primarily affected SPSelection and the few NR::Object-derived classes and added -lgc to the compiler flags
* New keybindings were added to inkview
* a range bug was fixed in src/draw-context.cpp
* the "vaccuum defs" functionality was added
* peter documented various correctness proofs
* some changes were made to SPPath to (theoretically) cope with a missing d= attribute
* large changes were made to SPText which I do not fully understand
* SVG preview and some other stuff was added to the file dialog
* src/helper/helper-forward.h no longer includes src/display/display-forward.h
August 5th -> August 6th:
* -lgc was added to the Win32 makefile (its absence was why the August 5th autobuild failed)
* peter made some fixes to src/display/bezier-utils.cpp
Based on this information, I think it is fairly certain that the crashes are libgc-related.
Based on the analysis that we have done on Jabber over the past few days, it appears that libgc is attempting to take over the system new/delete functionality, so all code that allocates memory is affected.
Interestingly, it appears that things actually got worse when we undefined USE_LIBGC (which causes Inkscape::GC to use the system new/delete rather than the libgc allocator) [item 1 on the checklist I proposed to bryce].
This suggests to me that libgc proper is working fine; it is the system allocator that has been broken by libgc's attempt at takeover.
Since "malloc takeover" is not required, I suggest we make our own build of libgc that does not include it (I am fairly certain it is not the default). That sort of magic is always dicey and error-prone to begin with.
This hypothesis can be confirmed by completing the checklist:
1) existing libgc without USE_LIBGC: should fail 2) "fixed" libgc with USE_LIBGC: should work 3) "fixed" libgc without USE_LIBGC: should work 4) no libgc at all, also without USE_LIBGC: should work
-mental