GTK_ICON_SIZE_INVALID warning on launch

Bug #519726 reported by slimIT
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenShot Video Editor
Fix Released
Low
Unassigned

Bug Description

When i try to open openshot i have this problem :

Added /usr/share/openshot to system path
/usr/share/themes/Human/gtk-2.0/gtkrc:85: Murrine configuration option "gradients" is no longer supported and will be ignored.
--------------------------------
   OpenShot (version 1.0.0)
--------------------------------
/usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  return gtk.glade.XML(self.glade_path, root, domain)
A new frmMain has been created
Segmentation fault

Tags: patch
Revision history for this message
Ian Clark (blacktuzi) wrote :

I have the same issue. Here's my terminal output:
user@user-desktop:~$ openshot
Added /usr/share/openshot to system path
--------------------------------
   OpenShot (version 1.0.0)
--------------------------------
/usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  return gtk.glade.XML(self.glade_path, root, domain)
A new frmMain has been created
Traceback (most recent call last):
  File "/usr/bin/openshot", line 50, in <module>
    main()
  File "/usr/share/openshot/openshot.py", line 57, in main
    form1 = MainGTK.frmMain(project=current_project, version=info.SETUP['version'])
  File "/usr/share/openshot/windows/MainGTK.py", line 161, in __init__
    self.settings.load_settings_from_xml()
  File "/usr/share/openshot/windows/preferences.py", line 208, in load_settings_from_xml
    xmldoc = xml.parse(settings_path)
  File "/usr/lib/python2.6/xml/dom/minidom.py", line 1918, in parse
    return expatbuilder.parse(file)
  File "/usr/lib/python2.6/xml/dom/expatbuilder.py", line 924, in parse
    result = builder.parseFile(fp)
  File "/usr/lib/python2.6/xml/dom/expatbuilder.py", line 211, in parseFile
    parser.Parse("", True)
xml.parsers.expat.ExpatError: no element found: line 1, column 0

Let me add that I have a weird computer that was assembled privately in China. I have system clock issues when the power cuts out or after the computer is unplugged. After a power outage, I restarted the computer and could barely boot into Ubuntu. I had to reset a bios setting (boot order) and after finally getting into Karmic I had to reset my clock. It's possible that the above bug is related to some missing or corrupted configuration file. My other programs work and start just fine. I've already tried the fixes here https://bugs.launchpad.net/openshot/+bug/480894 (purging openshot and mlt, plus the files listed there, then reinstalling).

I'm running Ubuntu Karmic 9.10 and OpenShot was installed through the PPA.

Revision history for this message
Andy Finch (fincha) wrote :

@Ian Clark:

Your issue looks different to the original bug report. The problem you are having seems to be an issue reading the xml settings file. You could try removing the file settings.xml, which is in a hidden folder in your home, i.e. /home/.openshot/settings.xml.

Openshot will recreate the file if it is not there. There is some improved error trapping in the next version of Openshot which would hopefully work through this error.

(The error /usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed is normal and can be ignored)

Revision history for this message
Ian Clark (blacktuzi) wrote :

@Andy Finch:

I deleted the whole folder there, openshot created a new one, and Openshot indeed opens now. The problem is now that it crashes my computer. I start by opening a previous openshot file which loads OK. then I try to do something, like slide along the time line, and not only does Openshot crash, but the whole computer logs out. I get back to the Karmic login screen, re-enter my password, and nothing is there. Sorry to be taking up so much of your time. But,

What logs should I be looking at? Where might there be a clue as to what is going on?

Revision history for this message
brendon (brendon-schu) wrote :

I concur with Andy Finch's comment. You seem to have a file missing which is needed for configuration to run the program, look at the last line of the output to catch a hint:

 File "/usr/lib/python2.6/xml/dom/expatbuilder.py", line 211, in parseFile
    parser.Parse("", True)
xml.parsers.expat.ExpatError: no element found: line 1, column 0

Here it is very clear that Python is trying to build a "dom" object out of an XML file. The very last line tells you: no element found. And obviously if column 0 and line 1 (the very first character of the file) doesn't exist, thus there is no file where there should be a file.

Replace any files you deleted, download a full package of this application to find the missing files, and/or reinstall.

Revision history for this message
Ian Clark (blacktuzi) wrote :

