Re-sending after unarchiving bug.
On 16/03/26 8:03 pm, Nilesh Patra wrote:
>>> The latter has `elf_storage` and `elf_storage_by_member` functions, that do
>>> call the `create` function, but never the `DESTROY` one.
>>
>> Lintian::Storage::MLDBM uses the Moo object system, which provides
>> the DEMOLISH method (man 3 Moo):
>>
>> DEMOLISH
>> sub DEMOLISH {
>> my ($self, $in_global_destruction) = @_;
>> ...
>> }
>>
>> When an object is destroyed, any "DEMOLISH" methods in the
>> inheritance hierarchy will be called on the object. They are
>> given boolean to inform them if global destruction is in
>> progress, and are called from the child class upwards to the
>> parent. This is similar to "BUILD" methods but in the opposite
>> order.
>>
>> Now the interesting question is why this doesn't happen …
>
> I know this bug has been long closed, but I was looking at specifically this
> part (destructor not running)
> it today. I added in a couple of prints/warns in DEMOLISH and I can see that
> it was infact, being called
> perfectly.
>
> I then tried to print $self->tempfile->stringify on a test on lintian's
> testsuite. It gave the right name
> for one file but an undef for the second file.
>
> It's a bit hard to confirm the exact reason as to why this happened, but I
> suppose this is happening due to global destruction.
> So it's probably that "Path::Tiny->tempfile" called its destructor before the
> MLDBM class got a chance to do that.
>
> I then tried to use the filename instead of filerefs to delete the actual
> file. Something like this:
>
> diff --git a/lib/Lintian/Storage/MLDBM.pm b/lib/Lintian/Storage/MLDBM.pm
> index f58cb8c96..6436b0028 100644
> --- a/lib/Lintian/Storage/MLDBM.pm
> +++ b/lib/Lintian/Storage/MLDBM.pm
> @@ -76,6 +76,7 @@ sub create {
> my $tempfile
> = Path::Tiny->tempfile(TEMPLATE => $stem . 'XXXXXXXX', UNLINK => 0);
> $self->tempfile($tempfile);
> + $self->{tempfile_path} = $tempfile->stringify;
>
> try {
> tie(
> @@ -100,8 +101,10 @@ sub DEMOLISH {
>
> untie %{$self->tied_hash};
>
> - $self->tempfile->remove
> - if defined $self->tempfile;
> + my $path = self->{tempfile_path};
> + if (-e $path) {
> + unlink $path;
> + }
>
> return;
> }
>
> And I could see the files getting removed. But this is already fixed in a
> different way, i.e. Path::Tiny handling
> the unlinks (with UNLINK => 1) so this patch is not required. Nevertheless,
> wanted to report the same so it adds
> the missing info.
>
> Best,
> Nilesh
