bugGNUstep - Bugs: bug #28939, -[NSString getCString:] doesn't...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #28939: -[NSString getCString:] doesn't work

Submitted by:  Sergei Golovin <svg>
Submitted on:  Sat 20 Feb 2010 09:07:52 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

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.

Richard Frith-Macdonald <CaS>
Project Member
Sun 21 Feb 2010 06:07:44 AM UTC, comment #6:

I have just tested base-r29692 on Ubuntu 9.10 Server 32bit in Amazon EC2 (a virtual machine) with the same result. So it isn't a hardware fault.

Sergei Golovin <svg>
Sun 21 Feb 2010 05:45:22 AM UTC, comment #5:

I'm using :

- base: r29670 (2010-02-19)
- OS: Ubuntu 9.10 32bit
Linux acer5610 2.6.31-17-generic-pae #54-Ubuntu SMP Thu Dec 10 17:23:29 UTC 2009 i686 GNU/Linux

GNUSTEP_STRING_ENCODING=NSUTF8StringEncoding

defaultCStringEncoding is NSUTF8StringEncoding as well

Sergei Golovin <svg>
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.

Fred Kiefer <FredKiefer>
Project Member
Sat 20 Feb 2010 07:25:23 PM UTC, comment #3:

It (@"string") is a constant string ... so getCString_c() will be used, but really the same reasoning applies ... both methods simply call the same underlying code ... which makes it likely that a separate memory corruption issue is causing a failure wiht one method but not the other simply because using different methods changes where things are located in memory.

Richard Frith-Macdonald <CaS>
Project Member
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.

matt rice <ratmice>
Project Member
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.

Richard Frith-Macdonald <CaS>
Project Member
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.

Sergei Golovin <svg>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by ratmice (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by svg (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 21 Feb 2010 06:40:10 AM UTCCaSOpen/ClosedOpen=>Closed
    Sun 21 Feb 2010 06:40:09 AM UTCCaSStatusNeed Info=>Fixed
    Sat 20 Feb 2010 04:53:12 PM UTCCaSStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1