I've purged and reinstalled Openshot. Now the issue is that after starting Openshot, my system logs out (!). Just before log-out, I was able to copy this out of terminal:

user@user-desktop:~$ openshot
Added /usr/share/openshot to system path
--------------------------------
   OpenShot (version 1.0.0)
--------------------------------
/usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  return gtk.glade.XML(self.glade_path, root, domain)
A new frmMain has been created

Is there any more info I need to post here?

Revision history for this message
ptf (paul-flinders) wrote :

There may be two bugs here.

I get the assertion warning as above but openshot works just fine - no segfault, no DOM problems.

The assertion is due to the glade XML for the main window specifying the toolbar icon size using the GtkIconSize enum values as string constants, not numeric constants.

That is the icon size is specified as e.g. GTK_ICON_SIZE_LARGE_TOOLBAR, rather than the numeric value 3

I'm not sure if this is a libglade issue (I have libglade2-2.6.4-3 on a fedora 12 x86_64 system) but the following patch fixes the warning for me.

Note that this is just for the warning described in the title of the bug report, I'm not sure that it will have a bearing on the segfault that the original reporter experienced or the problem that Ian is having

Revision history for this message
Jonathan Thomas (jonoomph) wrote :

Thanks for the patch. I have committed it to the trunk.

summary: - Openshot won't start : GTK_ICON_SIZE_INVALID
+ GTK_ICON_SIZE_INVALID warning on launch
Changed in openshot:
importance: Undecided → Low
milestone: none → 1.1.0
status: New → Fix Committed
Revision history for this message
slimIT (slim-it) wrote :

what should i do with that patch file ? How to use it ?

Revision history for this message
Ian Clark (blacktuzi) wrote :

Can this fix be provided to us who are using the PPA? I figured since installing that way that fixes might come through that channel. I would still really like to get that video work done that I was doing before this bug popped up. Don't know how to install or use a patch file. Thanks!

Revision history for this message
Andy Finch (fincha) wrote :

It will be provided in the PPA soon, but note that this patch only removes the warning 'set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed' - it is unlikely to fix the segmentation fault.

Revision history for this message
Ian Clark (blacktuzi) wrote :

@Andy Finch: If the patch removes the warning, but the problem is still there, isn't that a bad idea? At least before we'd have an error message to give us a hint about what is going on.

I think the root issues of this bug are:

1. OpenShot gets borked by a system clock change
2. OpenShot is easily installed but does not uninstall cleanly, making a simple reinstall useless as a fix.

Revision history for this message
Jonathan Thomas (jonoomph) wrote :

@Ian,
Have you tried deleting the .openshot folder (located in your home folder)? Once you delete that folder, launch OpenShot again. Good luck.

NOTE: This folder is created at runtime, and is not cleaned up during installation or removal of OpenShot.

Thanks,
-Jonathan

Revision history for this message
Ian Clark (blacktuzi) wrote :

@Jonathan
Yes I've done this, and each time I test opening it I make sure to go and delete that folder before starting it. Currently I get:

desktop:~$ openshot
Added /usr/share/openshot to system path
--------------------------------
   OpenShot (version 1.0.0)
--------------------------------
/usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  return gtk.glade.XML(self.glade_path, root, domain)
A new frmMain has been created
on_frmMain

then the program crashes my computer. Thanks for responding
-Ian

Revision history for this message
Ian Clark (blacktuzi) wrote :

I think the cleanup issue goes beyond the .openshot folder.
1. After my system clock changed, all my programs were normal except for OpenShot.
2. Reinstallation has been useless. Any installation after the first is affected by the first, because complete removal is not working.

Revision history for this message
ptf (paul-flinders) wrote :

> If the patch removes the warning, but the problem is still there, isn't that a bad idea?

It might be if the warning were _anything_ to do with the subsequent segmentation fault, but I very much doubt that it is.

The patch I supplied fixes a real problem - just a rather trivial one and not the one which I think is causing the other problems.

As I said there seems to be more than one problem here:

1) The GTK_ICON_SIZE_INVALID warning - trivial, easily fixed and probably nothing to do with the others.

2) The segfault reported by slimIT - we haven't had any more information on that so it's difficult to make any progress.

3) Ian's problems which seem to be unrelated to 2).

In turn Ian seems to have had two distinct issues - the preferences file warnings which _do_ seem to have been fixed by removing .openshot/re-installing openshot and his computer crashing/logging him out.

