>
> I have installed 2.089 back to check. And in the previous version there is no such error.

I have tried to debug. And looks like this error occurred during throwing exception inside std.exception: enforce.

Seems that I managed to slightly reduce the problemme. I suspect that error is somehow connected with running my code inside TaskPool:
https://dlang.org/library/std/parallelism/task_pool.html

`Memory allocation failed` error occurs when I throw any exception even trivial one:
throw new Exception(`Test`)

I have 3 modes of my small web server:
1. The main mode uses TaskPool to create fixed pool of working threads.
2. The second mode just creates new thread for every connection using class inherited from: import core.thread: Thread;
3. And the third variation is most stupid. It handles all requests in single thread.

The second and third variant working normally. But the first generates memory allocation error when I throw Exception inside of it. There was no such error before 2.090. I have tried forcibly recompile the same version of my code with 2.089 and 2.090. And version compiled with 2.089 doesn't have this issue.

Do anybody knows what could be changed or what else to try?

On 2/25/20 2:40 PM, uranuz wrote:
> Seems that I managed to slightly reduce the problemme. I suspect that error is somehow connected with running my code inside TaskPool:
> https://dlang.org/library/std/parallelism/task_pool.html
> 
> `Memory allocation failed` error occurs when I throw any exception even trivial one:
> throw new Exception(`Test`)
> 
> I have 3 modes of my small web server:
> 1. The main mode uses TaskPool to create fixed pool of working threads.
> 2. The second mode just creates new thread for every connection using class inherited from: import core.thread: Thread;
> 3. And the third variation is most stupid. It handles all requests in single thread.
> 
> The second and third variant working normally. But the first generates memory allocation error when I throw Exception inside of it. There was no such error before 2.090. I have tried forcibly recompile the same version of my code with 2.089 and 2.090. And version compiled with 2.089 doesn't have this issue.
> 
> Do anybody knows what could be changed or what else to try?

Have you tried valgrind or similar tools? Memory errors are the worst.

"Memory allocation failed" seems to suggest however that you are out of memory.

But with memory errors - it's quite possible the problem is still in 2.089, but some small change causes the memory issue to come out.

-Steve

I believe that problemme is somehow connected with core.runtime.DefaultTraceInfo.
I figured out that it fail inside a function that tries to get trace info for exception. Body is pretty simple. I created the case where `ex` is just an instance of standart Exception class in order to eliminate some side effects or errors that could be introduced by my code.

auto errorToJSON(Throwable ex)
{
	import std.json: JSONValue;
	import std.conv: to;

	string[] backTrace;
        // Commenting this loop removes memory error
	foreach( inf; ex.info )
		backTrace ~= inf.to!string; // Debug point is there

	JSONValue jErr = [
		"code": JSONValue(1),
		"message": JSONValue(ex.msg),
		"data": JSONValue([
			"file": JSONValue(ex.file),
			"line": JSONValue(ex.line),
			"backtrace": JSONValue(backTrace)
		])
	];

	return jErr;
}

I just tried to debug this code. And put debug point there (where it is commented). And programme fails after several iterations in this loop. There is call stack at this break point:

webtank.net.utils.errorToJSON(object.Throwable).__foreachbody2(ref const(char[]))@0x0000555555d35317 (/home/uranuz/sources/webtank/src/webtank/net/utils.d:112)
_D4core7runtime16DefaultTraceInfo7opApplyMxFMDFKxAaZiZ__T9__lambda2TmZQnMFKmKxQBdZi@0x0000555555e1a4ac (Unknown Source:0)
rt.backtrace.dwarf.traceHandlerOpApplyImpl(const(void*[]), scope int(ref ulong, ref const(char[])) delegate)@0x0000555555e1c65c (Unknown Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref ulong, ref const(char[])) delegate) const@0x0000555555e1a501 (Unknown Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref const(char[])) delegate) const@0x0000555555e1a47e (Unknown Source:0)
webtank.net.utils.errorToJSON(object.Throwable)@0x0000555555d34fa6 (/home/uranuz/sources/webtank/src/webtank/net/utils.d:111)
_D7webtank3net6server6common17makeErrorResponseFC6object9ThrowableCQCnQCi4http6output10HTTPOutputZv@0x0000555555d349bb (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:50)
_D7webtank3net6server6common14processRequestFC3std6socket6SocketCQClQCgQCf5iface10IWebServerZv@0x0000555555d16f96 (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:113)
_D3std11parallelism__T3runTPFCQBc6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEiFQEhKQEjKQCcZv@0x0000555555cc27cf (/usr/include/dmd/phobos/std/parallelism.d:761)
_D3std11parallelism__T4TaskSQBaQz3runTPFCQBn6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEt4implFPvZv@0x0000555555cc2171 (/usr/include/dmd/phobos/std/parallelism.d:444)
std.parallelism.AbstractTask.job()@0x0000555555dbb423 (Unknown Source:0)
_D3std11parallelism8TaskPool5doJobMFPSQBkQBj12AbstractTaskZv@0x0000555555dbb574 (Unknown Source:0)
std.parallelism.TaskPool.executeWorkLoop()@0x0000555555dbb6ea (Unknown Source:0)
std.parallelism.TaskPool.startWorkLoop()@0x0000555555dbb690 (Unknown Source:0)
core.thread.osthread.Thread.run()@0x0000555555da74de (Unknown Source:0)
thread_entryPoint@0x0000555555de9016 (Unknown Source:0)
start_thread@0x00007ffff72176db (/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
clone@0x00007ffff657e88f (/build/glibc-OTsEL5/glibc-2.27/sysdeps/unix/sysv/linux/x86_64/clone.S:95)

So I believe that bug is somewhere around there. Because there are some fixed size buffers in code. And have some template code, so symbol names could be greather in size that this buffers. And this case could be not handled good enough.

What dou you think about it? I shall try to create some representative example of smaller size to fill a bug report.

I have just added workaround of this bug in by code. And now it is working and returns backtrace

string[] getBacktrace(Throwable ex)
{
	import std.conv: to;
	import core.exception: OutOfMemoryError;

	string[] backTrace;
	try {
		foreach( inf; ex.info )
			backTrace ~= inf.to!string;
	} catch( OutOfMemoryError exc ) {} // Workaround for some bug in DefaultTraceInfo.opApply
	return backTrace;
}

auto errorToJSON(Throwable ex)
{
	import std.json: JSONValue;

	return JSONValue([
		"code": JSONValue(1),
		"message": JSONValue(ex.msg),
		"data": JSONValue([
			"file": JSONValue(ex.file),
			"line": JSONValue(ex.line),
			"backtrace": JSONValue(getBacktrace(ex))
		])
	]);
}