Segmentation Faults - OpenBSD

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Segmentation Faults - OpenBSD

Riccardo Mottola-5
Hi All,

After updating GNUstep on OpenBSD/i386 with gcc, I noticed that all
applications segfault. At first, I thought it is a strange combination
of an old setup, with system gcc+libobjc1 (which however worked before
upgrading)
However, I have a second machine where GS was proven working and with
gcc 4.9 and its own runtime, a setup that worked before and worked on
other system.
Test: everything works, update, gnustep base, gui, back : everything
segfaults! so that machine is the proof that the commits of the past
week broke,
I don't see how OpenBSD can be so much different, it worked for a long
time.

I notice that during gui build:

Making all for service GSspell...
gmake[4]: Nothing to be done for 'internal-service-compile'.
  Creating GSspell.service/Resources/Info-gnustep.plist...
Segmentation fault (core dumped)
gmake[3]: ***
[/usr/GNUstep/System/Library/Makefiles/Instance/service.make:141:
GSspell.service/Resources/Info-gnustep.plist] Error 1

so I found that something as simple as this:
$ plparse Source/Info-gnustep.plist
Segmentation fault (core dumped)

this smells as an issue in base! doesn't it?

this even more:
$ plparse
Segmentation fault (core dumped)

however, this is of no use at all!!

Program received signal SIGSEGV, Segmentation fault.
0x0cfd6dbc in _libc_memcpy (dst0=0x38c, src0=0x7b41c0bc,
length=2031685792)
     at /usr/src/lib/libc/string/memcpy.c:54
54      /usr/src/lib/libc/string/memcpy.c: No such file or directory.
         in /usr/src/lib/libc/string/memcpy.c
Current language:  auto; currently minimal


so now? even id I build with debug, I get no better stacktrace. This
sounds bad,


Riccardo



_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Fred Kiefer
I tried to reproduce this error but failed. Either it is a local problem on your machine or it was already fixed. Could you please try again?

Fred

> Am 30.03.2018 um 00:53 schrieb Riccardo Mottola <[hidden email]>:
>
> Hi All,
>
> After updating GNUstep on OpenBSD/i386 with gcc, I noticed that all applications segfault. At first, I thought it is a strange combination of an old setup, with system gcc+libobjc1 (which however worked before upgrading)
> However, I have a second machine where GS was proven working and with gcc 4.9 and its own runtime, a setup that worked before and worked on other system.
> Test: everything works, update, gnustep base, gui, back : everything segfaults! so that machine is the proof that the commits of the past week broke,
> I don't see how OpenBSD can be so much different, it worked for a long time.
>
> I notice that during gui build:
>
> Making all for service GSspell...
> gmake[4]: Nothing to be done for 'internal-service-compile'.
> Creating GSspell.service/Resources/Info-gnustep.plist...
> Segmentation fault (core dumped)
> gmake[3]: *** [/usr/GNUstep/System/Library/Makefiles/Instance/service.make:141: GSspell.service/Resources/Info-gnustep.plist] Error 1
>
> so I found that something as simple as this:
> $ plparse Source/Info-gnustep.plist
> Segmentation fault (core dumped)
>
> this smells as an issue in base! doesn't it?
>
> this even more:
> $ plparse
> Segmentation fault (core dumped)
>
> however, this is of no use at all!!
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0cfd6dbc in _libc_memcpy (dst0=0x38c, src0=0x7b41c0bc, length=2031685792)
>    at /usr/src/lib/libc/string/memcpy.c:54
> 54      /usr/src/lib/libc/string/memcpy.c: No such file or directory.
>        in /usr/src/lib/libc/string/memcpy.c
> Current language:  auto; currently minimal
>
>
> so now? even id I build with debug, I get no better stacktrace. This sounds bad,
>
>
> Riccardo
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Matt Rice-2
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.



On Fri, Mar 30, 2018 at 11:10 AM, Fred Kiefer <[hidden email]> wrote:

