Understanding SIGSEGV issues

Russel Winder russel at winder.org.uk
Sat Jan 5 07:34:17 UTC 2019

On Thu, 2019-01-03 at 11:23 +0000, Nicholas Wilson via Digitalmars-d-learn
> 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):

I am not sure this analysis is correct. The code never reaches the end of

> 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().

TransmitterData has a destructor defined but with no code in it. This used to
work fine – but I cannot be certain which version of LDC that was.

The problem does seem to be in the construction of the TransmitterData object
because a destructor is being called on the File_Ptr field as part of the
transmitterData constructor.

> 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.

For some reason it seems File_Ptr.~this() is being called before
File_Ptr.this() in the TransmitterData.this(). This is totally weird.

Having added some writeln statements:

(gdb) bt
#0  0x00005555555932e0 in dvb_file_free (dvb_file=0x0) at dvb_file.d:276
#1  0x0000555555592fbc in types.File_Ptr.~this() (this=...) at types.d:83
#2  0x000055555558cdf6 in _D3std6format__T14formattedWriteTSQBg5stdio4File17LockingTextWriterTaTS5types8File_PtrZQCtFKQChxAaQBcZk (w=..., fmt=..., _param_2=...) at /usr/lib/ldc/x86_64-linux-gnu/include/d/std/format.d:472
#3  0x000055555558c6a8 in _D3std5stdio4File__T5writeTAyaTS5types8File_PtrTaZQBeMFQBcQBbaZv (this=..., _param_0=..., _param_1=..., _param_2=10 '\n') at channels.d:1586
#4  0x00005555555749ce in _D3std5stdio__T7writelnTAyaTS5types8File_PtrZQBeFQzQxZv (_param_0=..., _param_1=...) at channels.d:3917
#5  0x000055555556af49 in _D8channels15TransmitterData6__ctorMFNcxAyaxkxE10libdvbv5_d8dvb_file16dvb_file_formatsZSQDiQDc (this=..., path=..., delsys=0, format=libdvbv5_d.dvb_file.dvb_file_formats.FILE_DVBV5) at channels.d:143
#6  0x000055555556aa9c in D main (args=...) at main.d:34

Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20190105/d6d2f578/attachment.sig>

More information about the Digitalmars-d-learn mailing list