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
no help, right?
Riccardo
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
