Hi Richard,
>> Aha, interesting. But this still rings no bell (no idea how this could be).
>
> Well, anything that overwrite the memory location in which 'self' is stored
> could cause this.
> The most common thing (as suggested by Wolfgang) would be if the object was
> deallocated and the memory re-used (a retain/release error),
The object is not deallocated as I have shown with a log message in -dealloc.
> but buffer overruns could also corrupt the memory.
> Fred's suggestion of running under valgrind should help find the problem in
> either case.
This gave me nothing (see below).
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 is line 168
// draw route
NSLog(@"routeVisible: %d", _routeVisible);
NSLog(@"routePath: %@", _routePath);
...
}
Thanks,
Andreas
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
