On 7 Apr 2018, at 18:58, Riccardo Mottola <riccardo.mott...@libero.it> wrote: > > Hi, > > Matt Rice wrote: >> Fred, did you try on OpenBSD? >> This smells to me like an issue of relying upon the platform dependent >> shared library constructor call order. >> perhaps the innocuous looking NSBundle changes here: >> https://github.com/gnustep/libs-base/commit/43673452a505a79a55dd1d59b0789f5ebc2eec0c#diff-c09284bb3ef153ed33bb7f447c4fe88e >> such as perhaps: NSBundle +load -> +initialize, and perhaps >> GSTinyString's +load or some such being called in an unexpected order. >> anyhow, the setName: call should result in a memcpy... perhaps >> Riccardo could give it a go without that change. > > I tried reverting with git that single commit, but git failed. > > I thus reverted whole base to 26th of March and things look fine. > > Going forward to the 27th, fine.. up to the 30th of March when it breaks.
No idea if either of them are relevant, but I’ve just pushed two fixes for memory-related errors in -base. One writes some data through an uninitialised pointer when an exception is thrown and the platform doesn’t provide backtrace. The other treats things as GSString instances even if they aren’t and so can potentially dereference an invalid pointer. Either of these could cause random crashes in some usage on some platforms. David _______________________________________________ Gnustep-dev mailing list Gnustepemail@example.com https://lists.gnu.org/mailman/listinfo/gnustep-dev