Re: Segmentation Faults - OpenBSD

[Fred Kiefer]

> Am 07.04.2018 um 20:04 schrieb David Chisnall <address@hidden>:
> 
> On 7 Apr 2018, at 18:58, Riccardo Mottola <address@hidden> 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