Understanding SIGSEGV issues

[Steven Schveighoffer]

On 1/5/19 6:33 AM, Russel Winder wrote:
> On Sat, 2019-01-05 at 10:52 +0000, Russel Winder wrote:
>> On Sat, 2019-01-05 at 10:31 +0000, Nicholas Wilson via Digitalmars-d-learn
>> wrote:
>> […]
>>> Maybe it is a problem with copying a File_Ptr (e.g. missing a
>>> increase of the reference count)? Like, `auto a = File_Ptr(); {
>>> auto b = a; }` and b calls the destructor on scope exit.
>>> That would be consistent with having problems copying to object
>>> to pass to writeln.
>>
>> I found the problem and then two minutes later read your email and bingo we
>> have found the problem.
>>
>> Previously I had used File_Ptr* and on this occasion I was using File_Ptr
>> and
>> there was no copy constructor because I have @disable this(this). Except
>> that
>> clearly copying a value is not copying a value in this case. Clearly this
>> situation is what is causing the destructor to be called on an unconstructed
>> value. But I have no idea why.
>>
>> The question now, of course, is should I have been using File_Ptr instead of
>> File_Ptr* in the first place. I am beginning to think I should have been.
>> More
>> thinking needed.
> 
> Switching to using File_Ptr* I now get the SIGSEGV at the end of main as you
> were thinking before. Oh f###.
> 
> This code used to work. :-(
> 

Russel, make sure your destructor both checks whether the underlying 
resource is set, and clears it to invalid when freeing it.

Even types that can't be copied can be moved, or temporarily created as 
rvalues. When they are moved the shell they get moved out of is still 
destructed! So it has to have a state where it can be destroyed, even 
though there is no resource.

Maybe some inspiration here: 
https://github.com/MartinNowak/io/blob/master/src/std/io/file.d#L189-L196

-Steve