From: Colin A. <col...@go...> - 2007-12-26 08:31:39
|
On 25/12/2007, Eric Bezault <er...@go...> wrote: > Colin Paul Adams wrote: > > Maybe, maybe not. I may try the original problem (by removing the > > parallel collecting option) to see if that catches it. > > Then we might as well report a bug in boehm. > > I found (and fixed) a bug in `deep_twin': > > * Fixed bug (read/write to non-allocated memory) in implementation of > `deep_twin' when traversing objects of type SPECIAL. > > Do you know if `deep_twin' is used in your program? It might explain > the weird behavior that you get if the memory gets corrupted in such > a way. > > I also improved things when declaring user-defined expanded types, > in particular when creating SPECIAL objects of expanded). Feature > `default_create' is still not called on initialization, and `copy' > is still not called on reattachment. If neither of these are redefined > in your user-defined expanded types, then it should now be safe to > use them. It doesn't fix the problems where I get: In test-case errorcode1030: Finishing early, having processed test case 'eeocode' in 'eif_except.h' not implemented 'stack_trace_string' in 'eif_except.h' not implemented Call on Void target! Unhandled exception How much effort is involved to implement that? Nor does it affect the original problem (revealed by turning off parallel marking in boehm gc). |