segmentation failure plmerge / building libs back

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

segmentation failure plmerge / building libs back

Riccardo Mottola-5
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: segmentation failure plmerge / building libs back

Richard Frith-Macdonald-9
> On 10 Aug 2018, at 10:40, Riccardo Mottola <[hidden email]> 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.



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

Re: segmentation failure plmerge / building libs back

Riccardo Mottola-5
Hi Richard,

sorry for the late answer, I was away without access to that specific
computer.

Richard Frith-Macdonald wrote:
> 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.

Well, it is libobjc2 "head" of git and I configured to use "ng" runtime,
so it should be David's ABI.

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

As you suggested, I put a breakpoint in [NSBundle initialize]

I was able to step until 1180 and print put the variables and as you
supposed they are string constants looking fine.

1180            gnustep_target_dir = [[NSString alloc] initWithFormat:
@"%@-%@",
(gdb) p gnustep_target_cpu
$1 = (struct NSString *) 0xb7f59920 <.objc_str>
(gdb) p gnustep_target_os
$2 = (struct NSString *) 0xb7f5992c <.objc_str>
(gdb) po gnustep_target_cpu
ix86
(gdb) po gnustep_target_os
linux-gnu

however, as could be guessed, the next step fails
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xb7b76294 in GSPrivateFormat (s=0xbfffdc34, format=0xbfffe45c,
     ap=0xbfffecc0 "
\231\365\267,\231\365\267\204\237\365\267\210\221\365\314/\350\273\267\320\003\016\bP\032\275\267$\217\365\267\060\217\365\267\204\237\365\267P\220\365\267D\220\365\267\004r\"\b\016\b\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\314\235\365\267"...,
locale=0x0) at GSFormat.m:1046
1046        for (; (size_t) nspecs_done < nspecs; ++nspecs_done)

I tried to setp into the string allocation and see where it fails and it
appears here:

(gdb) s
Single stepping until exit from function objc_msgSend,
which has no line number information.
+[NSObject alloc] (self=0xb7bbe82f <+[NSBundle initialize]+15>,
_cmd=0x80e03d0)
     at NSObject.m:1120
1120    + (id) alloc

(gdb) n
1122      return [self allocWithZone: NSDefaultMallocZone()];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.

#0  0xb7b76294 in GSPrivateFormat (s=0xbfffdc34, format=0xbfffe45c,
     ap=0xbfffecc0 "
\231\365\267,\231\365\267\204\237\365\267\210\221\365\267/\350\273\267\320\003\016\bP\032\275\267$\217\365\267\060\217\365\267\204\237\365\267P\220\365\267D\220\365\267\004r\"\b\016\b\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\314\235\365\267"...,
locale=0x0) at GSFormat.m:1046
#1  0xb7b8c54e in -[GSPlaceholderString initWithFormat:locale:arguments:] (
     self=0x8171ab4, _cmd=0xb7f904e4 <.objc_selector_list+432>,
     format=0xb7f59194 <.objc_str.170>, locale=0x0,
     argList=0xbfffecc0 "
\231\365\267,\231\365\267\204\237\365\267\210\221\365\267/\350\273\267\320\003\016\bP\032\275\267$\217\365\267\060\217\365\267\204\237\365\267P\220\365\267D\220\365\267\004r\"\b\016\b\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\
#2  0xb7ca9552 in -[NSString initWithFormat:] (self=<optimized out>,
     _cmd=<optimized out>, format=<optimized out>) at NSString.m:1366
#3  0xb7bbf0ac 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  0xb7cdc51f in +[NSUserDefaults standardUserDefaults] (
     self=<optimized out>, _cmd=<optimized out>) at NSUserDefaults.m:995
#9  0xb7c08915 in -[NSDictionary writeToFile:atomically:] (
     self=<optimized out>, _cmd=<optimized out>, path=<optimized out>,
     useAuxiliaryFile=<optimized out>) at NSDictionary.m:1096
#10 0x080496e4 in main (argc=<optimized out>, argv=<optimized out>,
     env=<optimized out>) at plmerge.m:135

we are at
588      GSPrivateFormat(f, fmt, argList, locale);

I printed out f and fmt locale is 0x0

(gdb) p *f
$4 = {<> = {<> = {<> = {
         isa = 0x8098f00}, <No data fields>}, <No data fields>},
_contents = {
     u = 0x8098f00, c = 0x8098f00 "P\222\t\b`\267\017\b\255\225\324\267"},
   _count = 134844160, _flags = {wide = 0, owned = 0, unused = 0,
     hash = 8427760}, _capacity = 134844160, _zone = 0x8098f00}

(gdb) p *fmt
$6 = 37



Can we assume that NSObject's alloc (line 1122) passed successfully? Do
you get any smarter? I don't...


Riccardo

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