Winff startup warning about access violation and possible data corruption

[Anton Kraus]

Binary package hint: winff

Executing Lucid's WinFF in a terminal leads to the following output:

[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00364F6E
  $08290BCD
  $081BCA9B
  $081BBCEA
  $0817AC98
  $0817A885
  $0817B87A
  $0817AD75
  $0817A885
  $0817B87A
  $0817AD75
  $08077CC1
  $0807CFAC
  $0807E069
  $0817A885
  $0817B87A
  $080853CE
TApplication.HandleException Access violation
  Stack trace:
  $00364F6E
  $08290BCD
  $081BCA9B
  $081BBCEA
  $0817AC98
  $0817A885
  $0817B87A
  $0817AD75
  $0817A885
  $0817B87A
  $0817AD75
  $08077CC1
  $0807CFAC
  $0807E069
  $0817A885
  $0817B87A
  $080853CE

------------------------------------

Additionally, a popup opens. See attached screenshot.

Pressing OK closes the popup, but the program does not show up afterwards.

Deleting the .winff folder had no effect.

WinFF in Karmic worked flawlessly.

ProblemType: Bug
Architecture: i386
Date: Sun Feb 14 18:58:09 2010
DistroRelease: Ubuntu 10.04
NonfreeKernelModules: nvidia
Package: winff 1.2.0-1ubuntu1
ProcEnviron:
 LANGUAGE=en_GB.UTF-8
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-13.18-generic
SourcePackage: winff
Uname: Linux 2.6.32-13-generic i686

[Paul Gevers (paul-climbing)]

Thanks for reporting this issue.

I am not sure, but it might be related to the fact that gtk+2.0 got an update two days ago (i.e. after this winff was build). At least that is what upstream has seen before with this kind of error. Maybe rebuilding winff is all that is needed. Could somebody verify this?

[Anton Kraus (done)]

Thanks for the quick response.

I used apt-build to rebuild winff, but I'm still running into this problem.

[Paul Gevers (paul-climbing)]

Hmm, than I have to verify and test in a Lucid environment. Please allow some time for me to do this, as I don't have one now, and no time today.

Of course, if somebody else knows what is going on, please fill us in.

By the way, are you 100% sure that after apt-build your newly build package was installed?

[Anton Kraus (done)]

Yes, I am certain that the package generated by apt-build was installed.
I ran sudo dpkg -i /var/cache/apt-build/repository/winff_1.2.0-1ubuntu1_i386.deb to make absolutely sure it was.

Is there anything else I can do to help diagnose the problem?

[Paul Gevers (paul-climbing)]

This package also builds a debugging package. I am not sure if this would give helpful information (it should of course) so if you can install winff-dbg and get the stack trace as above with debugging symbols that might indeed be useful.

[Paul Gevers (paul-climbing)]

I need some more to confirm, but I believe it is an issue with the compiler fpc. Even the IDE for it (lazarus-ide) quits on me with (looks similar eh):

TApplication.HandleException Access violation
  Stack trace:
  $B7D6DF6E
  $082BE3BD
  $081EA28B
  $081E94DA
  $081A8488
  $081A8075
  $081A906A
  $081A8565
  $081A8075
  $081A906A
  $081A8565
  $080789F1
  $0807DCDC
  $0807ED99
  $081A8075
  $081A906A
  $081A7151

Could you install lazarus-ide and see if it also quits on you? If so, feel free to file a bug against lazarus and link it here.

[Paul Gevers (paul-climbing)]

I will update the packages in my ppa soon (probably tomorrow) and see if the problem goes away with an update of fpc. We can test from there.

https://launchpad.net/~paul-climbing/+archive/ppa/

[Paul Gevers (paul-climbing)]

Maybe related to upstream http://62.166.198.202/view.php?id=15640

[Anton Kraus (done)]

I get the same exception when closing lazarus-ide.

I've installed the winff-dbg package, but I can't see any difference in the error messages. Or should I look elsewhere?

You PPA is now in my sources.lst.

[Paul Gevers (paul-climbing)]

Ok, I just uploaded fpc, lazarus, hevea and winff to my PPA to see if a rebuild helps. Please confirm or deny that this fixes the problems of winff and lazarus (after winff builds).

[Anton Kraus (done)]

Sadly, the latest ppa package (1.2.0-1ubuntu2~ppa1l) still exhibits the same behaviour.

[Paul Gevers (paul-climbing)]

Thanks for reporting. Does also lazarus-ide exhibit that behavior?

Paul

[Paul Gevers (paul-climbing)]

Upstream winff has also tested and installed the packages from lucid and can NOT confirm the problems. He has a 64bits computer thou. Maybe there is a clou there?

[Anton Kraus (done)]

I'm using a 32 bit machine, so maybe we are onto something.

lazarus-ide from your ppa now closes without an error message, by the way.

[Paul Gevers (paul-climbing)]

I forgot that we had this bug upstream: http://code.google.com/p/winff/issues/detail?id=55

It turned out that the problem was with a buggy theme in KDE. Are you using KDE as your desktop manager? If yes, can you test if the following helps (it does NOT for me thou):

on Kubuntu 9.10 this happens as well but I found if you go into system settings >
Appearance > GTK+Appearance and change the Widget Style from QTCurve to Raleigh it no
longer crashes. you can then change back to QTCurve so Firefox doesn't look ugly.

AND

Also, if you want a selection install all available gtk+ themes from synaptic and you
can choose a look that fits better with your kde theme. all gtk+ themes I tried
worked fine, the only one that seems to crash winff is QTCurve

[Anton Kraus (done)]

It seems the KDE issue is unrelated, as I'm running Gnome.

I've managed to narrow the bug down. It is definitely in winff's source code and it must have been introduced somewhere between versions 1.0.4 and 1.2.0.

I say this because, when installed in a Lucid environment, Karmic's winff version (winff_1.0.4-2ubuntu2) runs perfectly.

[Anton Kraus (done)]

On my search for deb packages of intermediate winff versions I came across http://code.google.com/p/winff/downloads/list?can=1&q=winff
winff_1.1.1-1~ppa1k_i386.deb from this source works on my system.

[Paul Gevers (paul-climbing)]

And how about the Karmic version of winff_1.2.0 (either from my PPA or google (they are the same))? When I try that in Lucid it crashes just the same, however, when I run the SAME package in Karmic I have no problems. I am getting very curious to what it is. Apparently older Ubuntu versions don't have this problem... We also haven't seen many reports. It seems that it is related to other parts of the system.

With regards to the difference between 1.0.4 and 1.2.0, there is indeed extra functionality which might need extra library functions to operate.

I will investigate further today.

[Anton Kraus (done)]

Indeed, version 1.2.0 from the Karmic PPA crashes in a Lucid environment.

I' ve tried switching between the libXXX-extra packages as provided by Ubuntu and those from the Medibuntu repository. There is no effect on whether a certain winff version works or not.

Which other parts of the system could this be related to? Do you need specific information about my system?

[Paul Gevers (paul-climbing)]

I have attached valgrind and gdb logs in accordance to https://wiki.ubuntu.com/Backtrace and https://wiki.ubuntu.com/Valgrind

[Niall Creech (sevenmachines-deactivatedaccount)]

looks like unit1.pas fails in some functions on an empty presetname. i'll put a check in on that in the crash places but there may be a need to look out for more :). I've no idea why this affects i386 but not amd64, although it does affect amd64 when using gdb, strange..

[Niall Creech (sevenmachines-deactivatedaccount)]

winff (1.2.0-1ubuntu2) lucid; urgency=low

  * debian/patches/empty-presetname-fix.patch:
    - unit1.pas causes an access violation when trying to use an empty
    presetname. This checks for an empty name and avoids accessing it.
    (LP: #521818)

[Niall Creech (sevenmachines-deactivatedaccount)]

looks like at least one of these changes is in svn upstream so it should be reasonable. unfortunately there are still more problems on i386 only so the previous debdiff wont work on that :(

[Paul Gevers (paul-climbing)]

@ SevenMachines

Where did you find it in the upstream svn? I seem not able to find it.

What are the other problems you are talking about?

Why would this suddenly be a problem in Lucid when the same binary is not a problem in Karmic. Or is it that the problem in Karmic is just not detected?

I will test your patch shortly in my ppa.

[Niall Creech (sevenmachines-deactivatedaccount)]

in svn checkout http://winff.googlecode.com/svn/trunk/ winff-read-only
unit1.pas:664 you'll see the change of adding the check
   if presetname <> '' then

this clears the original error (if added in both places as in the debdiff) on i386 and running gdb winff on amd64.
this may well not fix the core problem though as i now have the errors attached, the problem in gtk2wsstdctrls.pp:513 is causing the exception, giving the warning dialog, the invalid_free is causing the actual crash.

[Niall Creech (sevenmachines-deactivatedaccount)]

i'm looking into lazarus svn to see if this could be the issue, theres been changes to gtk2wsstdctrls.pp and the calls that were causing the problem seem to no longer exist

[Niall Creech (sevenmachines-deactivatedaccount)]

i might look at fpc 2.4 from debian/sid too, its unfortunately a rabbit warren of things to me, i'll look at it more in a couple of days but i'm using 32bit on a virtual machines so its a bit slow so hopefully someone will spot the gtk2wsstdctrls.pp:513 error before then :)

[Paul Gevers (paul-climbing)]

@ SevenMachines

Sorry to say, but you are looking at the wrong tree. In trunk there are two trees, " winff --username bggmtt", this is the real thing and "winff1.5" which is not really used.

Your patch didn't solve the problem (but I guess that is what you meant anyway). My winff still crashes with the same warning... Maybe some additional location?

[Niall Creech (sevenmachines-deactivatedaccount)]

good to know, i'd made the changes before looking at svn so it wasnt a costly mistake. the changes in themselves are reasonable, and do fix a bug, but i do get the feeling theres a more core problem. the fact only i386 is affected is probably a clue. i'm guessing that some other bug has only exposed the bug the previous debdiff closed.
i'll unassign myself for now and look at it again later in the week. If someone with a i386 install wants to tackle it though that would be great!

[Niall Creech (sevenmachines-deactivatedaccount)]

just to add, winff 1.2.0-1 works fine in debian sid i386 so it might be a ubuntu only thing, maybe newer gtk version and so on

[Paul Gevers (paul-climbing)]

I have cleaned up the patch a little bit, so that it is better review-able. I also included several fixes for possible uninitialized variables.

The patch does not solve all the problems, because the (gtk2wsstdctrls.pp:513) remains and is part of lazarus?

One remark thou: as the package in my PPA in Karmic also builds against the latest version of lazarus (although a different version of fpc), it seems to me that the problem is not in lazarus, but instead in the gtk library, that got updated several days ago. How to figure that one out?

[Niall Creech (sevenmachines-deactivatedaccount)]

theres a few logic problems with formtop (and maybe formleft?) in unit1.pas where its tested for >0 but hasnt been initialised so it should really have a value set before the if statement tries to get a value for it. but i think your right, its an issue of what relevant libraries ubuntu is using as compared to debian sid,i think we're using a higher version of gtk, and a lesser version of fpc, i think the problem lies somewhere in there. perhaps gtk 2.19 is doing something differently that lazarus doesnt expect.
if amd64 works and i386 doesnt, that does suggest to me is an underlying problem of the various things winff uses, so lazarus/fpc/gtk

[Niall Creech (sevenmachines-deactivatedaccount)]

rebuilding lazarus with the commit 23695 then rebuilding winff using this 'fixed' version of lazarus solves the problem here. if someone could try it out on i386 to verify?

[Niall Creech (sevenmachines-deactivatedaccount)]

Paul Gevers: would it be ok for you to take care of making any changes to lazarus/winff if they look ok to you? I notice you've done plenty of work on this before and i know literally nothing about pascal so it might be better for someone more knowledgeable to be assigned :) if not, let me know.

there a test build of patched lazarus and patched winff built against it here which seems know to work fine on i386/amd64
https://launchpad.net/~sevenmachines/+archive/release+1/+packages

[Paul Gevers (paul-climbing)]

I will have a look at both, but I need sponsors, because I can not commit.

Also, the patch winff (I think there are two "end" tags too much) crash
on me when I try to add a file. I am looking into it.

Should we mark this bug as: affects lazarus?

Paul

[Niall Creech (sevenmachines-deactivatedaccount)]

i'd probably open a new lazarus bug and attach a debdiff with the svn fix in it as its not specifically related to winff

i'm not seeing any other crashes at all, everything seems fine at the moment though i havent tested too much. if you find some steps to reproduce the new adding file crash i'll try and test it too

[Paul Gevers (paul-climbing)]

On 02/23/10 21:23, SevenMachines wrote:
> i'm not seeing any other crashes at all, everything seems fine at the
> moment though i havent tested too much. if you find some steps to
> reproduce the new adding file crash i'll try and test it too

It doesn't crash, but hangs. I tried your version of lazarus-ide and
when I press <ctrl>-o (to open a project) I get (that is the same error
that I get when I try to open a file with winff. Seems still to be
somewhere in fpc or lazarus.

TApplication.HandleException Invalid floating point operation
Stack trace:
  $B67E5761
  $B68023BC
  $B73F5ED1
  $B7493332
  $B749524A
  $B7365128
  $B71347D9
  $B7136152
  $B714D576
  $B714EE23
  $B714F706
  $B74A8C9E
  $B735DD84
  $B71A7A6B
  $B71A7A1A
  $B71A7A1A
  $B71D7164

(lazarus:20858): Gtk-CRITICAL **: gtk_style_detach: assertion
`style->attach_count > 0' failed
TApplication.HandleException: there was another exception during showing
the first exception
  Stack trace:
  $B73548D0
  $B73550F4
  $B7361019
  $B71347D9
  $B7136152
  $B714D576
  $B714EFA4
  $B714F706
  $B74B09C1
  $B73D7F50
  $B714456C
  $B71347D9
  $B7136152
  $B714D1CA
  $B714EFA4
  $B714F706
  $B72C4756
lazarus.pp - unhandled exception
[FORMS.PP] ExceptionOccurred

[Niall Creech (sevenmachines-deactivatedaccount)]

sadly i dont get any problems with either the lazarus-ide/lazazrus-src or winff from my ppa doing what you describe so i cant really be any help here. i guess maybe gdb or valgrind might help show up any problem.

it looks like theres a sync request in for lazarus and fpc 2.4. it doesnt look like the new lazarus verion has the fix mentioned previously, might be worth trying both of the newer debian versions and seeing if that helps. i suspect what your having is a lazarus problem though

[Paul Gevers (paul-climbing)]

I'll attach my gdb and valgrind output while running your version of winff and pressing the "Add" button. While running it in gdb, it crashed; while running in valgrind it didn't... Strange.

[Paul Gevers (paul-climbing)]

I will see if upgrading fpc to version 2.4.0 helps for me in my PPA.

[Niall Creech (sevenmachines-deactivatedaccount)]

hi, it might be worth having a look at http://mantis.freepascal.org/view.php?id=15114
seems to be similar, you could try changing qt/gtk themes around a bit and seeing if that gets rid of the problem. might well not be a fpc or lazarus bug

[Paul Gevers (paul-climbing)]

I confirm that my problems with SevenMachines packages go away by moving my theme in KDE away from QTcurve for BOTH the widget style and GTK+style. My bet would be that there is a problem with the qtcurve library exposed by lazarus. What do you think?

I commented on upsteams bug tracker as well.

[Niall Creech (sevenmachines-deactivatedaccount)]

you might want to open a separate bug on gtk2-engines-qtcurve, which has the problem.
In gtk2-engines-qtcurve-1.0.2, common/common.h:1143 we have

double min=QTC_MIN(QTC_MIN(r, g), b),
           max=QTC_MAX(QTC_MAX(r, g), b),
           delta=max - min;

if max == min then delta is 0 so when we try to divide by it later on, it crashes. adding a check, something like
if (delta == 0 )
        delta=1;

seems to cover this case where r,g and b are all equal, although i've chosen a value of 1 for delta arbitrarily, the package maintainer will know if theres a wiser fix.

I've put a 'fixed' package in the ppa below if you want to check it, it works in gnome using the qtcurve engine, i assume it'll work in kde
https://launchpad.net/~sevenmachines/+archive/release+1

[Mike Durham (mdurhamesq)]

Thanks SevenMachines, that fixed it for me (gnome).

[Flávio Etrusco (etrusco)]

SevenMachines, what is this code related to? Would this bug be caused by trying to paint a zero-sized area?

[Anzenketh (anzenketh)]

Added Link to upstream.

[Niall Creech (sevenmachines-deactivatedaccount)]

Flávio Etrusco: its used to set the alternating colour on a directory listing. i've added the bug, with a hopefully 'less red' fix :)

https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-qtcurve/+bug/528872

[Flávio Etrusco (etrusco)]

Paul, if you have a reproducible test-case, can you try this fix?

diff --git a/lcl/interfaces/gtk2/gtk2widgetset.inc b/lcl/interfaces/gtk2/gtk2widgetset.inc
--- a/lcl/interfaces/gtk2/gtk2widgetset.inc
+++ b/lcl/interfaces/gtk2/gtk2widgetset.inc
@@ -592,7 +592,7 @@ begin
     {$IFDEF windows}
       Set8087CW($133F);
     {$ELSE}
- SetExceptionMask(GetExceptionMask + [exZeroDivide]);
+ SetExceptionMask(GetExceptionMask + [exZeroDivide, exInvalidOp]);
     {$ENDIF}
   {$ENDIF}
   {$ifend}

[Paul Gevers (paul-climbing)]

@Flávio Etrusco , you are now talking about a workaround for the qtcurve library issue? I will test this (hopefully tomorrow)

[Flávio Etrusco (etrusco)]

Paul Ishenin, a FPC developer, was the one who suggested this fix. I
got the same impression, to what he replied clearly that this was a
fix, not a workaround. It's something like this is to avoid trapping
some FPU exceptions, since C code handles them differently, or
that the CPU exception flag is leftover from the C library function
call which C code wouldn't bother but FPC needs it to be explicitly
cleared upon the function return...

[Paul Gevers (paul-climbing)]

Created bug 529469 for lazarus, please discuss the lazarus issue there further.

[Paul Gevers (paul-climbing)]

Oops, should have waited with subscribing ubuntu-universe-sponsors until bug 529469 is solved. Unfortunately I can't undo it.

[Paul Gevers (paul-climbing)]

Bug 529469 just got fixed by a patched upload. Subscribing ubuntu-universe-sponsors again with the kind request to apply my debdiff.

[Paul Gevers (paul-climbing)]

fpc (the compiler) and lazarus are synced/merged recently (bug 525523). An upload of winff would be great. Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package winff - 1.2.0-1ubuntu2

---------------
winff (1.2.0-1ubuntu2) lucid; urgency=low

  [ Niall Creech ]
  * debian/patches/empty-presetname-fix.patch:
    - unit1.pas causes an access violation when trying to use an empty
    presetname. This checks for an empty name and avoids accessing it.
    (LP: #521818)

  [ Paul Gevers ]
  * Added preset file for ubuntu with libfaac based presets removed
    (LP: #527548)
 -- Paul Gevers <email address hidden> Sun, 28 Feb 2010 19:16:57 +0100