Understanding SIGSEGV issues

[Russel Winder]

On Sat, 2019-01-05 at 13:14 +0000, Nicholas Wilson via Digitalmars-d-learn
wrote:
> 
[…]
> Your problem possibly (probably?) stems from
> 
> auto channelsData = TransmitterData(args[1]).scan(frontendId);
> 
> The temporary TransmitterData(args[1]) is, well, temporary and 
> its destructor runs after that expression is done. As the 
> returned object from scan references data from the temporary, you 
> have a stale pointer.

Actually that is not a worry since the TransmitterData instance is only needed
to call the scan function which creates a ChannelsData instance that holds no
references to the TransmitterData instance.

It turns out that whilst the code used to run, and now doesn't, all the things
we have been talking of are nothing to do with the core problem. It turns out
that the function call to initialise the File_Ptr object is returning a valid
object with invalid data. Thus the unknown change is likely in the libdvbv5
library either due to the C API doing different things or the adapter created
using DStep doing the wrong thing.
 
> > I have a feeling that I am really not doing things in a D 
> > idiomatic way.
> 
> Some driveby style comments then:
> 
> > 	bool opEquals()(const FrontendId other) const {
> > 		if (this is other) return true;
> > 		if (other is null) return false;
> > 		return this.adapter_number == other.adapter_number && 
> > this.frontend_number == other.frontend_number;
> > 	}
> 
> The compiler generated default opEquals will do basically the 
> same thing. Ditto for the other types. You usually want to take a 
> const ref for opEquals since there is no point copying it.

I deleted them, added a test or three (should have done this ages ago) and the
tests pass. So teh generated methods do the needful. Thanks for that "heads
up".

> > if (other is null)
> 
> I'm surprised the compiler doesn't warn or error on that as the 
> only way that could make sense would be if it had an alias this 
> to a pointer type.
> 
> You should consider reference counting your pointer wrapper 
> types, FrontendParameters_Ptr/File_Ptr/ScanHandler_Ptr

Very true. For now I have forbidden copying, which is wrong for this sort of
thing. If D had the equivalent of C++ std::shared_ptr or Rust std::rc::Rc or
std::rc::Arc, that would be the way forward But I guess having explicit
reference counting is not too hard.

> You seem to like const, good! You don't need to take `const int`s 
> as parameters, you're getting a copy anyway. You have a bunch of 
> redundant casts as well.

I am a person who always makes Java variables final, and loves that Rust
variables are immutable by default!

-- 
Russel.
===========================================
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/20190108/86fa4f29/attachment.sig>