Difference between revisions of "InvalidMemoryOperationError"
m |
|||
(5 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | An <tt>InvalidMemoryOperationError</tt> can occur when an allocation occurs during the execution of the garbage collector. This can happen when the garbage collector runs, finds an unreferenced class instance, calls its finalizer (class destructor, <tt>~this</tt>), which in turn does something which attempts to allocate memory. Since the current implementation of the D garbage collector is not re-entrant, this causes a fatal error. | + | An <tt>InvalidMemoryOperationError</tt> can occur when a memory operation (usually an allocation) occurs during the execution of the garbage collector. This can happen when the garbage collector runs, finds an unreferenced class instance, calls its finalizer (class destructor, <tt>~this</tt>), which in turn does something which attempts to allocate memory. Since the current implementation of the D garbage collector is not re-entrant, this causes a fatal error. |
<tt>InvalidMemoryOperationError</tt> problems are difficult to debug because they do not print a stack trace (since that also requires a memory allocation), and may not occur reliably. This page describes how to find the cause of these errors. | <tt>InvalidMemoryOperationError</tt> problems are difficult to debug because they do not print a stack trace (since that also requires a memory allocation), and may not occur reliably. This page describes how to find the cause of these errors. | ||
Line 25: | Line 25: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
+ | |||
+ | When run, this program will crash with the following output: | ||
+ | |||
+ | core.exception.InvalidMemoryOperationError@(0) | ||
+ | core.exception.InvalidMemoryOperationError@(0) | ||
== Debugging == | == Debugging == | ||
− | First, you will need to build Druntime with debug information (<tt>-g</tt>) and stack frames (<tt>-gs</tt>) enabled. Without stack frames in Druntime, you will not be able to get a reliable stack trace. D version 2.067 or newer is also required, as in older versions the <tt>onInvalidMemoryOperationError</tt> function is [https://issues.dlang.org/show_bug.cgi?id=13725 inlined], thus making it impossible to breakpoint. | + | First, you will need to build Druntime with debug information (<tt>-g</tt>) and stack frames (<tt>-gs</tt>) enabled. Without stack frames in Druntime, [https://issues.dlang.org/show_bug.cgi?id=13726 you will not be able to get a reliable stack trace]. D version 2.067 or newer is also required, as in older versions the <tt>onInvalidMemoryOperationError</tt> function is [https://issues.dlang.org/show_bug.cgi?id=13725 inlined], thus making it impossible to breakpoint. |
The easiest way to do this is is to use [https://github.com/CyberShadow/Digger Digger]: | The easiest way to do this is is to use [https://github.com/CyberShadow/Digger Digger]: | ||
Line 43: | Line 48: | ||
# Start Visual Studio, go to <b>File</b> → <b>Open</b> → <b>Project/Solution...</b>, and select your compiled <b>.exe</b> file. | # Start Visual Studio, go to <b>File</b> → <b>Open</b> → <b>Project/Solution...</b>, and select your compiled <b>.exe</b> file. | ||
− | |||
# Press <b>Ctrl+B</b> to open the <b>New Breakpoint</b> dialog. In the <b>Function</b> field, type <tt>_onInvalidMemoryOperationError</tt>. Click <b>OK</b>. | # Press <b>Ctrl+B</b> to open the <b>New Breakpoint</b> dialog. In the <b>Function</b> field, type <tt>_onInvalidMemoryOperationError</tt>. Click <b>OK</b>. | ||
− | # Click <b> | + | # Click <b>Start</b> to start your program. |
Your program should now break at the <tt>_onInvalidMemoryOperationError</tt> function. | Your program should now break at the <tt>_onInvalidMemoryOperationError</tt> function. | ||
Line 91: | Line 95: | ||
Type "apropos word" to search for commands related to "word"... | Type "apropos word" to search for commands related to "word"... | ||
Reading symbols from ./program...done. | Reading symbols from ./program...done. | ||
− | (gdb) <b> | + | (gdb) <b>break onInvalidMemoryOperationError</b> |
− | + | Breakpoint 1 at 0x415d20: file src/core/exception.d, line 536. | |
− | Starting program: /home/ | + | (gdb) <b>run</b> |
+ | Starting program: /home/vladimir/tmp/2015-01-25/test | ||
[Thread debugging using libthread_db enabled] | [Thread debugging using libthread_db enabled] | ||
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". | Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". | ||
− | + | Breakpoint 1, onInvalidMemoryOperationError (pretend_sideffect=0x40e591 <gc.gc.Gcx.mark()+185>) | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
at src/core/exception.d:536 | at src/core/exception.d:536 | ||
536 cast(void*) typeid(InvalidMemoryOperationError).init; | 536 cast(void*) typeid(InvalidMemoryOperationError).init; | ||
− | (gdb) where | + | (gdb) <b>where</b> |
#0 onInvalidMemoryOperationError (...) at src/core/exception.d:536 | #0 onInvalidMemoryOperationError (...) at src/core/exception.d:536 | ||
#1 0x000000000040b0c2 in gc.gc.GC.malloc() (...) at src/gc/gc.d:469 | #1 0x000000000040b0c2 in gc.gc.GC.malloc() (...) at src/gc/gc.d:469 |
Latest revision as of 12:05, 25 January 2015
An InvalidMemoryOperationError can occur when a memory operation (usually an allocation) occurs during the execution of the garbage collector. This can happen when the garbage collector runs, finds an unreferenced class instance, calls its finalizer (class destructor, ~this), which in turn does something which attempts to allocate memory. Since the current implementation of the D garbage collector is not re-entrant, this causes a fatal error.
InvalidMemoryOperationError problems are difficult to debug because they do not print a stack trace (since that also requires a memory allocation), and may not occur reliably. This page describes how to find the cause of these errors.
Example test case
A simple program which will throw an InvalidMemoryOperationError:
class C
{
~this()
{
new ubyte[1024];
}
}
void main()
{
foreach (n; 0..100)
new C;
import core.memory;
GC.collect();
}
When run, this program will crash with the following output:
core.exception.InvalidMemoryOperationError@(0) core.exception.InvalidMemoryOperationError@(0)
Debugging
First, you will need to build Druntime with debug information (-g) and stack frames (-gs) enabled. Without stack frames in Druntime, you will not be able to get a reliable stack trace. D version 2.067 or newer is also required, as in older versions the onInvalidMemoryOperationError function is inlined, thus making it impossible to breakpoint.
The easiest way to do this is is to use Digger:
digger build master+CyberShadow/druntime/debug+CyberShadow/phobos/debug
This will build the latest version of D from GitHub, and pull in two branches from my fork with the necessary Makefile changes.
Once you got your project to build with the latest compiler version, see if the error still occurs - it might have been resolved by a change in D. Otherwise, build your program with -g (and -gs if you have to use -release), and continue to the section corresponding to your platform.
Windows
The easiest way to debug this problem on Windows is to use Visual Studio's debugger.
- Start Visual Studio, go to File → Open → Project/Solution..., and select your compiled .exe file.
- Press Ctrl+B to open the New Breakpoint dialog. In the Function field, type _onInvalidMemoryOperationError. Click OK.
- Click Start to start your program.
Your program should now break at the _onInvalidMemoryOperationError function.
Open the stack trace view. It might look like this:
> test.exe!core.exception.onInvalidMemoryOperationError(...) Line 531 test.exe!gc.gc.GC.malloc(...) Line 471 test.exe!gc.proxy.gc_qalloc(...) Line 217 + 0x14 bytes test.exe!rt.lifetime.__arrayAlloc(...) Line 440 + 0x10 bytes test.exe!rt.lifetime._d_newarrayU(...) Line 940 test.exe!rt.lifetime._d_newarrayT(...) Line 957 + 0x9 bytes test.exe!test.C.~this() Line 5 + 0x10 bytes test.exe!rt.lifetime.rt_finalize2(...) Line 1403 test.exe!rt.lifetime.rt_finalizeFromGC(...) Line 1434 + 0xa bytes test.exe!gc.gc.Gcx.sweep() Line 2616 + 0x15 bytes test.exe!gc.gc.Gcx.fullcollect() Line 2532 + 0x7 bytes test.exe!gc.gc.GC.fullCollect() Line 1177 + 0xb bytes test.exe!gc.proxy.gc_collect() Line 171 + 0xa bytes test.exe!core.memory.GC.collect() Line 170 test.exe!D main() Line 15 + 0x5 bytes ...
Note the bolded line: it indicates the cause of our problem, the allocation inside our destructor.
Linux
On Linux, you can use gdb to breakpoint onInvalidMemoryOperationError:
$ dmd -g program $ gdb ./program GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./program...done. (gdb) break onInvalidMemoryOperationError Breakpoint 1 at 0x415d20: file src/core/exception.d, line 536. (gdb) run Starting program: /home/vladimir/tmp/2015-01-25/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, onInvalidMemoryOperationError (pretend_sideffect=0x40e591 <gc.gc.Gcx.mark()+185>) at src/core/exception.d:536 536 cast(void*) typeid(InvalidMemoryOperationError).init; (gdb) where #0 onInvalidMemoryOperationError (...) at src/core/exception.d:536 #1 0x000000000040b0c2 in gc.gc.GC.malloc() (...) at src/gc/gc.d:469 #2 0x0000000000402f34 in gc_qalloc (...) at src/gc/proxy.d:217 #3 0x0000000000407552 in rt.lifetime.__arrayAlloc() (...) at src/core/memory.d:366 #4 0x00000000004076c5 in _d_newarrayU (...) at src/rt/lifetime.d:939 #5 0x0000000000403ddd in _d_newarrayT (...) at src/rt/lifetime.d:957 #6 0x0000000000401d15 in program.C.__dtor() (...) at program.d:5 #7 0x00000000004192d0 in rt_finalize2 (...) at src/rt/lifetime.d:1400 #8 0x000000000041129a in rt_finalizeFromGC (...) at src/rt/lifetime.d:1434 #9 0x000000000040f002 in gc.gc.Gcx.sweep() (...) at src/gc/gc.d:2390 #10 0x000000000040f6bf in gc.gc.Gcx.fullcollect() (...) at src/gc/gc.d:2532 #11 0x000000000040c453 in gc.gc.GC.fullCollect() (...) at src/gc/gc.d:1177 #12 0x0000000000402db7 in gc_collect () at src/gc/proxy.d:171 #13 0x0000000000402a59 in core.memory.GC.collect() () at src/core/memory.d:169 #14 0x0000000000401d55 in D main () at program.d:15 ...
As above, the bolded line (between rt_finalize2 and _d_newarrayT) indicates the problem.