> I tried to reproduce this error but failed. Either it is a local problem on your machine or it was already fixed. Could you please try again?
>
> Fred
>
>> Am 30.03.2018 um 00:53 schrieb Riccardo Mottola <[hidden email]>:
>>
>> Hi All,
>>
>> After updating GNUstep on OpenBSD/i386 with gcc, I noticed that all applications segfault. At first, I thought it is a strange combination of an old setup, with system gcc+libobjc1 (which however worked before upgrading)
>> However, I have a second machine where GS was proven working and with gcc 4.9 and its own runtime, a setup that worked before and worked on other system.
>> Test: everything works, update, gnustep base, gui, back : everything segfaults! so that machine is the proof that the commits of the past week broke,
>> I don't see how OpenBSD can be so much different, it worked for a long time.
>>
>> I notice that during gui build:
>>
>> Making all for service GSspell...
>> gmake[4]: Nothing to be done for 'internal-service-compile'.
>> Creating GSspell.service/Resources/Info-gnustep.plist...
>> Segmentation fault (core dumped)
>> gmake[3]: *** [/usr/GNUstep/System/Library/Makefiles/Instance/service.make:141: GSspell.service/Resources/Info-gnustep.plist] Error 1
>>
>> so I found that something as simple as this:
>> $ plparse Source/Info-gnustep.plist
>> Segmentation fault (core dumped)
>>
>> this smells as an issue in base! doesn't it?
>>
>> this even more:
>> $ plparse
>> Segmentation fault (core dumped)
>>
>> however, this is of no use at all!!
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0cfd6dbc in _libc_memcpy (dst0=0x38c, src0=0x7b41c0bc, length=2031685792)
>>    at /usr/src/lib/libc/string/memcpy.c:54
>> 54      /usr/src/lib/libc/string/memcpy.c: No such file or directory.
>>        in /usr/src/lib/libc/string/memcpy.c
>> Current language:  auto; currently minimal
>>
>>
>> so now? even id I build with debug, I get no better stacktrace. This sounds bad,
>>
>>
>> Riccardo
>>
>>
>>
>> _______________________________________________
>> Gnustep-dev mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Riccardo Mottola-5
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.


Riccardo

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

David Chisnall-7
On 7 Apr 2018, at 18:58, Riccardo Mottola <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Fred Kiefer


> Am 07.04.2018 um 20:04 schrieb David Chisnall <[hidden email]>:
>
> On 7 Apr 2018, at 18:58, Riccardo Mottola <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

David Chisnall-7
On 7 Apr 2018, at 19:56, Fred Kiefer <[hidden email]> wrote:
>
> 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.

Eeek!  I didn’t think I’d committed any of that.  Sorry!

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Riccardo Mottola-5
In reply to this post by David Chisnall-7
Hi,

On 2018-04-07 18:04:12 +0000 David Chisnall <[hidden email]> wrote:

>
> 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.


unfortunatley not. I still get a hard crash while running "plmerge". For me it is OpenBSD only, but I got that Gregory has issues on linux to.

I was able to compile with debug and get a better starcktrace, although I think it is corrupted and loops.. or we have some case of /thread recurision

Riccardo


Program received signal SIGSEGV, Segmentation fault.
0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
    at /usr/src/lib/libc/string/memcpy.c:54
54      /usr/src/lib/libc/string/memcpy.c: No such file or directory.
        in /usr/src/lib/libc/string/memcpy.c
Current language:  auto; currently minimal
(gdb) bt
#0  0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
    at /usr/src/lib/libc/string/memcpy.c:54
#1  0x0ba9f956 in _libc_arc4random_buf (buf=0x85d03bd4, n=Variable "n" is not available.
)
    at /usr/src/lib/libc/crypt/arc4random.c:154
#2  0x0ba60cfa in omalloc (sz=Variable "sz" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:308
#3  0x0ba60b72 in malloc (size=Variable "size" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1273
#4  0x0869dd26 in default_malloc (zone=0x286ffa60, size=88) at NSZone.m:124
#5  0x086a0722 in NSZoneMalloc (zone=0x286ffa60, size=88) at NSZone.m:1779
#6  0x085d3bbe in NSAllocateObject (aClass=0x28695760, extraBytes=0,
    zone=0x286ffa60) at NSObject.m:788
