Re: signal SIGSEGV, Segmentation fault

[Richard Frith-Macdonald]

> On 22 May 2018, at 13:55, Andreas Höschler <ahoesch@smartsoft.de> wrote:
> 
> 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: ???

Well it tells you that some uninitialised value is used at line 168 ... 

We already knew that, but I guess the fact that there's no problem reported 
preceding it means that there's no obvious memory management/corruption issue 
like a buffer overrun on the heap, and something is specifically setting that 
location in memory.

You might need to actively debug the program to find out what's going on ... 
use gdb to break at the start ofd the method and then step through, instruction 
by instruction, examining key values to see at what point things change.