Understanding SIGSEGV issues

[Nicholas Wilson]

On Saturday, 5 January 2019 at 12:14:15 UTC, Russel Winder wrote:
> Indeed. I should do that to see if I can reproduce the problem 
> to submit a proper bug report.
>
> File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make 
> things a bit for D and to ensure RAII. libdvbv5 is a C API with 
> classic C approach to handling objects and data structures.
>
> My DStep/with manual binding is at 
> https://github.com/russel/libdvbv5_d and the application using 
> it (which is causing the problems) is at 
> https://github.com/russel/DVBTune

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.

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

> 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

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'll have another looks tomorrow when I'm a bit more awake.