#7  0x08586b93 in +[NSHashTable allocWithZone:] (self=0x28695760,
    _cmd=0x286957f0, aZone=0x286ffa60) at NSHashTable.m:51
#8  0x08524303 in NSCreateHashTableWithZone (k=
      {hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c <_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a <_NS_non_owned_void_p_retain>, release = 0x8519e30 <_NS_non_owned_void_p_release>, describe = 0x8519e36 <_NS_non_owned_void_p_describe>}, capacity=10, zone=0x286ffa60)
    at NSConcreteHashTable.m:308
#9  0x08524169 in NSCreateHashTable (callBacks=
      {hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c <_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a <_NS_non_owned_void_p_retain>, release = 0x8519e30 <_NS_non_owned_void_p_release>, describe = 0x8519e36 <_NS_non_owned_void_p_describe>}, capacity=10) at NSConcreteHashTable.m:283
#10 0x0864d4e7 in -[NSThread init] (self=0x7d5aea10, _cmd=0x286c3cc0)
    at NSThread.m:1092
#11 0x085d428d in +[NSObject new] (self=0x286e5080, _cmd=0x286e5248)
    at NSObject.m:1233
#12 0x0864ca6b in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:844
#13 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#14 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#15 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#16 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae110,
    _cmd=0x286e5270) at NSThread.m:769
#17 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#18 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#19 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#20 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#21 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae290,
    _cmd=0x286e5270) at NSThread.m:769
#22 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#23 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#24 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#25 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#26 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae310,
    _cmd=0x286e5270) at NSThread.m:769
#27 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#28 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#29 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#30 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#31 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f990,
    _cmd=0x286e5270) at NSThread.m:769
#32 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#33 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#34 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#35 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#36 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae190,
    _cmd=0x286e5270) at NSThread.m:769
#37 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#38 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#39 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#40 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#41 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f610,
    _cmd=0x286e5270) at NSThread.m:769
#42 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#43 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#44 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#45 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#46 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925fb90,
    _cmd=0x286e5270) at NSThread.m:769
#47 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#48 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#49 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#50 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#51 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f990,
    _cmd=0x286e5270) at NSThread.m:769
#52 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#53 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#54 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#55 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#56 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae690,
    _cmd=0x286e5270) at NSThread.m:769
#57 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#58 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#59 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#60 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#61 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282590,
    _cmd=0x286e5270) at NSThread.m:769
#62 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#63 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#64 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#65 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#66 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282510,
    _cmd=0x286e5270) at NSThread.m:769
#67 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#68 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#69 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#70 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#71 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925fd10,
    _cmd=0x286e5270) at NSThread.m:769
#72 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#73 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#74 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#75 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#76 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4fd90,
    _cmd=0x286e5270) at NSThread.m:769
#77 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#78 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#79 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#80 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#81 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f910,
    _cmd=0x286e5270) at NSThread.m:769
#82 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#83 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#84 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#85 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#86 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f410,
    _cmd=0x286e5270) at NSThread.m:769
#87 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#88 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#89 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#90 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#91 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f910,
    _cmd=0x286e5270) at NSThread.m:769
#92 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#93 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#94 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#95 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#96 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282290,
    _cmd=0x286e5270) at NSThread.m:769
#97 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
    _cmd=0x286e5438) at NSThread.m:846
#98 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#99 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#100 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#101 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f010,
    _cmd=0x286e5270) at NSThread.m:769
#102 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#103 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#104 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#105 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#106 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f710,
    _cmd=0x286e5270) at NSThread.m:769
#107 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#108 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#109 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#110 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#111 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282d90,
    _cmd=0x286e5270) at NSThread.m:769
#112 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#113 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#114 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#115 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#116 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282310,
    _cmd=0x286e5270) at NSThread.m:769
#117 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#118 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#119 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#120 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#121 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900d810,
    _cmd=0x286e5270) at NSThread.m:769
#122 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#123 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#124 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#125 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#126 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae390,
    _cmd=0x286e5270) at NSThread.m:769
#127 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#128 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#129 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#130 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#131 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900d590,
    _cmd=0x286e5270) at NSThread.m:769
