Sorry, right, I should have said lines 7, 8, or 9 which crash GDB --
inexplicably. Other dynamic objc in GDB does not crash GDB. Could it be
something with NSUserDefaults itself?
On Aug 21, 2016, at 9:04 AM, Fred Kiefer <fredkie...@gmx.de> wrote:
In line 10 the variable ud no longer has a defined value. The autorelease pool
that manages this value gets released in line 9 and no mor references to that
variable should happen. It isn't great that gdb just crashes, but on Windows
they seem to have issues with illegal memory access.
Fred
On the road
Am 21.08.2016 um 14:12 schrieb Giah de Barag <g...@crelg.com>:
> Can anyone on MSYS2 replicate this recipe for crashing GDB?
>
>
> 1. Install MSYS2. Update pacman.
>
> 2. Install packages and build GS (modules/scripts).
>
> 3. Build the program below and run gdb on it.
>
>
> gdb commands:
>
> b main
> r
> tbreak 10 # in front of the return
> c
> print [ud objectForKey:@"foo”] # GDB crashes
>
>
> program:
>
> #import <Foundation/Foundation.h>
>
> int main( int argc, const char *argv[] )
> {
> id pool = [NSAutoreleasePool new];
> id ud = [NSUserDefaults standardUserDefaults];
> id foo = [ud objectForKey:@"foo"];
> printf("foo = %s\n", foo ? [foo cString] : "missing"); fflush(stdout);
> [pool release];
> #line 10
> return 0;
> }
>
>
>
> Note:
>
> Using old MSYS GNUstep installed from Installers, it crashes right on “b
> main” (as previously reported) and if update all packages with mingw-get and
> rebuild GNUstep, it crashes as above.
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
