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.