#132 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#133 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#134 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#135 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#136 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f510,
    _cmd=0x286e5270) at NSThread.m:769
#137 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#138 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#139 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#140 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#141 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282c90,
    _cmd=0x286e5270) at NSThread.m:769
#142 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#143 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#144 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#145 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#146 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ea0cf90,
    _cmd=0x286e5270) at NSThread.m:769
#147 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#148 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#149 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#150 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#151 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4fa90,
    _cmd=0x286e5270) at NSThread.m:769
#152 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#153 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#154 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#155 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#156 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ccd9f10,
    _cmd=0x286e5270) at NSThread.m:769
#157 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#158 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#159 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#160 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#161 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900df10,
    _cmd=0x286e5270) at NSThread.m:769
#162 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#163 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#164 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#165 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#166 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282010,
    _cmd=0x286e5270) at NSThread.m:769
#167 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
#168 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#169 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#170 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#171 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ccd9d90,
    _cmd=0x286e5270) at NSThread.m:769
#172 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
    self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846

<....>


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Sebastian Reitenbach-2
Hi,
 
Am Dienstag, April 10, 2018 00:28 CEST, Riccardo Mottola <[hidden email]> schrieb:
 

> Hi,
>
> On 2018-04-07 18:04:12 +0000 David Chisnall <[hidden email]> wrote:
>
> > > 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.
>
>
> unfortunatley not. I still get a hard crash while running "plmerge". For me it is OpenBSD only, but I got that Gregory has issues on linux to.
>
> I was able to compile with debug and get a better starcktrace, although I think it is corrupted and loops.. or we have some case of /thread recurision

while debugging GNUMail, I also tried gnustep-base from git, and I saw the very same backtrace, when I tried to rebuild gnustep-gui afterward.
Threre I saw it happen in make_services.

I'm also on OpenBSD, but amd64, built with clang 5.0.1 libobjc2 and gnustep-make, gnustep-gui are latest releases, only gnustep-base was from git.

Sebastian

