https://issues.dlang.org/show_bug.cgi?id=16641

Etienne <etcimon@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
           Hardware|x86                         |x86_64
                 OS|Windows                     |Linux
           Severity|enhancement                 |major

--

https://issues.dlang.org/show_bug.cgi?id=16641

ag0aep6g@gmail.com changed:

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

--

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #1 from ag0aep6g@gmail.com ---
Do you have code to reproduce this? InvalidMemoryOperationError is usually thrown when a destructor tries to allocate GC memory during a collection. The current GC can't do that. So problem might be in your code or in vibe.d instead of druntime.

--

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #2 from Etienne <etcimon@gmail.com> ---
(In reply to ag0aep6g from comment #1)
> Do you have code to reproduce this? InvalidMemoryOperationError is usually thrown when a destructor tries to allocate GC memory during a collection. The current GC can't do that. So problem might be in your code or in vibe.d instead of druntime.

Unfortunately the stack trace cycles into itself so I can't pinpoint the problem, but it always happens here:

https://github.com/etcimon/vibe.0/blob/master/source/vibe/stream/botan.d#L147

The issue here happens very very rarely, it's probably a very complex set of circumstances, but the fact here is that I didn't voluntarily create a cycle in the stack trace linked list and the problem is amplified by this function in druntime lacking proper cycle detection.

--

https://issues.dlang.org/show_bug.cgi?id=16641

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |EH
                 CC|                            |code@dawg.eu

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
We got a similar report for dub-registry (not using botan I assume).

--

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #4 from Etienne <etcimon@gmail.com> ---
I still get this infinite loop problem every now and then. I got around it by auto-launching more processes and killing them every hour, it seems like it happens when my (very busy) application starts to throw more frequently. It became 99% less frequent after putting a loop counter in this code

        auto eh = ExceptionHeader.toExceptionHeader(exceptionObject);
        int infini_guard;
        while (eh.next && ++infini_guard < 10000)
        {
            ExceptionHeader* ehn = eh.next;

--

https://issues.dlang.org/show_bug.cgi?id=16641

--- Comment #5 from anonymous4 <dfj1esp02@sneakemail.com> ---
It tries to throw exception from processException method? You have InvalidMemoryOperationError stored in m_ex field?

--

https://issues.dlang.org/show_bug.cgi?id=16641

Nemanja Boric <4burgos@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |4burgos@gmail.com

--- Comment #6 from Nemanja Boric <4burgos@gmail.com> ---
I've experienced issue similar to this while working on: https://github.com/dlang/druntime/pull/1872

The trick is that chaining exceptions doesn't work with `InvalidMemoryOperationError` or similar errors that are statically allocated. So, if you're executing your `close()` during stack unwinding due to `AssertError`, say, (like in `scope(exit)`) and that method throws another Error (invalid GC operation), that will reuse the same statically allocated memory, chaining `ThrowableInstance.next = &ThrowableInstance`, which will cause infinite loop in the exception handling.

--

https://issues.dlang.org/show_bug.cgi?id=16641

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--

https://issues.dlang.org/show_bug.cgi?id=16641

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #7 from Dlang Bot <dlang-bot@dlang.rocks> ---
@schveiguy updated dlang/dmd pull request #14710 "Remove GC for allocating traceinfo" fixing this issue:

- Remove GC for allocating traceinfo. Allow traces for
  InvalidMemoryOperationError and other sensitive errors.
  Fixes 20650,16641,22616.

https://github.com/dlang/dmd/pull/14710

--