WinFF crashes in OpenSUSE 11.2

[Willem]

Hello.
WinFF 1.1 (from Packman repository) fails to import video files.It crashes immediately when clicking the Import button. OS: OpenSUSE 11.2 + KDE 4.3.1. Error: invalid floating point operation. I changed GTK-styles, but no result. I did uninstall and re-install, but nothing works. Ffmpeg and all the related packages are correctly installed. In OpenSUSE 11.1 WinFF worked just fine. Does anyone has an idea to solve this?
Kind regards, Willem

[kalex77]

Hi Willem,

SuSE-11.2 is pretty fresh now, I don't have it yet. Maybe there is a library version mismatch or something like that.

You installed this version?
http://packman.links2linux.de/package/winff/124973
(winff-1.1.1-0.pm.1.4.i586.rpm)

There is another repo providing Winff:
http://download.opensuse.org/repositories/home:/enzokiel/openSUSE_11.2_Update/
Maybe the rpm from there works better (winff-1.1.1-9.1.i586.rpm).

Does the following command output any errors?

Code:

ldd -r /usr/bin/winff

[Willem]

Hi Kalex77,
Thank you very much for your answer. But also WinFF 1.1.1-9.1. i586 has the same problem. The console reports the following:
willem@linux-jcui:~> ldd -r /usr/bin/winff
        linux-gate.so.1 =>  (0xffffe000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb75e4000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb75c8000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb71b1000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb710d000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb70ca000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7002000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6ffc000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6fb3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6f99000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f7c000)
        libdl.so.2 => /lib/libdl.so.2 (0xb6f77000)
        libc.so.6 => /lib/libc.so.6 (0xb6e16000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6df7000)
        libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb6d4c000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6d47000)
        libm.so.6 => /lib/libm.so.6 (0xb6d1e000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6d10000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6d0a000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6c84000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6c5a000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6c26000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c13000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6c08000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6c04000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb6bf9000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6bf0000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6be5000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb6be0000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6bdc000)
        libpcre.so.0 => /lib/libpcre.so.0 (0xb6bad000)
        librt.so.1 => /lib/librt.so.1 (0xb6ba3000)
        /lib/ld-linux.so.2 (0xb7730000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6b9f000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb6b88000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb6b6a000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ae8000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6a80000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6a56000)
        libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb6a50000)
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb6a46000)
        libz.so.1 => /lib/libz.so.1 (0xb6a32000)
        libexpat.so.1 => /lib/libexpat.so.1 (0xb6a0b000)

I'm a rather Linux-newbie, but I don see any errors in this. What would you say?
Kind regards, Willem

[kalex77]

Hi Willem,

No, there seems to be no problem with missing libraries, at least there is no error message.

As I can read, you reinstalled the rpm and also tried the other rpm.

Did you also remove the .winff directory in your home directory?
After that, you would start from beginning with your winff.

Better than removing ist moving:

Code:

cd
mv .winff .winff_bak

After starting winff, can you hit any other button or does any action immediately cause a crash?

Is "Error: invalid floating point operation" the only error message you get when starting winff in a shell?
Or does the message appear in an error window?

Finally: Is your SuSE-11.2 a completely fresh install or an upgrade from 11.1 (an upgrade I suppose)?

[Willem]

Hi Kalex,
My OpenSUSE 11.2 is a complete fresh install (no update from 11.1), cause first I formatted the Linux partition in Ext4 (in stead of the previous Ext3). I didn't delete the WinFF directory in my home directory. I'll uninstall WinFF again and then also delete that directory. I'll let you know the results. I indeed reinstalled the rpm and tried the other one (the enzokiel rpm). The invalid floating point message is the only error message. When I click the Import button a new (but empty) window appears. In the titlebar of that window: <WinFF 2>. In that window the error message is appearing. After clicking on any button in the titlebar of that window (close, maximalize, or minimalize) WinFF is shutting down. Well I'll execute your late instructions and I'll let you know the results.

[Willem]

Kalex,
I uninstalled version 1.1.1-9.1. There wasn't any WinFF folder left in the Home directory. I tried the command mv, etc. (I don 't understand this), without result. I installed the whole thing again. Same error. Again uninstall. Then re-installed the Packman rpm (in stead of the enzokiel) and installed version 1.1.1-0.pm.1.4. Same error. No error messages in the console output Meanwhile I've posted a message on the Packman user group. Well, that's all I could do. What is very annoying: WinFF 1.1 just works in all versions of Windows. So I think we're landed here at one of the weaknesses of the Linux-concept. Everytime a Linux distribution uses a new kernel-upgrade and libs-upgrade apps get in a mess if not updated and packaged too. Did the communities never hear of downward compatible libraries? What do you think about that?

[rebterge73]

Hi Richard,

if my memory serves me well
a window to select the codec for rendering comes up after clicking the "render "-button.
this was, what I remember from the instructional video
I dont get that far as the program immediately crashes while clicking at the button.
Do I have other possibilities to make changes in the codec selection ?

Regards

RanX

[paul]

Did the communities never hear of downward compatible libraries?

Actually, this is what they usually do pretty nicely. The soname of a library is the way to tell if the api/abi changed. Most library writers don't change this easily and if they do there is nothing wrong with programs using the old libraries because programs usually know exactly which version of the library they need (at least as long as the older version is still available). Under Linux you can install multiple versions of the same library (try that on a windows machine) without problems. But apparently, the problem is more subtle than that.

