ART feature requests and discussion

[agriggio (Alberto)]

Hi, and thanks for testing!

@a286

I’ve tested it and I couldn’t get a crash (in multiple tabs mode)

good!

@a286

The new zooming behavior is not very convenient though

one thing at a time… besides, I’d argue this is more convenient than getting segfaults all the time

[agriggio (Alberto)]

@agriggio

one thing at a time…

Here’s a new version:

https://drive.google.com/file/d/19yM41CD7vvvuOOMbXcs3x6_sdgrw8ntO/view?usp=sharing

is it better now?

[a286 (Alexander)]

@agriggio

Here’s a new version

Unfortunately, it crashed after 15 mins of testing (in mutliple tabs mode). It crashed when I used double click to reset zoom (to fit image to screen).

[agriggio (Alberto)]

Thanks for testing! Can you elaborate a bit more on what you did? Was art idle and you simply double clicked? Or was it already updating the GUI?

[a286 (Alexander)]

I don’t remember what exactly happened, most likely I was moving (panning?) the image right before double clicking, but the thing is - the double click logic itself always re-renders image on the first click, and then the second click changes zoom/pan. So I think that at the moment of zooming image already was being re-rendered.

[gaaned92]

@agriggio
I don’t know if it is the same bug as for @a286
A user on the French forum submitted an ARP that systematically crashes ART when zooming.
For license reason, I used another photo from @Wocket play_raw

DSCF0083.RAF (32.2 MB)
DSCF0083.RAF.arp (25.0 KB)

crashes on W10 with ART build from your above post.

[agriggio (Alberto)]

Thanks. I tried with the latest master on my win7 VM and I get no crash

I really don’t know what to do about these (apparently) windows-specific issues. I don’t normally use windows, I’m not familiar with it, and I don’t even have a copy of win10… I try to do my best but without being able to reproduce the bugs myself fixing them will be very hard, sorry

[bipster]

You can download a copy of Windows 10 from the Microsoft site and install it without activating it. The only limitation is that you’ll not be able to personalize it.

[gaaned92]

The problem is that even if I use a debug build, I cannot get a backtrace.
I will try to identify the minimum set of functions inducing the crash.

[a286 (Alexander)]

@gaaned92

The problem is that even if I use a debug build, I cannot get a backtrace.

This might indicate that stack is corrupted (which gdb suggests as well) and so instruction address is invalid - thus no meaningful backtrace. I would assume some variable or buffer on the stack gets written out of its bound.
Another way to isolate the issue is to find exact ART version when it was introduced. It’s quite easy to install ART and to reproduce the issue, so the only question is the availability of the binaries of previous versions. I could test them all and find the exact version when it was introduced (using binary search).

[agriggio (Alberto)]

@a286

Another way to isolate the issue is to find exact ART version when it was introduced. It’s quite easy to install ART and to reproduce the issue, so the only question is the availability of the binaries of previous versions. I could test them all and find the exact version when it was introduced (using binary search).

The previous binaries are not available anymore, but an alternative is to set up a build env on windows and use git bisect to find the culprit. FWIW I think this has to do with race conditions rather than buffer overflows, but it’s just a feeling so take it with a lot of salt

Anyway, I will release 1.9 soon even if this doesn’t get resolved, as it’s not a recent regression.

[gaaned92]

I can try to bisect. There should not be difficulty to rebuild old versions.
The problem is to have an idea of the approximate date of the last good build.

[a286 (Alexander)]

@gaaned92

The problem is to have an idea of the approximate date of the last good build.

ART_master_1.5.4-34-g7a12db8bf doesn’t have this issue for sure, I’ve just checked it.

[gaaned92]

Thanks @a286

@a286

ART_master_1.5.4-34-g7a12db8bf doesn’t have this issue for sure, I’ve just checked it.

I rebuilt this version. agreed no issue.

I have still to make some simplification in my build procedure to speed up the bisect process.
I am going to work in the garden now . So I will start in end of afternoon.

[agriggio (Alberto)]

Update:

@gaaned92

I don’t know if it is the same bug as for @a286

this is not the same bug. This is indeed a buffer overflow that happens during CA correction with lensfun. I’m working on a fix

[gaaned92]

But I get no crash for this bug with ART_master_1.5.4-34-g7a12db8bf.

but I will test with photo from @a286

[agriggio (Alberto)]

@gaaned92

But I get no crash for this bug with ART_master_1.5.4-34-g7a12db8bf

Means nothing. Maybe the buffer is allocated differently and reading past it doesn’t trigger the segfault. I also couldn’t reproduce on windows… Anyway, it should be fixed now

[gaaned92]

Yes fixed thank you, @agriggio

Edit :Now I can neither crash ART with @a286 procedure and DSC_4058.NEF

@a286

• Open raw file, set neutral profile, close file, close ART
• Start ART again, open raw file (with double click) and start rapidly zooming right away (maybe even a fraction of second before the photo is completely loaded and displayed).

[a286 (Alexander)]

@gaaned92

Now I can neither crash ART with @a286 procedure and DSC_4058.NEF

I’ve just checked this version:
ART_master_1.8.4-31-g404ab87ed_W64_Skylake_210520.7z

And it crashes the same way as before.

[agriggio (Alberto)]

@a286

I’ve just checked this version:
ART_master_1.8.4-31-g404ab87ed_W64_Skylake_210520.7z

And it crashes the same way as before.

I’m afraid you’d need to try to bisect this yourself if you want to see some progress, as I still can’t reproduce (I even tried on a windows 10 vm, still no luck…)