>
> Riccardo
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
>     at /usr/src/lib/libc/string/memcpy.c:54
> 54      /usr/src/lib/libc/string/memcpy.c: No such file or directory.
>         in /usr/src/lib/libc/string/memcpy.c
> Current language:  auto; currently minimal
> (gdb) bt
> #0  0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
>     at /usr/src/lib/libc/string/memcpy.c:54
> #1  0x0ba9f956 in _libc_arc4random_buf (buf=0x85d03bd4, n=Variable "n" is not available.
> )
>     at /usr/src/lib/libc/crypt/arc4random.c:154
> #2  0x0ba60cfa in omalloc (sz=Variable "sz" is not available.
> ) at /usr/src/lib/libc/stdlib/malloc.c:308
> #3  0x0ba60b72 in malloc (size=Variable "size" is not available.
> ) at /usr/src/lib/libc/stdlib/malloc.c:1273
> #4  0x0869dd26 in default_malloc (zone=0x286ffa60, size=88) at NSZone.m:124
> #5  0x086a0722 in NSZoneMalloc (zone=0x286ffa60, size=88) at NSZone.m:1779
> #6  0x085d3bbe in NSAllocateObject (aClass=0x28695760, extraBytes=0,     zone=0x286ffa60) at NSObject.m:788
> #7  0x08586b93 in +[NSHashTable allocWithZone:] (self=0x28695760,     _cmd=0x286957f0, aZone=0x286ffa60) at NSHashTable.m:51
> #8  0x08524303 in NSCreateHashTableWithZone (k=
>       {hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c <_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a <_NS_non_owned_void_p_retain>, release = 0x8519e30 <_NS_non_owned_void_p_release>, describe = 0x8519e36 <_NS_non_owned_void_p_describe>}, capacity=10, zone=0x286ffa60)
>     at NSConcreteHashTable.m:308
> #9  0x08524169 in NSCreateHashTable (callBacks=
>       {hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c <_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a <_NS_non_owned_void_p_retain>, release = 0x8519e30 <_NS_non_owned_void_p_release>, describe = 0x8519e36 <_NS_non_owned_void_p_describe>}, capacity=10) at NSConcreteHashTable.m:283
> #10 0x0864d4e7 in -[NSThread init] (self=0x7d5aea10, _cmd=0x286c3cc0)
>     at NSThread.m:1092
> #11 0x085d428d in +[NSObject new] (self=0x286e5080, _cmd=0x286e5248)
>     at NSObject.m:1233
> #12 0x0864ca6b in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:844
> #13 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #14 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #15 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #16 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae110,     _cmd=0x286e5270) at NSThread.m:769
> #17 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #18 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #19 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #20 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #21 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae290,     _cmd=0x286e5270) at NSThread.m:769
> #22 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #23 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #24 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #25 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #26 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae310,     _cmd=0x286e5270) at NSThread.m:769
> #27 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #28 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #29 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #30 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #31 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f990,     _cmd=0x286e5270) at NSThread.m:769
> #32 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #33 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #34 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #35 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #36 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae190,     _cmd=0x286e5270) at NSThread.m:769
> #37 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #38 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #39 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #40 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #41 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f610,     _cmd=0x286e5270) at NSThread.m:769
> #42 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #43 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #44 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #45 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #46 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925fb90,     _cmd=0x286e5270) at NSThread.m:769
> #47 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #48 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #49 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #50 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #51 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f990,     _cmd=0x286e5270) at NSThread.m:769
> #52 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #53 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #54 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #55 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #56 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae690,     _cmd=0x286e5270) at NSThread.m:769
> #57 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #58 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #59 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #60 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #61 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282590,     _cmd=0x286e5270) at NSThread.m:769
> #62 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #63 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #64 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #65 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #66 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282510,     _cmd=0x286e5270) at NSThread.m:769
> #67 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #68 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #69 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #70 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #71 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925fd10,     _cmd=0x286e5270) at NSThread.m:769
> #72 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #73 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #74 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #75 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #76 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4fd90,     _cmd=0x286e5270) at NSThread.m:769
> #77 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #78 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #79 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #80 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #81 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f910,     _cmd=0x286e5270) at NSThread.m:769
> #82 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #83 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #84 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #85 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #86 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f410,     _cmd=0x286e5270) at NSThread.m:769
> #87 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #88 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #89 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #90 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #91 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f910,     _cmd=0x286e5270) at NSThread.m:769
> #92 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #93 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #94 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #95 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #96 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282290,     _cmd=0x286e5270) at NSThread.m:769
> #97 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,     _cmd=0x286e5438) at NSThread.m:846
> #98 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #99 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #100 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #101 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f010,     _cmd=0x286e5270) at NSThread.m:769
> #102 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #103 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #104 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #105 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #106 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7925f710,     _cmd=0x286e5270) at NSThread.m:769
> #107 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #108 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #109 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #110 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #111 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282d90,     _cmd=0x286e5270) at NSThread.m:769
> #112 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #113 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #114 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #115 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #116 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282310,     _cmd=0x286e5270) at NSThread.m:769
> #117 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #118 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #119 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #120 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #121 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900d810,     _cmd=0x286e5270) at NSThread.m:769
> #122 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #123 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #124 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #125 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #126 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae390,     _cmd=0x286e5270) at NSThread.m:769
> #127 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #128 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #129 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #130 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #131 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900d590,     _cmd=0x286e5270) at NSThread.m:769
> #132 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #133 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #134 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #135 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #136 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f510,     _cmd=0x286e5270) at NSThread.m:769
> #137 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #138 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #139 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #140 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #141 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282c90,     _cmd=0x286e5270) at NSThread.m:769
> #142 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #143 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #144 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #145 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #146 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ea0cf90,     _cmd=0x286e5270) at NSThread.m:769
> #147 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #148 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #149 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #150 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #151 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4fa90,     _cmd=0x286e5270) at NSThread.m:769
> #152 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #153 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #154 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #155 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #156 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ccd9f10,     _cmd=0x286e5270) at NSThread.m:769
> #157 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #158 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #159 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #160 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #161 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7900df10,     _cmd=0x286e5270) at NSThread.m:769
> #162 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #163 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #164 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #165 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #166 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7b282010,     _cmd=0x286e5270) at NSThread.m:769
> #167 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
> #168 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
> #169 0x0864c3bd in GSCurrentThread () at NSThread.m:673
> #170 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
> #171 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7ccd9d90,     _cmd=0x286e5270) at NSThread.m:769
> #172 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (
>     self=0x286e5080, _cmd=0x286e5438) at NSThread.m:846
>
> <....>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

