[Issue 7303] New: Erroneous closure behavior

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jan 17 05:14:19 PST 2012


http://d.puremagic.com/issues/show_bug.cgi?id=7303

           Summary: Erroneous closure behavior
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: dpx.infinity at gmail.com


--- Comment #0 from Vladimir Matveev <dpx.infinity at gmail.com> 2012-01-17 05:14:16 PST ---
Consider this code:

module test;

import std.stdio;

class C {
    public int x;

    this(int x) {
        this.x = x;
    }
}

void delegate() test(int n) {
    C c = new C(n);

    void inner() {
        writeln(c.x);
    }

    return () { inner(); };
}

void main(string[] args) {
    auto d1 = test(12);
    auto d2 = test(13);
    d1();
    d2();
}

It prints 13 two times, though it should print first 12, then 13.

I found this problem while trying to create simple test case for the following
similar closure-related error. I'm using gtkd to create UI for my program. This
code

    TextBuffer logBuffer = logTextView.getBuffer();

    void logln(string s) {
        TextIter it = new TextIter();
        logBuffer.getEndIter(it);
        logBuffer.insert(it, s ~ "\n");
    }

    auto computeHandler = (Button aux) {
        logln("Compute pressed.");
    };

    auto singlePlotHandler = (Button aux) {
        logln("Single pressed.");
    };

    auto comparePlotHandler = (Button aux) {
        logln("Compare pressed.");
    };

segfaults when any of the *Handler closures are called (from the gtk event
handling code). This happens because logBuffer variable used in logln function
is null, though it shouldn't. If I use logBuffer in any way in any of the
closures, the code works fine.

It seems that there's a problem in closed variables detection in both programs.
In simple test case it does not crash the program because of its simplicity,
but in the second one stack is overwritten many times after the delegates are
created, so no wonder it fails.

I'm using dmd v2.057 on x86_64 linux system.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list