Understanding SIGSEGV issues

Nicholas Wilson iamthewilsonator at hotmail.com
Tue Jan 8 11:51:54 UTC 2019


On Tuesday, 8 January 2019 at 10:23:30 UTC, Russel Winder wrote:
> 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.

Ahh. Good that you've found that, I can't help you much more with 
that then.

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

No problems, less code is good code.

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

I believe Andrei and Razvan are working on that, part of that 
being the Copy Constructor DIP. Hopefully it will arrive soon.

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

Indeed, less to think about is always nice.

Good luck figuring out why your data is dud.
Nic


More information about the Digitalmars-d-learn mailing list