Linux: Random crashes after a few minutes (possible timemapping as the cause)

[RussNelson]

I'm trying to make a time-lapse out of five clips. I've only had success with just one clip. As soon as I put two clips in, I get a segmentation fault every time. I'm trying to make a test case that will always crash, but I can't get consistent crashing. Sometimes it crashes immediately after starting the export, and sometimes it crashes after 20 minutes. I ran it under gdb, provoked a crash and have appended the output.

[Switching to Thread 0x7fff512fd700 (LWP 25724)]
0x00007fffe37f2434 in std::tr1::__shared_ptr<juce::AudioSampleBuffer, (__gnu_cxx::_Lock_policy)2>::operator-> (this=0x20)
    at /usr/include/c++/4.8/tr1/shared_ptr.h:673
673     return _M_ptr;
(gdb) where
#0  0x00007fffe37f2434 in std::tr1::__shared_ptr<juce::AudioSampleBuffer, (__gnu_cxx::_Lock_policy)2>::operator-> (this=0x20)

at /usr/include/c++/4.8/tr1/shared_ptr.h:673

#1  0x00007fffe37ef4ac in openshot::Frame::GetAudioSamplesCount (this=0x0) at /home/nelson/libopenshot/src/Frame.cpp:406
#2  0x00007fffe37a01cf in openshot::Clip::get_time_mapped_frame (this=0x17e44b0, frame=std::tr1::shared_ptr (count 2, weak 0) 0x7fff300050e0,

frame_number=3) at /home/nelson/libopenshot/src/Clip.cpp:470

#3  0x00007fffe379f235 in openshot::Clip::GetFrame (this=0x17e44b0, requested_frame=3) at /home/nelson/libopenshot/src/Clip.cpp:277
#4  0x00007fffe380716a in openshot::Timeline::GetOrCreateFrame (this=0x191a7d0, clip=0x17e44b0, number=3)

at /home/nelson/libopenshot/src/Timeline.cpp:206

#5  0x00007fffe38073ca in openshot::Timeline::add_layer (this=0x191a7d0, new_frame=std::tr1::shared_ptr (count 2, weak 0) 0x7fff3000b030,

source_clip=0x17e44b0, clip_frame_number=3, timeline_frame_number=3, is_top_clip=true) at /home/nelson/libopenshot/src/Timeline.cpp:230

#6  0x00007fffe3813a86 in openshot::Timeline::GetFrame () at /home/nelson/libopenshot/src/Timeline.cpp:727
#7  0x00007fffe0f5134a in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#8  0x00007ffff7bc4182 in start_thread (arg=0x7fff512fd700) at pthread_create.c:312
#9  0x00007ffff78f147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

nelson@d2:~/openshot-qt$ 

[RussNelson]

Thanks, Markdown, for folding code. Well done.

[mlocati]

To write long blocks of code with markdown you shouldn't use the code notation, but something like this:

The content of your log.
This'll be formatted much better.

That'll be rendered as

The content of your log.
This'll be formatted much better.

[RussNelson]

I've tried running valgrind with it like this: valgrind --log-file=vg.log --leak-check=yes python3 src/launch.py however that hangs before it starts up Qt. The load average is still 1.0 and it's using 100% of CPU, however it prints nothing and hasn't started the GUI.

[jonoomph]

@RussNelson What OS are you running OpenShot on, and what version of OpenShot are you running. Also, please attach your log file (~/.openshot_qt/openshot_qt.log). Thanks!

With the newest version, there should be 2 new preferences: Debug (Verbose) and Debug (Port), and with those settings enabled, it should output much more debug info to the openshot_qt.log file. You can download the latest version from http://www.openshot.org/download/ and click "Other Installers", and choose the newest file. Thanks and good luck!

[RussNelson]

Running HEAD on Ubuntu 14.04 Turned on Verbose debugging. Loaded two video clips that caused a crash earlier. Inserted them into the stream and set Time->Fast->Forward-32X. Moved them both to the beginning of the stream. Without doing any more editing, I exported a video using the default settings. And it worked!! Which it never had before.

Then I loaded another five video clips, and it immediately segfaulted:
Segmentation fault (core dumped)
Leaving aside the issue that my computer has no core but only silicon memory .... nothing else more interesting was printed.

2016-04-08.zip

[RussNelson]

FWIW, I tried loading six video clips, set them all to Time->Fast->Forward->32X. It ran for about two hours and segfaulted then. Here are the log files from both crashes (you can discard the other one if you've already downloaded it).
2016-04-08-1.zip

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.