Thread overview
[Issue 7978] New: UTF exception (memory corruption?) using std.range.chain (behavior changes with -g)
Apr 24, 2012
Brad Anderson
Jul 27, 2012
Brad Anderson
Oct 17, 2012
Brad Anderson
Oct 17, 2012
Brad Anderson
Dec 28, 2012
SomeDude
Dec 28, 2012
Brad Anderson
Mar 06, 2013
Brad Anderson
Mar 06, 2013
Andrej Mitrovic
April 24, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978

           Summary: UTF exception (memory corruption?) using
                    std.range.chain (behavior changes with -g)
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: eco@gnuk.net


--- Comment #0 from Brad Anderson <eco@gnuk.net> 2012-04-23 21:02:41 PDT ---
Compiling the following code using DMD 2.059 without -g results in a UTF exception (memory corruption?) after outputting ["a", "b",. Compiling with -g produces no exception but the output is incorrect (["a", "b", "0", "1", "2"] should be ["a", "b", "a0", "a1", "a2"]).  Now, if you replace the iota line with with the commented out sequence line it works the other way. Without -g gives no exception (but correct output this time), with -g results in a UTF exception. It's a bit unsettling that adding debug info can change the behavior of the program.

   import std.stdio, std.range, std.algorithm, std.string;

   void main()
   {
       writeln(gen(["a", "b"]).take(5));
   }

   auto gen(string[] lst)
   {
       auto prefix = lst[0];
       auto a = iota(10).map!(a=>format("%s%d", prefix, a))();
       //auto a = sequence!"n+1"().map!(a=>format("%s%d", prefix, a))();
       return chain(lst.save, a);
   }

Similar code can also produce access violations as can be seen here: http://forum.dlang.org/post/owqlhtpfnxjujwuxkeob@forum.dlang.org

I'm not sure how to go about reducing this.  Sometimes I can get it to work (using a global fixed it in one case though wasn't suitable for my needs). Moving it out of its own function into main() also fixes it sometimes but not always.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 27, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978


Brad Anderson <eco@gnuk.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #1 from Brad Anderson <eco@gnuk.net> 2012-07-27 00:58:21 PDT ---
I see my error.  Prefix is local so can't be captured in the closure.  Passing lst by ref and making it not an rvalue resolves this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978



--- Comment #2 from hsteoh@quickfur.ath.cx 2012-10-16 22:13:37 PDT ---
According to TDPL (section 5.8.1) it should be valid to reference local variables from a closure. So this is a valid bug. I'll let you decide whether to reopen it; I already opened issue 8832 for probably the same bug. (Looks like in both cases it's the map delegate that's causing trouble.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978


Brad Anderson <eco@gnuk.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
           See Also|                            |http://d.puremagic.com/issu
                   |                            |es/show_bug.cgi?id=8832
         Resolution|INVALID                     |


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978



--- Comment #3 from Brad Anderson <eco@gnuk.net> 2012-10-16 22:20:24 PDT ---
I've reopened so I'm reminded to check on this if issue 8832 gets fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 28, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978


SomeDude <lovelydear@mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear@mailmetrash.com
           Platform|All                         |x86_64


--- Comment #4 from SomeDude <lovelydear@mailmetrash.com> 2012-12-28 04:47:58 PST ---
Tested with 2.060 on DPaste:

     32 bits 64 bits.
DMD  PASS(1) FAIL
GDC  FAIL    PASS(2)
LDC  FAIL    FAIL

(1) output: ["a", "b", "0", "1", "2"]
(2) output: ["a", "b", "\x01\x000", "\x01\x001", "\x01\x002"])

http://dpaste.dzfl.pl/fork/2cd77316

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 28, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7978



--- Comment #5 from Brad Anderson <eco@gnuk.net> 2012-12-28 13:58:24 PST ---
(In reply to comment #4)
> Tested with 2.060 on DPaste:
> 
>      32 bits 64 bits.
> DMD  PASS(1) FAIL
> GDC  FAIL    PASS(2)
> LDC  FAIL    FAIL
> 
> (1) output: ["a", "b", "0", "1", "2"]
> (2) output: ["a", "b", "\x01\x000", "\x01\x001", "\x01\x002"])
> 
> http://dpaste.dzfl.pl/fork/2cd77316

I'd just like to add that the PASS cases are still incorrect (obviously since the output differs). They do build though which is what someone reading this should take "PASS" to mean. I just tried with DMD git (2.061 alpha-ish at the moment) and it throws this error message now:

Error: function std.range.chain!(string[],MapResult!(__lambda2,
Result)).chain.Result.save cannot get frame pointer to gen

So at least the compiler seems to be somewhat aware of a frame pointer problem now although it should be able to accept it by creating a closure for this bug to be fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 06, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7978


Brad Anderson <eco@gnuk.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


--- Comment #6 from Brad Anderson <eco@gnuk.net> 2013-03-06 09:14:43 PST ---
This is fixed in 2.062 (tested on Windows and Linux).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 06, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7978


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com
         Resolution|FIXED                       |WORKSFORME


--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-03-06 09:16:55 PST ---
Fixed but no associated pull -> worksforme.

Don't blame the messenger, that's how Walter wants it.

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