digitalmars.D.bugs - [Issue 7251] New: GC not working
- d-bugmail puremagic.com (50/50) Jan 08 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (13/13) Jan 09 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (11/11) Feb 29 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (13/14) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (14/18) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (14/26) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (15/26) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (19/37) Mar 04 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7251
- d-bugmail puremagic.com (14/14) May 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7251
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Summary: GC not working Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: regression Priority: P2 Component: druntime AssignedTo: nobody puremagic.com ReportedBy: wfunction hotmail.com --- Comment #0 from wfunction hotmail.com 2012-01-08 23:40:33 PST --- On DMD 2.057, the code: import core.memory, std.stdio; extern(Windows) int GlobalMemoryStatusEx(ref MEMORYSTATUSEX lpBuffer); struct MEMORYSTATUSEX { uint Length, MemoryLoad; ulong TotalPhys, AvailPhys, TotalPageFile, AvailPageFile; ulong TotalVirtual, AvailVirtual, AvailExtendedVirtual; } void testA(size_t count) { size_t[] a; foreach (i; 0 .. count) a ~= i; } void main() { MEMORYSTATUSEX ms; ms.Length = ms.sizeof; foreach (i; 0 .. 32) { testA(16 << 20); GlobalMemoryStatusEx(ms); stderr.writefln("AvailPhys: %s MiB", ms.AvailPhys >>> 20); } } Gives output: AvailPhys: 3711 MiB AvailPhys: 3365 MiB AvailPhys: 3061 MiB AvailPhys: 2747 MiB AvailPhys: 2458 MiB core.exception.OutOfMemoryError Obviously, the GC is non-functional... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 08 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 David Simcha <dsimcha yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dsimcha yahoo.com Resolution| |INVALID --- Comment #1 from David Simcha <dsimcha yahoo.com> 2012-01-09 14:47:00 PST --- This looks like false pointers. testA allocates 48 MB for its largest array on each run. We really need precise heap scanning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 09 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 wfunction hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from wfunction hotmail.com 2012-02-29 20:08:19 PST --- Just wondering, why was this marked as "Resolved, Invalid" with no comment? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 29 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |clugdbug yahoo.com.au Resolution| |INVALID --- Comment #3 from Don <clugdbug yahoo.com.au> 2012-03-01 01:22:39 PST --- (In reply to comment #2)Just wondering, why was this marked as "Resolved, Invalid" with no comment?Huh? Comment #1 was added when it was closed. Reclosing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 wfunction hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |REMIND --- Comment #4 from wfunction hotmail.com 2012-03-01 02:01:33 PST --- (In reply to comment #3)(In reply to comment #2)Wait what? "This looks like false pointers [...] We really need precise heap scanning." Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the meaning of the above? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Just wondering, why was this marked as "Resolved, Invalid" with no comment?Huh? Comment #1 was added when it was closed. Reclosing.
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 --- Comment #5 from Don <clugdbug yahoo.com.au> 2012-03-01 03:39:55 PST --- (In reply to comment #4)(In reply to comment #3)No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers. You marked this as regression, is there any previous compiler where this worked? (reopen if it there is). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------(In reply to comment #2)Wait what? "This looks like false pointers [...] We really need precise heap scanning." Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the meaning of the above?Just wondering, why was this marked as "Resolved, Invalid" with no comment?Huh? Comment #1 was added when it was closed. Reclosing.
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 --- Comment #6 from wfunction hotmail.com 2012-03-01 14:53:44 PST --- (In reply to comment #5)No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers.I think you might have misunderstood the problem, like I originally did. I am ********** NOT *********** filling the system with false pointers. See David Simcha's comment in response to mine: http://stackoverflow.com/a/8796226/541686 It's inherently defective -- I'm merely _allocating_ a lot of memory, that's all. The rest is a problem with the GC's algorithm. (Unless you expect that no one will allocate one 20-MB chunk of RAM?)You marked this as regression, is there any previous compiler where this worked? (reopen if it there is).I marked it as "remind", since I'm sorta reminding about this bug... if that's not the implied meaning then my bad, but this still needs to be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Rob Jacques <sandford jhu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 CC| |sandford jhu.edu Platform|x86 |All OS/Version|Windows |All Severity|regression |minor --- Comment #7 from Rob Jacques <sandford jhu.edu> 2012-03-04 09:53:01 PST --- (In reply to comment #6)(In reply to comment #5)The static data segment and the stack generate _always_ contain false pointers. So even if you're not generating them yourself much, they do exist and things will get stuck. Also, direct use of ~= is discouraged; appender is recommended instead and there patch for appender that solves this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers.I think you might have misunderstood the problem, like I originally did. I am ********** NOT *********** filling the system with false pointers. See David Simcha's comment in response to mine: http://stackoverflow.com/a/8796226/541686 It's inherently defective -- I'm merely _allocating_ a lot of memory, that's all. The rest is a problem with the GC's algorithm. (Unless you expect that no one will allocate one 20-MB chunk of RAM?)
Mar 04 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Leandro Lucarella <leandro.lucarella sociomantic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leandro.lucarella sociomant | |ic.com Resolution|REMIND |DUPLICATE --- Comment #8 from Leandro Lucarella <leandro.lucarella sociomantic.com> 2013-05-30 04:54:25 PDT --- I think is better to set this as a duplicate of #3463, as when that one gets fixed, this one should be fixed too. *** This issue has been marked as a duplicate of issue 3463 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 30 2013