David Chisnall-7
On 10 Apr 2018, at 07:13, Sebastian Reitenbach <[hidden email]> wrote:

>
> Hi,
>
> Am Dienstag, April 10, 2018 00:28 CEST, Riccardo Mottola <[hidden email]> schrieb:
>
>> Hi,
>>
>> On 2018-04-07 18:04:12 +0000 David Chisnall <[hidden email]> wrote:
>>
>>>> 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.
>>
>>
>> unfortunatley not. I still get a hard crash while running "plmerge". For me it is OpenBSD only, but I got that Gregory has issues on linux to.
>>
>> I was able to compile with debug and get a better starcktrace, although I think it is corrupted and loops.. or we have some case of /thread recurision
>
> while debugging GNUMail, I also tried gnustep-base from git, and I saw the very same backtrace, when I tried to rebuild gnustep-gui afterward.
> Threre I saw it happen in make_services.

This looks like the bug with non-fragile ivars appearing to have different offsets in different libraries.  If I give you a clang patch, are you able to test it?

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Sebastian Reitenbach-2
Hi,
Am Dienstag, April 10, 2018 10:03 CEST, David Chisnall <[hidden email]> schrieb:
 

> On 10 Apr 2018, at 07:13, Sebastian Reitenbach <[hidden email]> wrote:
> >
> > Hi,
> >
> > Am Dienstag, April 10, 2018 00:28 CEST, Riccardo Mottola <[hidden email]> schrieb:
> >
> >> Hi,
> >>
> >> On 2018-04-07 18:04:12 +0000 David Chisnall <[hidden email]> wrote:
> >>
> >>>> 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.
> >>
> >>
> >> unfortunatley not. I still get a hard crash while running "plmerge". For me it is OpenBSD only, but I got that Gregory has issues on linux to.
> >>
> >> I was able to compile with debug and get a better starcktrace, although I think it is corrupted and loops.. or we have some case of /thread recurision
> >
> > while debugging GNUMail, I also tried gnustep-base from git, and I saw the very same backtrace, when I tried to rebuild gnustep-gui afterward. > Threre I saw it happen in make_services.
>
> This looks like the bug with non-fragile ivars appearing to have different offsets in different libraries.  If I give you a clang patch, are you able to test it?

OpenBSD -current just updated to clang 6.0.0 a few days ago, is that fix already part of clang 6.0.0?
I'll have to wait a few days before I upgrade my desktop to test, because there was quite some fallout
in the ports tree because of that clang update, and I have to wait until the most of it is fixed and
packages are available. Then I can retry gnustep-base from GIT.
If the fix is not yet in 6.0.0, then send the patch along, and I can give it a try, but still, I'll need a
few days before upgrading.

cheers,
Sebastian

>
> David
>


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Riccardo Mottola-5
In reply to this post by David Chisnall-7
Hi,

David Chisnall wrote:
> Either of these could cause random crashes in some usage on some platforms.


just for the record - I am getting a crash on NetBSD too.

Riccardo

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Riccardo Mottola-5
further update, I got this mix

OpenBSD/x86 gcc -> plmerge fails because it says its environment is not
setup (no crash)
NetBSD/x86 gcc -> plmerge is fine, but any GUI app crashes
FreeBSD/amd64 clang -> works
Linux/x86 clang -> works
Linux/x86 gcc -> deep crash in plmerge
Linux/PPC gcc -> crash in plmerge

so I am thinking this is maybe more a compiler issue than an OS issue

Riccardo

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Gregory Casamento
Could we roll back the changes which are causing this on master and put them onto a branch so that they can cease blocking development?    

GC 

