Re: signal SIGSEGV, Segmentation fault

The best way to find out about this would be to run the application with valgrind. Many mysterious problems became quite clear when looking at them through the valgrind toolset. If you require help with that, I could provide you with detailed instructions.

I will probably need help with that. :-) How would I start?

That is a simple three steps process:

- Get and install valgrind (sudo apt-get install valgrind)

- Start your application with valgrind (valgrind Ink.app/Ink)

- Be very patient, use your application as usual and watch the messages scroll by in the console.

And when the segmentation vault happens valgrind will be able to tell you what caused it.

Thanks for the hint. valgrind reports

2018-05-22 11:23:16.323 TimberNav[7685:7685] MapView drawRect {x = 0; y = 0; width = 817; height = 334} ... _osmDrawing 0

2018-05-22 11:23:16.327 TimberNav[7685:7685] After super drawRect:rect

2018-05-22 11:23:16.328 TimberNav[7685:7685] bums

==7685== Use of uninitialised value of size 4

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==

==7685== Invalid write of size 1

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd

==7685==

==7685==

==7685== Process terminating with default action of signal 11 (SIGSEGV)

==7685==  Access not within mapped region at address 0x134

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==  If you believe this happened as a result of a stack

==7685==  overflow in your program's main thread (unlikely but

==7685==  possible), you can try to increase the size of the

==7685==  main thread stack using the --main-stacksize= flag.

==7685==  The main thread stack size used in this run was 8388608.

==7685==

==7685== HEAP SUMMARY:

==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks

==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated

==7685==

==7685== LEAK SUMMARY:

==7685==    definitely lost: 49,171 bytes in 1,041 blocks

==7685==    indirectly lost: 457,010 bytes in 8,088 blocks

==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks

==7685==    still reachable: 3,715,526 bytes in 44,342 blocks

==7685==                       of which reachable via heuristic:

==7685==                         newarray           : 69,036 bytes in 303 blocks

==7685==         suppressed: 0 bytes in 0 blocks

==7685== Rerun with --leak-check=full to see details of leaked memory

==7685==

==7685== For counts of detected and suppressed errors, rerun with: -v

==7685== Use --track-origins=yes to see where uninitialised values come from

==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

==7685== Use of uninitialised value of size 4

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==

==7685== Invalid write of size 1

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==  Address 0x134 is not stack'd, malloc'd or (recently) free'd

==7685==

==7685==

==7685== Process terminating with default action of signal 11 (SIGSEGV)

==7685==  Access not within mapped region at address 0x134

==7685==    at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)

==7685==    by 0xBEAD8617: ???

==7685==  If you believe this happened as a result of a stack

==7685==  overflow in your program's main thread (unlikely but

==7685==  possible), you can try to increase the size of the

==7685==  main thread stack using the --main-stacksize= flag.

==7685==  The main thread stack size used in this run was 8388608.

==7685==

==7685== HEAP SUMMARY:

==7685==     in use at exit: 7,671,140 bytes in 99,510 blocks

==7685==   total heap usage: 345,414 allocs, 245,904 frees, 38,473,207 bytes allocated

==7685==

==7685== LEAK SUMMARY:

==7685==    definitely lost: 49,171 bytes in 1,041 blocks

==7685==    indirectly lost: 457,010 bytes in 8,088 blocks

==7685==      possibly lost: 3,449,433 bytes in 46,039 blocks

==7685==    still reachable: 3,715,526 bytes in 44,342 blocks

==7685==                       of which reachable via heuristic:

==7685==                         newarray           : 69,036 bytes in 303 blocks

==7685==         suppressed: 0 bytes in 0 blocks

==7685== Rerun with --leak-check=full to see details of leaked memory

==7685==

==7685== For counts of detected and suppressed errors, rerun with: -v

==7685== Use --track-origins=yes to see where uninitialised values come from

==7685== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

- (void)drawRect:(NSRect)rect

{

NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect), _osmDrawing);

[super drawRect:rect];

NSLog(@"After super drawRect:rect");

[self bums];

// if (image != nil && _osmDrawing == NO)

{

NSImage *image = [self image];

NSSize imageSize = [image size];

_routeVisible = YES; // <--- this sis line 168

// draw route

NSLog(@"routeVisible: %d", _routeVisible);

NSLog(@"routePath: %@", _routePath);

...

}

I am accessing a BOOL ivar of MapView in the line that crashes the app.

MapView : ESMMapView : GSImageView : NSImageView

MapView is a subclass of NSImageView (see above inheritance string). Each subclass adds properties, some are public.

@interface MapView : ESMMapView

{

NSPoint _currentPosition;

NSTimer *_routeFadeTimer;

float _positionAlpha;

BOOL _addAlpha;

NSString *_message;

NSArray *_routeNodes;

NSBezierPath *_routePath;

NSArray *_departurePaths;

NSArray *_arrivalPaths;

NSArray *_overlayPaths;

BOOL _routeVisible;

BOOL _departurePathVisible;

BOOL _arrivalPathVisible;

}

The code works great under MacOSX and also worked under the old GNUstep/debian system. On Ubuntu with current GNUstep it fails.

Any further ideas?

Thanks a lot,

 Andreas

From:	Andreas Höschler
Subject:	Re: signal SIGSEGV, Segmentation fault
Date:	Tue, 22 May 2018 11:31:47 +0200