Ian - it sounds as though the X server is crashing when you get "logged out" - see if you can find the X server log file (I don't run Ubuntu so don't know exactly where it will be but look in /var/log for Xorg.0.log or Xorg.0.log.old and see if there's any hint in those files).

Having said that it's a bit odd that you had time to copy anything from the terminal window - can you describe what happens in any more detail?

Have you confirmed that MLT can play videos on your system. If it is an X server crash it's is quite likely to be related to use of XV by SDL.

Also you admit that your hardware is a bit strange - can you give us any more details on the video card, motherboard, processor, amount of RAM etc.

The clock thing sounds a bit strange as well - is the BIOS battery OK? Are there any motherboard links (eg clock reset) which are set incorrectly?

I don't think there's anything in openshot which would get especially upset by a system clock change.

Revision history for this message
Olivier Girard (eolinwen) wrote :

@Ian
Like ptf saids we must have more explanations for resolving this bug if it a bug clean at Openshot or not (personnaly i don't think ).
You have a faq now to know if it's mlt, ffmeg, or another thing that could give us a track about this problem. It will help us a bit.
Another thing, could you post the result of the terminal. And better could you do that for help us ? If not, don't worry, it's just better for us because a segment fault is very difficult to resolve.
https://answers.launchpad.net/openshot/+faq/983
http://openshotusers.com/forum/viewtopic.php?f=12&t=180&p=647&hilit=gdb#p647
Thanks for all.

Revision history for this message
Ian Clark (blacktuzi) wrote :

1. Melt is running fine, I can play movies with it.
2. I checked through all dependencies here http://openshotusers.com/forum/viewtopic.php?f=18&t=10
3. X server may be crashing and causing the log out. The log file is attached.
4. My hardware is an ATI Radeon 9550 with maximuum ram (specifics attached)
5. BIOS battery was just changed. What are motherboard links like clock reset - where do I find them and how do I check them? Should I go through BIOS and check these things? My BIOS is a bit messed up. It does not remember boot order and I have to change that in order just to start the computer, even though the battery is new. I've never updated BIOS and I hear that is difficult through Ubuntu. Flashrom's support page is down, and I don't know if it would support my BIOS version. Other than that, however, the entire system functions fine - except for OpenShot.
6. There was a power surge and the power went out, which caused this messed up BIOS. After I was finally able to get into my Ubuntu system, all programs were fine except for OpenShot. I had just been using OpenShot just fine when the surge happened. So something with BIOS/clock or something like that affected it - at least this is what the experience is telling me.

Output of gdb:
"(gdb) run openshot.py
Starting program: /usr/bin/python openshot.py
[Thread debugging using libthread_db enabled]
/usr/bin/python: can't open file 'openshot.py': [Errno 2] No such file or directory
Program exited with code 02."

Terminal output of openshot before forced X restart:
"user-desktop:~$ openshot
Added /usr/share/openshot to system path
--------------------------------
   OpenShot (version 1.0.0)
--------------------------------
/usr/share/openshot/windows/SimpleGladeApp.py:340: GtkWarning: gtk_toolbar_set_icon_size: assertion `icon_size != GTK_ICON_SIZE_INVALID' failed
  return gtk.glade.XML(self.glade_path, root, domain)
A new frmMain has been created
on_frmMain"
(I can either let it restart X at this point, or I can exit OpenShot within about 5 seconds. To record terminal output I did not let it restart X, but this output is the same as if I had let it).

Revision history for this message
Ian Clark (blacktuzi) wrote :

I posted gdb output before http://openshotusers.com/forum/viewtopic.php?f=12&t=180&p=853#p744
But no one responded to it. Is it insignificant that the file .openshot.py does not exist in /usr/bin/python? Could I find a way to create this file there? Thanks!

Revision history for this message
ptf (paul-flinders) wrote :

OK, just to deal quickly with a couple of things before I go to work

Do you ever see the main openshot window open? It really sounds as though the X server is crashing for some reason.

Have you changed the BIOS battery since the power outage that you mention? It sounds as though your BIOS settings are corrupted. It's possible that the non-volatile RAM that the BIOS keeps its settings in has been damaged but I hope not as you'd have to replace the motherboard.

Look in the motherboard manual for a jumper labelled clock reset or NVRAM reset. Normally you need to push a header over two pins on the motherboard for a few seconds to disconnect the battery and clear the NVRAM completely. Usually it's a three pin header where "normal" operation has two of the pins linked (e.g 1&2) and you then move the header to the other pair (eg 2&3) to clear the NVRAM.

running openshot in gdb:

gdb will look for openshot.py in the current directory - you'll have openshot.py in the development tree but if you just have the installed version of openshot you won't have this file. However you should still be able to run openshot in gdb

type the command "which openshot" - note the result
run gdb
$ gdb /usr/bin/python
in gdb start python with the path to the openshot script
(gdb) run <path-to-openshot-found-earlier>

You mention that openshot was working OK before the power outage/scrambled system. Did you do anything to change the openshot set-up after the power problem but before you noticed openshot crashing.

I must admit that coming to the conclusion that a previously working program, which no-longer works after a power outage that seriously scrambled your computer, is failing due to bugs in the program is not how I'd interpret things. Given that sequence I'd assume that I still had hardware problems of some sort, even if the rest of the system appeared OK.

Revision history for this message
ptf (paul-flinders) wrote :

Just to expand a bit further...

Obviously a power outage could leave corrupt config files, execuatables or libraries which should not cause an application to crash (openshot does have some way to go in that respect) but we now seem to have ruled that out for Ian as far as I can see.

Ian - I still think your problems could be hardware related, or related to some sort of file coruption (either in openshot or one it its many dependencies).

I'd suggest:

Trying to get to the bottom of the BIOS problems.

If you can't fix those it might be worth trying to at least borrow a replacement motherboard.

Consider re-installing the operating system from scratch.

Run memtest and look at the output from smartctl to try to eliminate failing memory or hard disk

From you description I'm still sure that the X server is crashing. To try to look at this switch to a text console, log in then use "startx -- :1" to run X. When X crashes you should just be left back at the console command line and you'll be able to see the X server output.

You said that you'd attached the X log file - I couldn't see it with you post.

Revision history for this message
Ian Clark (blacktuzi) wrote :

Ok here's my gdb output now:
(gdb) run /usr/bin/openshot
Starting program: /usr/bin/openshot
No executable file specified.
Use the "file" or "exec-file" command.

Revision history for this message
Ian Clark (blacktuzi) wrote :

Specifics of my system attached.

Revision history for this message
Olivier Girard (eolinwen) wrote :

The explanaitons of ptf are very good and better than i can provide.
Another thing with gdb
(gdb) run openshot.py
And what give you too this command :
echo $PYTHONPATH
Thanks

Revision history for this message
ptf (paul-flinders) wrote :

Ian

gdb:

You need to run gdb with
$gdb /usr/bin/python
Then
(gdb) run /usr/bin/openshot

The error message you got from gdb means that you didn't give it an executable. I admit that the error message could be clearer!

I'm not too sure that gdb will help too much at the moment though.

Hardware - Can't tell much from what you posted. Guessing slightly - Prescott P4 with 1G of RAM in a machine 5 or six years old?

Nothing obviously wrong. Serious video editing might be a bit slow though. Have you run memtest86 and looked at some smartctl output?

The X server log doesn't have anything obvious but that's likely to be because it's either from your "current" copy of the xserver which hasn't crashed because you're sitting in front of it or if it was from the crashed copy but it didn't write anything useful before it died.

I'd still like you to run X from a console window. I'm going to suggest doing that slightly differently to my earlier post as acceleration may only work properly for the "first" copy of X. Can you do the following?

log in
su to root (or use sudo) to run the command "telinit 3"

Your X session will disappear (don't worry!) and you should be looking at a console login prompt (might need to hit return once or twice).

Log in, then type

startx -- :0

You should now have a graphical desk top.

Run openshot - if it crashes the X server you should now be looking back at the console prompt with the last few lines of output from the server - post that plus the logfile.

Finally run the command "telinit 5" to get back to a graphical login.

Revision history for this message
Olivier Girard (eolinwen) wrote :

I was having a P4 Northwood 2.4 gz with 500 Mo of Memory and Openshot was running fine with. It was in 2002. Prescott was the next generation (so 6-7 years) . For the mpeg2 and the Xvid, it's okay but for MP4 (and Avchd) forgotten. It's just impossible with.
@Pft Very good advice.

moimael (moimael)
Changed in openshot:
status: Fix Committed → Fix Released
tags: added: patch
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.