[PATCH] Segmentation fault without further info

[Robert Helling]

> On 15.03.2016, at 22:51, Robert Helling <helling at atdotde.de> wrote:
> 
> Hi,
> 
>> On 15.03.2016, at 15:33, Robert Helling <helling at atdotde.de <mailto:helling at atdotde.de>> wrote:
>> 
>> This turns out to be more complicated to fix. I have to look into how to make the live time long enough for the thread to complete. But in order to do this, I have to understand once more the slightly complicated call sequence that the struct picture is handed along.
>> 
> 
> <0001-When-handing-off-a-picture-to-a-worker-thread-copy-it-.txt>
> <0002-Fix-loading-images-from-URLs.txt>
> 
> I think patch 0001 fixes the issue by giving each thread its own copy of the struct picture. Please test!
> 
> Patch 0002 then addresses another problem with loading images from URLs.

There are two more things I am worried about:

As explained in the commit message of 0002, after loading the image, the DivePictureModel should be asked to reload the image. But that is in the desktop-models while the image downloader is in subsurface core and thus does not see the model. I am not sure how to address this. Tomas????

The other thing is the local cache file: There is a small chance of a race condition that I am not sure how to resolve: When we successfully downloaded an image from the network we store it in a local cache file. The filename of that cache file is actually the hash of the image. If we now happen to download the same image twice in different threads, we might overwrite the same file leading to a corrupted image file. If the resulting file does not properly parse as an image, no problem, when subsurface cannot read the file, it will download it again. But there is the theoretical possibility that we end up with a corrupted cached image.

I played a bit with different filenames, for example one could include msecs since the epoch as well (or some random number). That lowers the chance of corruption but on the other hand might lead to an inflation of stored image data in the cache directory. So I decided against it.

What do you guys think?

Best
Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160315/69cf93eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160315/69cf93eb/attachment.sig>