Thread overview
[Issue 19947] OutOfMemoryError with GC-allocs
Jun 07, 2019
OlegZ
Jun 07, 2019
anonymous4
Jun 07, 2019
KnightMare
Jun 08, 2019
Gregor Mückl
Jun 09, 2019
ZombineDev
Jun 12, 2019
Rainer Schuetze
Jun 21, 2019
Gregor Mückl
Jun 21, 2019
Rainer Schuetze
Dec 17, 2022
Iain Buclaw
June 07, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

--- Comment #1 from OlegZ <black80@bk.ru> ---
Windows Server 2019 (x64)
DMD 2.086.0
LDC 1.16.0-beta2

--
June 07, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=15723

--- Comment #2 from anonymous4 <dfj1esp02@sneakemail.com> ---
It can be false positive, see issue 15723

--
June 07, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

--- Comment #3 from KnightMare <black80@bk.ru> ---
maybe u right.
imo gc shouldnt scan all data segment for pointers:
when we assign to some globals some pointers or explicitly called
GC.addRange/addRoot. and when I transfer something to C(or others)-libs.. well,
its my responsibility only, not compiler or GC

--
June 08, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

Gregor Mückl <gregormueckl@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gregormueckl@gmx.de

--- Comment #4 from Gregor Mückl <gregormueckl@gmx.de> ---
I don't think that it can be false positives. Adding a GC.collect() call will clean up the allocations; so the issue must rather be that collection is not started for some reason.

See also original forum discussion: https://forum.dlang.org/thread/obkpctudtnnfojrbrwiv@forum.dlang.org

--
June 09, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--
June 12, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #5 from Rainer Schuetze <r.sagitario@gmx.de> ---
To avoid false pointers in the heap and the data segment, use --DRT-gcopt=gc:precise --DRT-scanDataSeg=precise

With these the program runs to completion.

--
June 21, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

--- Comment #6 from Gregor Mückl <gregormueckl@gmx.de> ---
(In reply to Rainer Schuetze from comment #5)
> To avoid false pointers in the heap and the data segment, use --DRT-gcopt=gc:precise --DRT-scanDataSeg=precise
> 
> With these the program runs to completion.

How does this square with the fact that calling GC.collect() inside the for loop also makes the program run to completion? Also, the array is initialized with 0, so any false false pointers would be invisible to the user code.

--
June 21, 2019
https://issues.dlang.org/show_bug.cgi?id=19947

--- Comment #7 from Rainer Schuetze <r.sagitario@gmx.de> ---
> How does this square with the fact that calling GC.collect() inside the for loop also makes the program run to completion?

When running GC.collect() after the allocation, you are changing the amount of memory that the GC overallocates before running the next collection (2 times the live memory at the time of the previous collection). This changes the probability of getting false pointers.

> Also, the array is initialized with 0, so any false false pointers would be invisible to the user code.

The content of the int[] array is not scanned, the false pointers in the data segment (and the stack, -gx might help) are the issue here. These can pin the large allocations. Address randomization (ASLR) makes it rather unpredictable, too.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=19947

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--