On Wed, Apr 11, 2018 at 18:53 Riccardo Mottola <[hidden email]> wrote:
further update, I got this mix

OpenBSD/x86 gcc -> plmerge fails because it says its environment is not
setup (no crash)
NetBSD/x86 gcc -> plmerge is fine, but any GUI app crashes
FreeBSD/amd64 clang -> works
Linux/x86 clang -> works
Linux/x86 gcc -> deep crash in plmerge
Linux/PPC gcc -> crash in plmerge

so I am thinking this is maybe more a compiler issue than an OS issue

Riccardo

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Riccardo Mottola-5
In reply to this post by Riccardo Mottola-5
Hi,

Richard just commited some promising fixes.

Things seem better, but not stable. Here a summary of the current
status. OpenBSD seems fine on x86, on amd64 I get some strange issues
that might not be related

FreeBSD/amd64/clang
- seems to work with all apps I tried
- One test failure:
base/NSException/basic.m:
Failed test:     basic.m:51 ... addresses and symbols match


OpenBSD/i386/gcc
- seems to work fine
- Two test failures
base/NSException/basic.m:
Failed test:     basic.m:51 ... addresses and symbols match
base/NSProcessInfo/general.m:
Failed test:     general.m:48 ... -systemUptime works


OpenBSD/amd64/gcc
- gui apps do not start due to some symbol relocations maybe a spurious
error
- Two test failures
base/NSException/basic.m:
Failed test:     basic.m:50 ... call stac addresses is not empty
base/NSProcessInfo/general.m:
Failed test:     general.m:48 ... -systemUptime works

NetBSD/amd64/gcc
things mostly work, but apps spit out an incredible number of errors,
like below:

- test failures:
base/NSException/basic.m:
Failed test:     basic.m:51 ... addresses and symbols match

2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c8521602f0) of class GSDictionary in thread
<NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c852161c60) of class GSNotification in
thread <NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c854dfed90) of class NSFont in thread
<NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c854dfe790) of class NSFont in thread
<NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}



NetBSD/i386/gcc
plmerge "works" however all gui apps crash

(gdb) bt
#0  0xbb20ff0e in pthread_cond_signal () from /usr/lib/libpthread.so.1
#1  0xb7db59fb in _xcb_in_wake_up_next_reader () from
/usr/pkg/lib/libxcb.so.1
#2  0xb7db5b67 in wait_for_reply () from /usr/pkg/lib/libxcb.so.1
#3  0xb7db5ca6 in xcb_wait_for_reply64 () from /usr/pkg/lib/libxcb.so.1
#4  0xb82295dd in _XReply () from /usr/pkg/lib/libX11.so.6
#5  0xb821a014 in XOpenDisplay () from /usr/pkg/lib/libX11.so.6
#6  0xb85b00e4 in -[XGServer _initXContext] (self=0xb8650180,
     _cmd=0xb85f63b0 <_OBJC_SELECTOR_TABLE+240>) at XGServer.m:422
#7  0xb85af246 in -[XGServer initWithAttributes:] (self=0xb8650180,
     _cmd=0xbbbad128 <_OBJC_SELECTOR_TABLE+72>, info=0x0) at XGServer.m:477
#8  0xbb9cdeb4 in +[GSDisplayServer serverWithAttributes:] (
     self=0xbbbad2a0 <_OBJC_Class_GSDisplayServer>, _cmd=0xbbaeb868
<_OBJC_SELECTOR_TABLE+1672>,
     attributes=0x0) at GSDisplayServer.m:187
#9  0xbb826fa0 in -[NSApplication _init] (self=0xb88fb330,
     _cmd=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>) at NSApplication.m:884
#10 0xbb41c688 in -[NSObject performSelector:withObject:] (self=0xb88fb330,
     _cmd=0xbb708d18 <_OBJC_SELECTOR_TABLE+280>, aSelector=0xbbaeb8c0
<_OBJC_SELECTOR_TABLE+1760>,
     anObject=0xb88fb330) at NSObject.m:2009
