Natron crashes when opening a certain file

[RaminRAY201]

• I'm using the latest version of Natron (not required but recommended)
• I've restarted Natron and the issue persists
• I've run Natron via the command line and the issue persists
• I've followed the contributing guidelines to the best of my understanding
• My issue is not on the issue tracker and is not a duplicate of a forum thread
• This bug is reproducible
• This issue is not a feature request or a pull request

Natron version

Natron 2.4

Operating system

Windows 10

System specs

RAM:8 GB
CPU: Intel Core i5-7200U 2.5GHz with turbo boost up to 3.1GHz
GPU: Nvidia GeForce 940MX 4GB

Did you install Natron using the official installer?

• Yes, I used the official installer
• No, I installed from a binary archive
• No, I compiled Natron from sources
• No, I installed Natron via another method

If you installed to a custom '(non-default)' location please include it here':'

No response

What were you trying to do?

I have a save that is a bit heavy, but it used to open normally, then one time I put the timeline on a certain frame, which crashed the program, then after opening it worked for a bit then crashed after choosing another frame, but since I saved just before moving to that other frame, now it crashes as soon as I open it, because apparently that first frame started crashing again, and I can't access the file now,

Please help me fix this, this is a very important file to me and I really don't want to redo all of it

What did you expect to happen? What happened instead?

I expected to open the file, instead it crashes, I have tried this on other computers and all of them have the same result,

I can't find a crash report nor a crash ID

Step-by-step reproduction instructions

1. Start Natron
2. Open the save file provided

https://drive.google.com/file/d/1LZrwKZhYj4V_4aw2p5zvQjw1Fo9uyp2q/view?usp=sharing

Additional details

No response

[rodlie]

Hi,

I'm able to replicate the issue on macOS. It seems to be an issue with the tracker, I don't have time to look at this now, but maybe later this weekend.

I did a minor modification to the project file to get it to load (it will probably crash if you connect the viewer, so close the tracker panel before doing anything):
portifolio 7-1.ntp.zip

[devernay]

@rodlie got any time to look at this? Should it be a blocker for 2.4.1, or can we release 2.4.1 now? any other fixes you want to add to 2.4.1?

[rodlie]

Forgot about it, sorry. Will take a look this weekend.

any other fixes you want to add to 2.4.1?

I noticed that on Windows Natron is very slow loading/saving large projects, we are talking minutes vs. Mac/Linux that takes seconds, I was planning to try to find a fix (or at least the reason).

[devernay]

Is that a regression from previous versions? If not, it can wait for next minor release Le jeu. 16 sept. 2021 à 23:45, Ole-André ***@***.***> a écrit :

…

Forgot about it, sorry. Will take a look this weekend. any other fixes you want to add to 2.4.1? I noticed that on Windows Natron is very slow loading/saving large projects, we are talking minutes vs. Mac/Linux that takes seconds, I was planning to try to find a fix (or at least the reason). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#660 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA42MF4XVJG4G3Z5UXNKNILUCLPXNANCNFSM5CEHL2MA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rodlie]

Not a regression, it's been like this for a while (always?). Anyway, will try to find a solution, but it's not a blocker for 2.4.1.

[devernay]

@rodlie were you able to investigate about this crash? (not the long file loading issue)

[rodlie]

Tested on macOS yesterday:

Connecting the viewer to the rectangle in the project file (see above) will crash when using Misc.ofx release build, but not against a debug build of Misc.ofx, then everything is fine.

1 (anonymous namespace)::RectangleProcessor<float, 4, 1>::multiThreadProcessImages(OfxRectI const&, OfxPointD const&) (x86_64) /Applications/Natron.app/Contents/Plugins/OFX/Natron/Misc.ofx.bundle/Contents/MacOS/Misc.ofx 0x1222be316

2 OFX::ImageProcessor::multiThreadFunction(unsigned int, unsigned int) (x86_64) /Applications/Natron.app/Contents/Plugins/OFX/Natron/Misc.ofx.bundle/Contents/MacOS/Misc.ofx 0x121924cee

3 Natron::(anonymous namespace)::threadFunctionWrapper(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *) OfxHost.cpp 1242 0x101126437

4 int boost::_bi::list5<boost::_bi::value<void ( *)(unsigned int, unsigned int, void *)>, boost::arg<1>, boost::_bi::value<unsigned int>, boost::_bi::value<QThread *>, boost::_bi::value<void *>>::operator()<int, int ( *)(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *), boost::_bi::rrlist1<unsigned int const&>>(boost::_bi::type<int>, int ( *&)(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *), boost::_bi::rrlist1<unsigned int const&>&, long) bind.hpp 500 0x101130d16

5 int boost::_bi::bind_t<int, int ( *)(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *), boost::_bi::list5<boost::_bi::value<void ( *)(unsigned int, unsigned int, void *)>, boost::arg<1>, boost::_bi::value<unsigned int>, boost::_bi::value<QThread *>, boost::_bi::value<void *>>>::operator()<unsigned int const&>(unsigned int const&&&) bind.hpp 1285 0x101130c3d

6 QtConcurrent::MappedEachKernel<std::__wrap_iter<unsigned int const *>, boost::_bi::bind_t<int, int ( *)(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *), boost::_bi::list5<boost::_bi::value<void ( *)(unsigned int, unsigned int, void *)>, boost::arg<1>, boost::_bi::value<unsigned int>, boost::_bi::value<QThread *>, boost::_bi::value<void *>>>>::runIteration(std::__wrap_iter<unsigned int const *>, int, int *) qtconcurrentmapkernel.h 180 0x10112fe56

7 QtConcurrent::MappedEachKernel<std::__wrap_iter<unsigned int const *>, boost::_bi::bind_t<int, int ( *)(void ( *)(unsigned int, unsigned int, void *), unsigned int, unsigned int, QThread *, void *), boost::_bi::list5<boost::_bi::value<void ( *)(unsigned int, unsigned int, void *)>, boost::arg<1>, boost::_bi::value<unsigned int>, boost::_bi::value<QThread *>, boost::_bi::value<void *>>>>::runIterations(std::__wrap_iter<unsigned int const *>, int, int, int *) qtconcurrentmapkernel.h 190 0x10112ff80

8 QtConcurrent::IterateKernel<std::__wrap_iter<unsigned int const *>, int>::forThreadFunction() qtconcurrentiteratekernel.h 263 0x101131101

9 QtConcurrent::IterateKernel<std::__wrap_iter<unsigned int const *>, int>::threadFunction() qtconcurrentiteratekernel.h 225 0x101130017

10 QtConcurrent::ThreadEngineBase::run() (x86_64) /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore 0x106191419

11 QThreadPoolThread::run() (x86_64) /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore 0x106192390

12 QThreadPrivate::start(void *) (x86_64) /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore 0x10619ff18

13 _pthread_body (x86_64) /usr/lib/system/libsystem_pthread.dylib 0x7fff6399d661

14 _pthread_start (x86_64) /usr/lib/system/libsystem_pthread.dylib 0x7fff6399d50d

15 thread_start

[devernay]

This issue came from the Mirror plugin. For some reason, with optimization enabled, sometimes the multithread suite asks to render parts that are outside of src bounds, so that srcPix = 0.

To debug this, add -g to the CXXFLAGS in Makefile.master for the plugins.