As kalex77 already asked, can you start winff from a command prompt and copy all the output here?

[kalex77]

Hi,

I was curious enough to spend some extra time on this problem.
I installed SuSE-11.2 in a virtual machine.

Some information on the setup:
It's a fresh install of 11.2 with Gnome,
ffmpeg-0.5.20592svn-0.pm.1.1.i586 (packman)
winff-1.1.1-0.pm.1.4.i586 (packman)
gtk2-2.18.1-3.5.i586 (default from distribution, just as general info)

Winff starts and works fine, every button works, files can be added and removed, converted...

Of course there are some error messages, when starting winff in a shell, but nothing fatal:

Code:

[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve
property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value
"((GString*) 0x852a6a0)" of type `GString'

Willem's problem must be very specific. We will have to wait until he posts his error output from command line.

[paul]

I was curious enough to spend some extra time on this problem.
I installed SuSE-11.2 in a virtual machine.

Does your system yield the same response for

Code:

ldd -r /usr/bin/winff

as Willems system?

[Willem]

Hi guys,
Thanks for your co-operation. I found this message at the Packman Users Support:
Hi,
I can confirm that /WinFF 1.1.1-0.pm.1.4 crash if you click on //import
button
This is the console output:
/
TApplication.HandleException Invalid floating point operation
  Stack trace:
  $B68B06E4
  $B68C22AA
  $B68CB492
  $B74448A1
  $B74CF1C2
  $B74D0E41
  $B73C6944

(winff:11293): Gtk-CRITICAL **: gtk_style_detach: assertion
`style->attach_count > 0' failed
TApplication.HandleException: there was another exception during showing
the first exception
  Stack trace:
  $B73B8039
  $B73B87A4
  $B73C3AAF
[FORMS.PP] ExceptionOccurred
[FORMS.PP] ExceptionOccurred

Could that mean there's a kind of mismatch with gtk styles in KDE? I changed it already from QtCurve to Raleigh and than back, but it didn't work. By the way I'm still a Linux-newbie and I'm not quite familiar using the command line yet. How could I produce an error output with the Konsole in this case? Well it's getting a long story isn't it.
Kind regards, Willem

[Willem]

Hi folks,
I evolved in my efforts. When I started WinFF with the command line I got this error message:
[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
TApplication.HandleException Invalid floating point operation
  Stack trace:
  $B68456E4
  $B68572AA
  $B6860492
  $B73E78A1
  $B74721C2
  $B7473E41
  $B7369944
WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?

At first the two lines with WARNING appeared. When clicking the Import button the line TApplication. Handle Exception appeared and after that the Stack trace bla bla bla. After that the last WARNING line. Clicking on any button did crash WinFF. No further messages. To me it's all a mistery. Does this help you further?
Willem

[paul]

Could you ask these packman people to provide a non-stripped version of winff? The stacktrace is what will tell (hopefully) where it all goes wrong, but because it is stripped of the so called debugging symbols we humans don't see where in the code it goes wrong.

By the way, these first warning are I believe due to your keyboard not fully supported by the FreePascal code. I also always get these.

[kalex77]

Hi paul,

Yes, "ldd -r" produces exactly the same output (exept for the - I have no idea, how they are called in english - Einsprungadressen)

Code:

       linux-gate.so.1 =>  (0xffffe000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb75ec000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb75d0000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb71b9000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7115000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb70d1000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb700a000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7004000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6fbb000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6fa1000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f83000)
        libdl.so.2 => /lib/libdl.so.2 (0xb6f7e000)
        libc.so.6 => /lib/libc.so.6 (0xb6e1e000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6dff000)
        libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb6d54000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6d4f000)
        libm.so.6 => /lib/libm.so.6 (0xb6d25000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6d18000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6d12000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6c8c000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6c62000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6c2e000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c1b000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6c10000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6c0c000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb6c01000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6bf8000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6bed000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb6be8000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6be4000)
        libpcre.so.0 => /lib/libpcre.so.0 (0xb6bb5000)
        librt.so.1 => /lib/librt.so.1 (0xb6bab000)
        /lib/ld-linux.so.2 (0xb7732000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6ba7000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb6b90000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb6b72000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6af0000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6a88000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6a5e000)
        libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb6a58000)
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb6a4e000)
        libz.so.1 => /lib/libz.so.1 (0xb6a3a000)
        libexpat.so.1 => /lib/libexpat.so.1 (0xb6a13000)

Anyway, one remarkable difference between my setup an Willem's ist that he uses KDE an I use Gnome.

Packman provides two additional rpm's:
winff-debugsource and winff-debuginfo

I guess "debuginfo" is the one we need here.

@Willem: could you please install winff-debuginfo-[your winff version].rpm in yast and start winff again on command line?

@paul: I hope the output is more usable for you then.

If not, we could use ltrace - a LOT of output.

[Willem]

Hi Kalex and Paul,
I installed debuginfo WinFF. This is all what I get now:
[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
TApplication.HandleException Invalid floating point operation
  Stack trace:
  $B67C76E4
  $B67D92AA
  $B67E2492
  $B73698A1
  $B73F41C2
  $B73F5E41
  $B72EB944
TApplication.HandleException Access violation
  Stack trace:
  $B70E6FBA

Well, it's not much more, except: Access violation
Willem