Release D 2.090.0

[uranuz]

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 at 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 at 0x0000555555e1a501 (Unknown 
Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref 
const(char[])) delegate) const at 0x0000555555e1a47e (Unknown 
Source:0)
webtank.net.utils.errorToJSON(object.Throwable)@0x0000555555d34fa6 (/home/uranuz/sources/webtank/src/webtank/net/utils.d:111)
_D7webtank3net6server6common17makeErrorResponseFC6object9ThrowableCQCnQCi4http6output10HTTPOutputZv at 0x0000555555d349bb (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:50)
_D7webtank3net6server6common14processRequestFC3std6socket6SocketCQClQCgQCf5iface10IWebServerZv at 0x0000555555d16f96 (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:113)
_D3std11parallelism__T3runTPFCQBc6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEiFQEhKQEjKQCcZv at 0x0000555555cc27cf (/usr/include/dmd/phobos/std/parallelism.d:761)
_D3std11parallelism__T4TaskSQBaQz3runTPFCQBn6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEt4implFPvZv at 0x0000555555cc2171 (/usr/include/dmd/phobos/std/parallelism.d:444)
std.parallelism.AbstractTask.job()@0x0000555555dbb423 (Unknown 
Source:0)
_D3std11parallelism8TaskPool5doJobMFPSQBkQBj12AbstractTaskZv at 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 at 0x0000555555de9016 (Unknown Source:0)
start_thread at 0x00007ffff72176db 
(/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
clone at 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.