Understanding SIGSEGV issues

[Nicholas Wilson]

On Thursday, 3 January 2019 at 08:35:17 UTC, Russel Winder wrote:
> Sorry about that, fairly obvious that the backtrace is needed 
> in hindsight. :- )
>
> #0  __GI___libc_free (mem=0xa) at malloc.c:3093
> #1  0x000055555558f174 in dvb_file_free 
> (dvb_file=0x5555555a1320) at dvb_file.d:282
> #2  0x000055555558edcc in types.File_Ptr.~this() (this=...) at 
> types.d:83
> #3  0x0000555555574809 in 
> channels.TransmitterData.__fieldDtor() (this=<error reading 
> variable: Cannot access memory at address 0xa>) at 
> channels.d:144
> #4  0x000055555556aeda in channels.TransmitterData.__aggrDtor() 
> (this=...) at channels.d:144
> #5  0x000055555556ab53 in D main (args=...) at main.d:33
>
> Which indicates that the destructor is being called before the 
> instance has been constructed. Which is a real WTF.

Not quite, this occurs as a TransmitterData object goes out of 
scope at the end of main(stick a fflush'ed printf there to see):

TransmitterData is a struct that has no destructor defined but 
has a field of type File_Ptr that does. The compiler generates a 
destructor, __aggrDtor, which calls the fields that have 
destructors, __fieldDtor (e.g. the File_Ptr) which in turn calls 
its destructor, File_Ptr.~this().

As you can see from the stack trace #3, the File_Ptr is null. The 
solution to this is to either ensure it is initialised in the 
constructor of TransmitterData, or account for it possibly being 
null by defining a destructor for TransmitterData.