Bug 223296

Can you reproduce this?  That's really bad...

Yes, every time.

Looks like I'm not quite RC1 (beta2 plus factory), so I justtried with  zen-updater-7.1.100-29, last changelog entry is:

jpr@square:~> rpm -q --changelog zen-updater | more
* Tue Nov 07 2006 - ro@suse.de
- fix manpage permissions

Still fails there, but it should be tested on a full RC1 install still (I'm still downloading).

I can confirm the bug using openSUSE 10.2 RC1.

This looks like a gtk library issue.

We could not find this issue when the binary (ZenInstaller.exe) was built on 
a suse 9.3 setup. However when we try to build zen-updater on OpenSuSE 10.2
(I have Beta 2) we are able to see this issue.. 

We are trying to see what exactly is causing this problem.. 

Any clues???

Fix submitted, see the patch included.  Try:
http://w3.suse.de/~jpr/zen-updater-7.1.100-31.i586.rpm


Issue seems to be in this code:
EventBox eb = new EventBox ();
eb.Add (l);

eb.ButtonPressEvent += delegate (object sender, ButtonPressEventArgs e) {
                    Label tl = eb.Child as Label;
                    filterType = (FilterType) Enum.Parse (typeof (FilterType), tl.Text);
                    this.GdkWindow.Cursor = normalCursor;
                    searchEntry.Text = String.Empty; 
                    filteredModel.Refilter ();
                    DisplayFilterLabels ();
};

The variable eb was null inside the delegate, I don't know if this is a compiler error not propogating eb into the delegate or a compiler error not erroring out because eb is out of scope.

Miguel says compiler bug, adding him as a CC.

What do you need from me?

*** Bug 223579 has been marked as a duplicate of this bug. ***

Just had a look at this and I can't reproduce this in the compiler.  This is the test case I used:

====
using System;

public class EventBox
{
        public event EventHandler ButtonPressEvent;

        public void ButtonPressed (EventArgs args)
        {
                if (ButtonPressEvent != null)
                        ButtonPressEvent (this, args);
        }

        public void Test ()
        { }
}

class X
{
        static void Main ()
        {
                EventBox eb = new EventBox ();
                eb.Test ();

                eb.ButtonPressEvent += delegate (object sender, EventArgs e) {
                        Console.WriteLine (eb != null);
                };

                eb.ButtonPressed (null);
        }
}
====

That works with all three versions of mcs/gmcs I have (1.2, latest SVN and my development tree).

Martin, we're shipping 1.1.18 on 10.2 still.

I'm not sure 1.2 is viable because extended attribute support is broken (which is bad for beagle).

Mono 1.2.1 fixed that issue.

Miguel, do you have a fix for 1.1.8?

Hello,

We could backport the compiler, but we are aware that it contains a number of regressions on anonymous methods.  Martin is working full time (weekends included) to get these issues fixed.

Miguel.

So, there's no easy fix for this in the compiler?

We're using 1.1.8 and what can we do to fix zen-updater?

Hello Andreas,

Let me provide all the information that I have:
* JP said they already provided a patch/workaround.
* Neither Martin or myself were able to reproduce the problem with a small program on either 1.1.18 or 1.2, so we suspect the sample is not complete.
* We know that 1.1.18 shipped with a large refactoring of the code for anonymous methods that closed about 20 anonymous method bugs.
* The refactoring contained a number of corner case bugs, so we started work immediately when we discovered those (the test suite was not complete enough to have caught those).
* We are currently working on the refactoring and have it almost ready.
* We were hoping we would have this ready before December 4th, which was one of the deadlines we were given (I forget for what it was though, SLED SP1 or OpenSUSE 10.2 or 10.3).

All we could think of was to ship an upgraded compiler due to the issues that we are aware of.

Ah, it seems that I was confused by comment #11.  Thanks for the explanation.

I thought there was an additional compiler bug.  So, the workaround from #10 should fix the problem.
JP, correct?  In that case let's close this bug...

Miguel, don't know who gave you Dec 4th - that one would be too late for 10.2.

JP, is this one fixed now?

I was unable to reproduce with the patch applied.

Please, reopen if needed.

We worked around the problem, but the compiler stills need to be checked.