> Am 07.04.2018 um 20:04 schrieb David Chisnall <gnus...@theravensnest.org>: > > On 7 Apr 2018, at 18:58, Riccardo Mottola <riccardo.mott...@libero.it> wrote: >> >> 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, actually you did also accidentally push your new constant string layout change. I hope it was accidentally as doesn’t get mentioned in the commit message and as usual is missing a ChangeLog entry. The bug fix itself looks correct. Thank you for that! Fred _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
