Hi Fred and all,
>>> 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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
