sobotka / olive

NLE video editor
GNU General Public License v3.0
2 stars 1 forks source link

[CRASH] Switching sequences while the cache is being built #140

Closed elsandosgrande closed 4 years ago

elsandosgrande commented 4 years ago

Platform Ubuntu Focal Fossa, latest mainline kernel version Various compilers and compiler flags used, marked in the backtrace text files

Summary If one switches to another sequence whilst the cache is being built, a segmentation fault shall be incurred. For further reading: https://canary.discordapp.com/channels/549629829730009089/549981324996378644/742089616982671490

Additional Information / Output The final lines of the terminal output are generally as follows:

***
[WARNING] QObject::connect: Cannot queue arguments of type 'NodeEdgePtr'
(Make sure 'NodeEdgePtr' is registered using qRegisterMetaType().) ((null):0)
[WARNING] QObject::connect: Cannot queue arguments of type 'NodeEdgePtr'
(Make sure 'NodeEdgePtr' is registered using qRegisterMetaType().) ((null):0)
[WARNING] QObject::connect: Cannot queue arguments of type 'NodeEdgePtr'
(Make sure 'NodeEdgePtr' is registered using qRegisterMetaType().) ((null):0)
[DEBUG] No arenas, creating new... ((null):0)
[DEBUG] All arenas are full, creating new... ((null):0)
[DEBUG] Removing an empty arena ((null):0)
Segmentation fault (core dumped)

Switching to a different sequence right after the project opens: backtrace 99b826a one.txt backtrace 99b826a two.txt backtrace 99b826a three.txt

Switching to a different sequence right after seeking ahead and then playing the current one: backtrace 99b826a five.txt

Also, if the cache is not being built at the moment, I can switch to another sequence and then switch between those two, even while the other one is caching: https://canary.discordapp.com/channels/549629829730009089/549981324996378644/744327033206603816

The strange commit hash in the recording above is due to me using my repository fork as the source code directory, which requires a commit for the pulling (merging) of upstream code. You can see that the hash is in my fork.

@Simran-B Since you are compiling with Clang as well, could you double-check the LLDB output with your builds? LLDB seems to descend into the Qt headers in its frames and when listing source code, whereas GDB does not seem to, at least on the thread which it drops me off on when I get a segmentation fault. I've also noticed that LLDB can catch segmentation faults across multiple threads, particularly if I try to switch between sequences immediately after pausing the playback of the timeline.

itsmattkc commented 4 years ago

This should be fixed as of b3e30b8dafb140d483e7456ecf82717afc6f6f14, let me know if it is

elsandosgrande commented 4 years ago

So far, it appears to be.