#11 0xbb491f9a in -[NSObject(NSThreadPerformAdditions)
performSelector:onThread:withObject:waitUntilDone:modes:]
(self=0xb88fb330, _cmd=0xbb708e20 <_OBJC_SELECTOR_TABLE+544>,
     aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
aThread=0xb8860510, anObject=0xb88fb330,
     aFlag=1 '\001', anArray=0xb876a320) at NSThread.m:2094
#12 0xbb491e74 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:]
(self=0xb88fb330, _cmd=0xbb708e28 <_OBJC_SELECTOR_TABLE+552>,
     aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
anObject=0xb88fb330, aFlag=1 '\001',
     anArray=0xb876a320) at NSThread.m:2053
#13 0xbb491edb in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:] (self=0xb88fb330,
_cmd=0xbbaeb8c8 <_OBJC_SELECTOR_TABLE+1768>,
     aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
anObject=0xb88fb330, aFlag=1 '\001')
     at NSThread.m:2063
#14 0xbb825877 in -[NSApplication init] (self=0xb88fb330,


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

David Chisnall-7
On 13 Apr 2018, at 00:31, Riccardo Mottola <[hidden email]> wrote:

>
> Hi,
>
> Richard just commited some promising fixes.
>
> Things seem better, but not stable. Here a summary of the current status. OpenBSD seems fine on x86, on amd64 I get some strange issues that might not be related
>
> FreeBSD/amd64/clang
> - seems to work with all apps I tried
> - One test failure:
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match

This test appears to expect the system backtrace_symbols function to demangle Objective-C method names.  It should probably be changed to a hope rather than an excepted behaviour, because I’ve never seen it pass.

> OpenBSD/i386/gcc
> - seems to work fine
> - Two test failures
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match
> base/NSProcessInfo/general.m:
> Failed test:     general.m:48 ... -systemUptime works

This one probably needs some per-platform plumbing.

>
>
> OpenBSD/amd64/gcc
> - gui apps do not start due to some symbol relocations maybe a spurious error
> - Two test failures
> base/NSException/basic.m:
> Failed test:     basic.m:50 ... call stac addresses is not empty

You may need to link libexecinfo to make this work on OpenBSD (I think we do that by default if it’s found, but maybe it wasn’t installed?)

David
_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation Faults - OpenBSD

Richard Frith-Macdonald-9
In reply to this post by Riccardo Mottola-5


> On 13 Apr 2018, at 00:31, Riccardo Mottola <[hidden email]> wrote:
>
> Hi,
>
> Richard just commited some promising fixes.
>
> Things seem better, but not stable. Here a summary of the current status. OpenBSD seems fine on x86, on amd64 I get some strange issues that might not be related
>
> FreeBSD/amd64/clang
> - seems to work with all apps I tried
> - One test failure:
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match

Pretty harmles ... the system doesn't have the code needed to generate backtrace symbols.  I've added a change to report the addresses an the fact that symbols are not available ... it'll stop the test complaining.

> OpenBSD/i386/gcc
> - seems to work fine
> - Two test failures
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match
> base/NSProcessInfo/general.m:
> Failed test:     general.m:48 ... -systemUptime works

That looks like simple missing information (we lack system specific code to get the information), and has presumably never passed on that platform.

> NetBSD/amd64/gcc
> things mostly work, but apps spit out an incredible number of errors, like below:
>
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without pool for object (0x72c8521602f0) of class GSDictionary in thread <NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without pool for object (0x72c852161c60) of class GSNotification in thread <NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without pool for object (0x72c854dfed90) of class NSFont in thread <NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without pool for object (0x72c854dfe790) of class NSFont in thread <NSThread: 0x72c855daa4c0>{name = (null), num = 126204759418048}

It would be good to know why this system doesn't have an autorelease pool in place when others do.  You could try setting a breakpoint where this is logged and looking at the stacktrace to see how that point in the code was reached.

> NetBSD/i386/gcc
> plmerge "works" however all gui apps crash

This is the only one that looks really concerning.  The log doesn't report the reason for the crash, but it appears to be in the pthread library code ... suggesting some form of memory corruption or perhaps linking issue.  You might try running under valgrind to see if that gives any clues.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev