Re: [Pan-users] Pan core-dumps on startup

[Duncan]

Heinrich Müller posted on Mon, 15 Jul 2013 06:50:40 +0200 as excerpted:

> Am 14.07.2013 23:40, schrieb Duncan:
>> John Aldrich posted on Sun, 14 Jul 2013 16:30:05 -0400 as excerpted:
>>
>>> On Sun July 14 2013 7:53:33 PM Heinrich Müller wrote:
>>>> try deleting your .pan2 folder and try again.
>>>>
>>> Thanks, Heinrich. Apparently something got FUBARed in my config file
>>> and (in this case) renaming the folder removed the bad file from where
>>> it was expected and caused a new one to be created, resolving the
>>> problem! :D
>> There have been several reports of a corrupt tasks.nzb file triggering
>> crashes/coredumps.  Since you renamed the directory, if you haven't
>> deleted it yet, try restoring it and just moving/renaming the tasks.nzb
>> file.  If that's it, it'll save the rest of your config, as well as
>> confirm that file as a problem trigger once again.
>>
> Yes, but I encountered that bug several times now. It's kind of hard to
> fix, though, but feel free to file a bug ticket.

Well if you've encountered it several times, then you probably have 
enough test material...


Meanwhile, keeping in mind that I don't claim to be a programmer, while I 
imagine it /could/ be hard to properly recover from and continue using 
the remaining good content (if any) of a corrupt nzb, I had really 
THOUGHT (again, as a non-programmer, believe me I'm very happy for all 
the work you've done on pan as it's something I simply couldn't have 
done) that it SHOULD be fairly easy to go for a relatively minimal/dumb 
fix, that being... 

Using the stack trace from the core dump, find a place to put an 
assertion (I /believe/ that's the correct term) where it's obviously 
going wrong, and if that triggers, simply delete the existing nzb and 
start with a fresh/empty one (as if the user deleted it), possibly with a 
popup message explaining what happened as well, so people don't wonder 
why pan failed to restart the download they were doing when it normally 
does.

Basically, that would be the same result as the user deleting the file, 
only pan would be handling it automatically, eliminating the "pan won't 
start" issue.

If one wished to get fancy, the popup would offer a choice, to replace 
the file, or to terminate without touching it and let the user try to 
recover it if they could.  If one wished to get even fancier, that could 
be made an option, so people could choose one or the other and have pan 
behave accordingly every time.  However, the basic "just replace the 
corrupt file with a new task list without crashing" would be a vast 
improvement on the current situation, eliminating the "pan's crashing 
before it even starts and I don't know how to fix it" experience that 
people who aren't aware of the problem will have now, if they trigger it.

That "dumb" fix is what I had in mind.  Is it /that/ hard to trace and 
place an assertion (??) appropriately (maybe because the traces aren't 
consistent enough to properly place such a trap), or is the difficulty 
because you were thinking of something rather more complex than that, 
probably (as I said) trying to pick up the pieces and resume with the bit 
that wasn't corrupt.  I expect trying to pick up the pieces /would/ be 
far harder, but IMO it's letting the perfect be the enemy of the good, 
and thus isn't necessary.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman