On chat mental and bulia spoke of plans for solving the windows crash issues. It's possibly due to one of the new dependencies. The tricky part is that since none of us do builds on windows, it's hard to troubleshoot, especially since stuff changes quite a bit in the codebase on a daily basis. However we have a plan.
What we'd like to do is temporarily go into a development freeze until this issue is fixed. The focus for developers should be on fixing the critical bugs, memory leaks identified by gc, and all platform build issues. We want to get back to a point where all developers can confidently build and run Inkscape again.
The steps for eliminating libgc as a source of the issues are: 1) test with the existing malloc-overriding libgc build, but USE_LIBGC undefined in src/gc-core.h 2) test with a fixed libgc build, but re-enable USE_LIBGC 3) test with a fixed libgc build, but disable USE_LIBGC again 4) test without libgc linked at all, and with USE_LIBGC disabled
If we still have the problem at #4, it's not libgc-related.
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.
Once we've narrowed it to the smallest set, we can determine the next steps. Hopefully we can get this problem licked quickly, via this approach.
Unless anyone has a major concern about doing this, let's plan on starting the freeze tomorrow (say, 12 hrs from right now). If we can't get good progress on this within a couple days, we'll de-freeze and figure something else out.
Bryce
On Fri, 27 Aug 2004, MenTaLguY wrote:
On Fri, 2004-08-27 at 14:37, MenTaLguY wrote:
Talking to Simarilius, it looks like the version of libgc we've been using on Win32 has been built to replace the standard malloc.
This should in principle be harmless (except that the collector will be scanning a lot of memory it does not need to, and might mistake e.g. bitmap data for pointers), but
Hrm. Didn't finish my thought there.
The thing is, I trust the boehm collector on Win32, provided we use it conservatively, as it's been very well tested by other projects before us (e.g. currently Mono is using it exclusively on Win32 for memory allocation).
However, I believe less conservative usages (like attempting to override the system allocator with it) are problematic.
If the override isn't perfect, for example, we could end up with memory allocated by the Win32 heap allocation API passed to GC_FREE(), or one of the Win32 heap freeing functions getting passed a gc-managed pointer.
That would be consistent with the symptoms and backtraces we appear to be seeing with the Win32 crashes; dying either in GC_free() or in a Win32 heap free function.
-mental