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.
