[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: segmentation failure plmerge / building libs back
|
From: |
Richard Frith-Macdonald |
|
Subject: |
Re: segmentation failure plmerge / building libs back |
|
Date: |
Sat, 11 Aug 2018 09:58:16 +0100 |
> On 10 Aug 2018, at 10:40, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
>
> Hi,
>
> I just updated my Gentoo box (i386) with compiler, libraries, kernel, etc. So
> I reconfigured and rebuilt all GNUstep.
>
> make is configured with:
> ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu
> CC=clang CXX=clang++
>
>
> Everything is compiled with clang6 and "ng runtime" is enabled (or we get
> other porblems with libobjc2 which I did not get sorted out with David yet)
>
> When building gnustep back I get:
>
> Creating libgnustep-back-026.bundle/Resources/Info-gnustep.plist...
> /bin/sh: line 2: 8299 Segmentation fault plmerge
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist
> libgnustep-back-026Info.plist
>
> which can be reproduced on the command line:
>
> $ plmerge libgnustep-back-026.bundle/Resources/Info-gnustep.plist
> libgnustep-back-026Info.plist
> Segmentation fault
>
> the executable itself runs:
>
> $ plmerge
> Usage: plmerge [destination-file] [input-file ...]
>
>
> so it dies when acutally trying to do something :)
>
> THis in the debugger:
>
> Program received signal SIGSEGV, Segmentation fault.
>
> (gdb) bt
> #0 0xb7b76274 in GSPrivateFormat (s=0xbfffdc24, format=0xbfffe44c,
> ap=0xbfffecb0 "
> \231\365\267,\231\365\267T\236\365\267\210\221\365\267\037\350\273\267\320\003\016\b@\032\275\267$\217\365\267\060\217\365\267T\236\365\267P\220\365\267D\220\365\267\024h\"\b.\a\324\267\030\217\365\267\360\217\365\267\344\217\365\267\330\217\365\267\314\217\365\267\300\217\365\267\264\217\365\267\f\217\365\267\250\217\365\267\234\217\365\267\220\217\365\267\204\217\365\267x\217\365\267`\217\365\267l\217\365\267T\217\365\267<\217\365\267\354\220\365\267\340\220\365\267\324\220\365\267\310\220\365\267\274\220\365\267\260\220\365\267\244\220\365\267\230\220\365\267\214\220\365\267
>
> \220\365\267\200\220\365\267\024\220\365\267t\220\365\267h\220\365\267\070\220\365\267,\220\365\267\374\217\365\267\\\220\365\267\214\237\365\267"...,
> locale=0x0) at GSFormat.m:1046
> #1 0xb7b8c53e in -[GSPlaceholderString initWithFormat:locale:arguments:]
> (self=0x81722e4,
> _cmd=0xb7f90714 <.objc_selector_list+992>, format=0xb7f59194
> <.objc_str.170>, locale=0x0,
> argList=0xbfffecb0 "
> \231\365\267,\231\365\267T\236\365\267\210\221\365\267\037\350\273\267\320\003\016\b@\032\275\267$\217\365\267\060\217\365\267T\236\365\267P\220\365\267D\220\365\267\024h\"\b.\a\324\267\030\217\365\267\360\217\365\267\344\217\365\267\330\217\365\267\314\217\365\267\300\217\365\267\264\217\365\267\f\217\365\267\250\217\365\267\234\217\365\267\220\217\365\267\204\217\365\267x\217\365\267`\217\365\267l\217\365\267T\217\365\267<\217\365\267\354\220\365\267\340\220\365\267\324\220\365\267\310\220\365\267\274\220\365\267\260\220\365\267\244\220\365\267\230\220\365\267\214\220\365\267
>
> \220\365\267\200\220\365\267\024\220\365\267t\220\365\267h\220\365\267\070\220\365\267,\220\365\267\374\217\365\267\\\220\365\267\214\237\365\267"...)
> at GSString.m:1588
> #2 0xb7ca9482 in -[NSString initWithFormat:] (self=<optimized out>,
> _cmd=<optimized out>, format=<optimized out>)
> at NSString.m:1366
> #3 0xb7bbf09c in +[NSBundle initialize] (self=<optimized out>,
> _cmd=<optimized out>) at NSBundle.m:1180
> #4 0xb79da15c in objc_send_initialize () from
> /System/Library/Libraries/libobjc.so.4.6
> #5 0xb79e64d8 in slowMsgLookup () from
> /System/Library/Libraries/libobjc.so.4.6
> #6 0xb79ec5e1 in objc_msgSend () from
> /System/Library/Libraries/libobjc.so.4.6
> #7 0xb7b665e0 in GSLanguageFromLocale (locale=<optimized out>) at
> GSLocale.m:264
> #8 0xb7cdc44f in +[NSUserDefaults standardUserDefaults] (self=<optimized
> out>, _cmd=<optimized out>) at NSUserDefaults.m:995
> #9 0xb7c088e5 in -[NSDictionary writeToFile:atomically:] (self=<optimized
> out>, _cmd=<optimized out>, path=<optimized out>,
> useAuxiliaryFile=<optimized out>) at NSDictionary.m:1096
>
> (gdb) p (size_t) nspecs_done
> $1 = 0
> (gdb) p nspecs
> $2 = <optimized out>
>
>
> Any ideas? trying to understand if this is a base issue or a runtime/libobjc2
> issue
>
> It actually comes from libobjc which calls base..
>
> I tried compiling with debug to get more information in the stacktrace, but
> the problem"goes away" confirming some kind of memory issue!
>
> Last thingI tried was running plmerge with valgrind and found:
> ==10969== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==10969== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==10969== Command: plmerge
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist
> libgnustep-back-026Info.plist
> ==10969==
> ==10969==
> ==10969== HEAP SUMMARY:
> ==10969== in use at exit: 2,237,034 bytes in 13,761 blocks
> ==10969== total heap usage: 24,707 allocs, 10,946 frees, 5,072,188 bytes
> allocated
> ==10969==
> ==10969== LEAK SUMMARY:
> ==10969== definitely lost: 90,396 bytes in 2,034 blocks
> ==10969== indirectly lost: 0 bytes in 0 blocks
> ==10969== possibly lost: 582,205 bytes in 2,440 blocks
> ==10969== still reachable: 1,564,433 bytes in 9,287 blocks
> ==10969== of which reachable via heuristic:
> ==10969== newarray : 2,432 bytes in 59
> blocks
> ==10969== suppressed: 0 bytes in 0 blocks
> ==10969== Rerun with --leak-check=full to see details of leaked memory
> ==10969==
> ==10969== For counts of detected and suppressed errors, rerun with: -v
> ==10969== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> O fine, nothing... that is the debug version! Let's run the original
> optimized version.รน
>
> multix@think ~/gnustep-cvs/libs-back/Source $ valgrind plmerge
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist
> libgnustep-back-026Info.plist
> ==13281== Memcheck, a memory error detector
> ==13281== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==13281== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==13281== Command: plmerge
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist
> libgnustep-back-026Info.plist
> ==13281==
> ==13281==
> ==13281== Process terminating with default action of signal 11 (SIGSEGV)
> ==13281== General Protection Fault
> ==13281== at 0x417C294: GSPrivateFormat (GSFormat.m:0)
> ==13281== by 0x419254D:
> _i_GSPlaceholderString__initWithFormat_locale_arguments_ (GSString.m:1588)
> ==13281== by 0x42AF551: _i_NSString__initWithFormat_ (NSString.m:1366)
> ==13281== by 0x41C50AB: _c_NSBundle__initialize (NSBundle.m:1180)
> ==13281== by 0x461D15B: objc_send_initialize (in
> /System/Library/Libraries/libobjc.so.4.6)
> ==13281== by 0x46294D7: slowMsgLookup (in
> /System/Library/Libraries/libobjc.so.4.6)
> ==13281== by 0x462F5E0: ??? (in /System/Library/Libraries/libobjc.so.4.6)
> ==13281== by 0x416C5DF: GSLanguageFromLocale (GSLocale.m:264)
> ==13281== by 0x42E251E: _c_NSUserDefaults__standardUserDefaults
> (NSUserDefaults.m:995)
> ==13281== by 0x420E914: _i_NSDictionary__writeToFile_atomically_
> (NSDictionary.m:1096)
> ==13281== by 0x80496E3: main (plmerge.m:135)
> ==13281==
> ==13281== HEAP SUMMARY:
> ==13281== in use at exit: 2,321,035 bytes in 13,940 blocks
> ==13281== total heap usage: 15,949 allocs, 2,009 frees, 4,385,163 bytes
> allocated
> ==13281==
> ==13281== LEAK SUMMARY:
> ==13281== definitely lost: 90,376 bytes in 2,032 blocks
> ==13281== indirectly lost: 0 bytes in 0 blocks
> ==13281== possibly lost: 270,639 bytes in 1,704 blocks
> ==13281== still reachable: 1,960,020 bytes in 10,204 blocks
> ==13281== of which reachable via heuristic:
> ==13281== newarray : 5,893 bytes in 132
> blocks
> ==13281== suppressed: 0 bytes in 0 blocks
> ==13281== Rerun with --leak-check=full to see details of leaked memory
> ==13281==
> ==13281== For counts of detected and suppressed errors, rerun with: -v
> ==13281== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> Segmentation fault
I wouldn't say that.
You can see that this is building a string from +initialize in NSBundle.m at
line 1180
You can then look at the source and check that the format string looks correct
and the number of argument passed is correct.
You can also look at where those two arguments come from, and see that they are
(most likely) to be literal/constant strings produced by the compiler.
If this is using David's new ABI ... the problem might well be a bug in the new
code or (more likely) a mismatch between the layout the compiler is producing
and the library is expecting.
Anyway, it tells you that you can run the program under gdb, set a breakpoint
in +[NSBundle initialize] and look at exactly what's being passed to narrow
things down more.