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



--- Comment #10 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2013-09-13 13:22:18 PDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > 32bits? Allocating large blocks in a loop?
> > Good luck with that... sooner or later they would be pinned by something that
> > looks like a pointer to GC.  We are back to false pointers and precise
> > collection topic.
> > 
> > How std.traits affects that is interesting thing, maybe inflates executable size. Anyway this is game of chance so any slight change may avoid it or bring it back.
> 
> 2 things I don't understand:
> 
> 1. New initializes, so the block contains nothing but 0x00's. How could that contain a false pointers? EDIT: Maybe the size/capacity info is wrongly seen as

False pointers that HAPPEN TO POINT INTO THAT BLOCK. I can't imagine we are having this conversation again. The larger the block the better target it makes.

> pointer?
> 
> 2. Besides, the GC knows about NO_SCAN, doesn't it? We are explicitly asking for new ubytes, which is a non-pointer type. Why would the GC scan any of that at all anywas?
> 

Yes it SHOULDN'T scan THAT BLOCK.

> If replace the call with GC.malloc(BIG_SIZE, GC.BlkAttr.NO_SCAN), then my win32
> runs forever...
> 

Or change something else and it might not... ? This is an erratic issue.

> --------
> 
> TLDR, I don't see how the false pointer issue in 32 bit environment would produce this failure.

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

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



--- Comment #11 from monarchdodra@gmail.com 2013-09-13 13:53:36 PDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > 2 things I don't understand:
> > 
> > 1. New initializes, so the block contains nothing but 0x00's. How could that contain a false pointers? EDIT: Maybe the size/capacity info is wrongly seen as
> 
> False pointers that HAPPEN TO POINT INTO THAT BLOCK. I can't imagine we are having this conversation again. The larger the block the better target it makes.

Ah. Right.

I apologize for not being there the last time you had this conversation...

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

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



--- Comment #12 from Temtaime <temtaime@gmail.com> 2013-09-13 23:43:45 PDT ---
It's array of ubytes, not pointers. GC mustn't scan its content.

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

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


safety0ff.bugz@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz@gmail.com


--- Comment #13 from safety0ff.bugz@gmail.com 2013-10-03 06:45:06 PDT ---
(In reply to comment #12)
> It's array of ubytes, not pointers. GC mustn't scan its content.

I think you misunderstand, something in std.traits gets scanned and it is treated as a pointer into the array of ubytes.

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