Sun 21 Feb 2010 06:40:10 AM UTC, comment #7:
Great ... that extra info was sufficient to reproduce the problem and fix it.
The actual problem was an incorrectly initialised zone pointer when converting the constant string to the UTF8 encoding (not an issue if you are using latin1) ... which was causing memory allocation issues.
I have fixed that in svn trunk.
The same bug occurs for -getCString:maxLength:encoding: so using that is not a reliable workaround.
Using the -cString or -dataUsingEncoding: methods would work around the problem safely though.
|
Sun 21 Feb 2010 12:24:38 AM UTC, comment #4:
Actually I am getting a segmentation fault from this code as well.
I am not able to get a proper back trace for this from gdb.
What I noticed is that in getCString_c we hid this condition
if (externalEncoding != internalEncoding)
(gdb) p externalEncoding
$1 = NSUTF8StringEncoding
(gdb) p internalEncoding
$2 = NSISOLatin1StringEncoding
And when I follow the code further down I get:
1463 tmp = NSZoneMalloc(zone, bytes);
(gdb) bt
#0 GSToUnicode (dst=0x7fffffffca70, size=0x7fffffffca7c, src=0x6fca1e "", slen=7326238,
enc=<value optimized out>, zone=<value optimized out>, options=<value optimized out>) at Unicode.m:1463
#1 0x00007ffff70ccdbd in GSStrWiden (s=0x7fffffffcab0) at GSString.m:2403
#2 0x00007ffff70cea79 in getCString_c (self=<value optimized out>, buffer=0x7ecec0 "",
maxLength=2147483646, aRange=..., leftoverRange=<value optimized out>) at GSString.m:1672
#3 0x0000000000400bb6 in main (argc=<value optimized out>, argv=<value optimized out>,
env=<value optimized out>) at getcstring.m:16
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
NSZoneMalloc (zone=0x7ffff70cea79, size=12) at NSZone.m:2013
2013 return (zone->malloc)(zone, size);
From then on the stack is corrupted. I am on a 64 bit machine, not sure what the original poster was using.
|
Sat 20 Feb 2010 05:38:10 PM UTC, comment #2:
I don't have a machine with gnustep to test, but in addition to what Richard mentioned it'd be good to know what [NSString defaultCStringEncoding] is.
looking at the getCString: what Richard said was true for NSString.m but the GSString.m version seems to be quite different.
calling getCString_c() vs getCStringE_c(),
unfortunately i can't see which class of string we're working with.
anyhow it seems possible that this only appears when using a specific string encoding setting.
|
Sat 20 Feb 2010 04:53:12 PM UTC, comment #1:
Your example/test code works fine for me using svn trunk.
So naturally, the questions arise ...
What release of base are you using?
What operating system are you on?
Are you sure you don't have a hardware fault?
Your 'working hack' would not be expected to work since -getCString: works by calling getCString:maxLength:encoding: with the same parameters that you pass, so the most likely causes for the problem would be some form of memory corruption from elsewhere in the code.
|
Sat 20 Feb 2010 09:07:52 AM UTC, original submission:
The followed code makes segfault:
<------------------------------------------------------
#import <Foundation/Foundation.h>
int main(int argc, char *argv, char *env) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *str = [NSString stringWithString:@"string"];
unsigned size = [str length] + 1;
char *buf = malloc(size);
memset(buf, 0, size);
[str getCString: buf];
// [str getCString: buf maxLength:size encoding: [NSString defaultCStringEncoding]];
NSLog(@"%s", buf);
[pool release];
return 0;
}
------------------------------------------------------>
The commented out line is a working hack (instead plain getCString) to avoid the segmentation fault.
My originally intention is to get DBModeller working to create an EOModel. gdl2 uses [NSString getCString:] in some places. I got the segfault everytime I were trying to change the name of an entity had just created.
Steps to reproduce (and to checking):
1) Run DBModeler
2) The Main menu -> Model -> New...
3) The Main menu -> Property -> Add Entity
4) Try to change new entity's name
I get rid of segfaults by that hack been applied to gdl2.
|