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

           Summary: Limit static object sizes
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Mac OS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrei@metalanguage.com


--- Comment #0 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-05 17:38:13 PDT ---
Objects of very large size can corrupt memory when used via null pointers:

struct S {
    char raw[100_000];
}

S * s = null;

To avoid this, static object sizes should be limited to a value that guarantees hardware memory protection (e.g. 64KB).

-- 
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=5176


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2010-11-06 00:46:12 PDT ---
Is this for @safe modules only?
If the answer is negative, what's the way to override this limit? If I am
writing a kernel using D, that's a system language, I may want to ignore this
corruption problem.

-- 
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=5176


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg@gmail.com


--- Comment #2 from nfxjfg@gmail.com 2010-11-06 02:46:38 PDT ---
64 KB ought to be enough for everyone.

-- 
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=5176



--- Comment #3 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-06 06:43:55 PDT ---
This change doesn't limit what can be done in a systems-level program.

-- 
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=5176


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michel.fortin@michelf.com


--- Comment #4 from yebblies <yebblies@gmail.com> 2011-06-16 01:04:46 PDT ---
*** Issue 3677 has been marked as a duplicate of this issue. ***

-- 
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=5176



--- Comment #5 from Michel Fortin <michel.fortin@michelf.com> 2011-06-16 06:23:20 EDT ---
(In reply to comment #0)
> To avoid this, static object sizes should be limited to a value that guarantees hardware memory protection (e.g. 64KB).

I think on OS X the size of that guaranty is significantly smaller, 4 Kb if I remember well. Is it reasonable to limit structs and objects to 4 Kb on OS X?

Note that it's not only structs and objects. Types such as char[100_000]* also pose a risk.

-- 
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=5176



--- Comment #6 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-03-18 10:03:05 PDT ---
One possibility is to allow arbitrary sizes but have the compiler insert checks for all field accesses through pointer or reference when the field offset is beyond the OS's protected area.

-- 
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=5176


klickverbot <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at


--- Comment #7 from klickverbot <code@klickverbot.at> 2012-03-18 10:07:28 PDT ---
In reply to comment #5)
> I think on OS X the size of that guaranty is significantly smaller, 4 Kb if I remember well. Is it reasonable to limit structs and objects to 4 Kb on OS X?

Wouldn't it also be possible to additionally protect memory up to the desired @safe object size limit during application startup?

-- 
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=5176


deadalnix <deadalnix@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deadalnix@gmail.com


--- Comment #8 from deadalnix <deadalnix@gmail.com> 2012-03-18 10:14:04 PDT ---
What about int[1000000]* ? The problem is the same.

-- 
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=5176



--- Comment #9 from Michel Fortin <michel.fortin@michelf.com> 2012-03-20 07:14:52 EDT ---
(In reply to comment #7)
> Wouldn't it also be possible to additionally protect memory up to the desired @safe object size limit during application startup?

That'll work only if those pages are not used for anything. My guess is that if they're readable (writable?) it's because they're being used in some way, possibly by some system APIs.

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