LiVES crashes on startup
LiVES is a Video Editing System. It is designed to be simple to use, y
Brought to you by:
gfinch
Menu
▾
▴
#205 LiVES crashes on startup
LiVES crashes reliably on startup on Ubuntu 15.04 (Ubuntu Studio) running the xfce 4.12 window manager.
The following is output from running in debug mode:
spl> lives -debug
LiVES 2.4.0
Copyright 2002-2015 Gabriel Finch (salsaman@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.
LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found in compound effect image_stabilizer, line 4
LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found in compound effect motion_analyser, line 4
**
Gtk:ERROR:/build/buildd/gtk+3.0-3.14.13/./gtk/gtkprogressbar.c:606:tick_cb: assertion failed: (priv->pulse2 > priv->pulse1)
Unfortunately LiVES crashed.
Please report this bug at http://sourceforge.net/tracker/?group_id=64341&atid=507139
Thanks. Recovery should be possible if you restart LiVES.
When reporting crashes, please include details of your operating system, distribution, and the LiVES version (2.4.0)
and any information shown below:
No further information is produced.
Is it possible for you to install gdb ? If you do so, then you can type "bt" when LiVES crashes and it should show the line of code where the crash occurs. Without this it is impossible to determine the cause of the crash.
Oddly enough, if I run
it starts up just fine and now after it's run the first time, it now
starts up just fine.
As far as I know, nothing significant has changed on my system since I
filed the bug report.
How did you install LiVES ? Is it included by default in Ubuntu studio or did you compile it yourself or was it from another source ?
It is not a default package in Ubuntu Studio but is recommended.
I installed it from the package using `synaptic', which tells me it is
version 2.4.0~ds0-3ubuntu0.
As I mentioned in my previous reply, it now seems to be running okay
from the command line and from the menus. Why running under `gdb'
made it work is a puzzle to me -- perhaps there's some sort of subtle
timing issue? But that's just a wild guess.
Just to clarify, are you saying that it now works even without running it via gdb ?
Also, when you ran LiVES for the first time, did it go through the installtion procedure (asking you to specify the working directory, etc) ?
Yes.
When it crashed, no, it did not.
Only when I ran it with `gdb' did it run the installation procedure.
Just as an experiment, I deleted the files and directory created and
it crashed again, so the failure is repeatable in that sense.
So, let's try it under `gdb' again and see what happens:
So now I'm really scratching my head.
BTW, for what it's worth, the splash is reading "Loading realtime
effect plugins..." and the progress bar is a little more than halfway
filled.
Thanks. That is useful to know, that means it is in the initial installation code. Checking now.
An observation which may or may not be useful:
Thinking along your same lines, I copied the .lives file, and
.lives-dir and .livestmp directories (I made `livestmp' a "hidden"
file) from another machine one which it was working (running Linux
Mint 17.1 'Rebecca' with the Mate Window Manager).
On startup, LiVES complained that it could not find the plugins. It
turns out that instead of them being installed in
/usr/lib/lives/...', they are installed in/usr/lib/x86_64-linux-gnu/lives/...' on Ubuntu Studio.I have no idea whether this confuses the LiVES startup but I thought
I'd mention it on the off chance it matters.
Regards.
OK, confirming it doesn't crash for me. It may be something to do with the gtk+ version. Here I am using gtk+ 3.12
I'm running gtk+ 3.14.13-0ubuntu1, according to `synaptic'.
Well, if the plugins are installed in a non standard location then it should have been configured with configure --libdir=lib/x86_64-linux-gnu
You could try making a symlink from /usr/lib/x86_64-linux-gnu to /usr/lib/lives, or alternately once the .lives file has been created you need to edit it and set the value of <lib_dir> there.</lib_dir>
I still feel this is most likely a gtk+ version issue. If you are able to compile the code yourself, you could try changing the code at the end of the function end_threaded_dialog() in dialogs.c
the code may be altered from:
lives_widget_context_update();
}
to:
if (mainw->is_ready)
lives_widget_context_update();
}
Last edit: Salsaman 2015-06-30
I just edited the `.lives' file.
I tried building with the source found at
and it threw a compile error:
I grepped the source and don't find where that symbol is defined.
Thanks, that should be fixed now if want to do an svn update.
No joy:
Am I svn'ing from the right place?
configure.ac:935: error: required file 'lives-plugins/plugins/decoders/audio/Makefile.in' not found
OK this one was my fault, I left some test code in. Please update from svn.
As regards the other files you are missing a build package, try
sudo apt-get install autopoint
Done.
Okay, done also.
New failure:
Looks like I'm missing a header file.
OK, it should all be fixed in svn now.
Um, no. . .
Tried a couple of different ways, by checkout and by downloading the
snapshot, just in case there was some difference.
I appreciate your efforts here and Not to be critical but are you
testing that this compiles before you commit?
Best regards.
Yes, I did test it, unfortunately the latter error you got was not triggered by my version of libav. It was a simple one line fix in svn - my apologies for the inconvenience and I hope the compilation will go smoothly now.
Many thanks for your help in troubleshooting this issue.
Last edit: Salsaman 2015-07-01
More missing symbols:
Hi, I am not able to check in to svn right now but I am sending 3 replacement files:
libweed/weed-compat.h, lives-plugins/plugins/decoders/mkv_decoder.h and lives-plugins/plugins/decoders/mpegts_decoder.h
this should add the missing symbols on your system.
Last edit: Salsaman 2015-07-01
Still losing:
It just occurred to me that this is a library build problem and somewhat moot to the actual bug.
Realizing that, I cleared out the config files and directories LiVES creates on startup and just went ahead and ran the binary in the src directory.
It ran fine (though it complained about missing plugins, which, as you suggested, could be corrected with a symbolic link).
I think we can declare the original bug to be fixed, at least provisionally.
If you wish to carry on with getting the compile of the libraries and plugins to run on my machine, I'm game for it but that's up to you.
Cheers
file2
file 3