Re: Release D 2.090.0
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))
])
]);
}
Re: Release D 2.090.0
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[]))@0x55d35317
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:112)
_D4core7runtime16DefaultTraceInfo7opApplyMxFMDFKxAaZiZ__T9__lambda2TmZQnMFKmKxQBdZi@0x55e1a4ac
(Unknown Source:0)
rt.backtrace.dwarf.traceHandlerOpApplyImpl(const(void*[]), scope
int(ref ulong, ref const(char[])) delegate)@0x55e1c65c
(Unknown Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref ulong, ref
const(char[])) delegate) const@0x55e1a501 (Unknown
Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref
const(char[])) delegate) const@0x55e1a47e (Unknown
Source:0)
webtank.net.utils.errorToJSON(object.Throwable)@0x55d34fa6
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:111)
_D7webtank3net6server6common17makeErrorResponseFC6object9ThrowableCQCnQCi4http6output10HTTPOutputZv@0x55d349bb
(/home/uranuz/sources/webtank/src/webtank/net/server/common.d:50)
_D7webtank3net6server6common14processRequestFC3std6socket6SocketCQClQCgQCf5iface10IWebServerZv@0x55d16f96
(/home/uranuz/sources/webtank/src/webtank/net/server/common.d:113)
_D3std11parallelism__T3runTPFCQBc6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEiFQEhKQEjKQCcZv@0x55cc27cf
(/usr/include/dmd/phobos/std/parallelism.d:761)
_D3std11parallelism__T4TaskSQBaQz3runTPFCQBn6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEt4implFPvZv@0x55cc2171
(/usr/include/dmd/phobos/std/parallelism.d:444)
std.parallelism.AbstractTask.job()@0x55dbb423 (Unknown
Source:0)
_D3std11parallelism8TaskPool5doJobMFPSQBkQBj12AbstractTaskZv@0x55dbb574
(Unknown Source:0)
std.parallelism.TaskPool.executeWorkLoop()@0x55dbb6ea
(Unknown Source:0)
std.parallelism.TaskPool.startWorkLoop()@0x55dbb690
(Unknown Source:0)
core.thread.osthread.Thread.run()@0x55da74de (Unknown
Source:0)
thread_entryPoint@0x55de9016 (Unknown Source:0)
start_thread@0x772176db
(/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
clone@0x7657e88f
(/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.
Re: Release D 2.090.0
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
Re: Release D 2.090.0
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?
Re: Release D 2.090.0
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.
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin But I got another problemme: Memory allocation failed In module src/core/exception.d:647. Traceback: I have installed 2.089 back to check. And in the previous version there is no such error.
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Now multiple deprecation warnings (about deprecated enum members) caused by passing std.json: JSONType value to `format` are fixed. It looks like that. Thanks for this very much ;-)
Re: Release D 2.090.0
On Wednesday, 8 January 2020 at 21:58:29 UTC, H. S. Teoh wrote: On Wed, Jan 08, 2020 at 09:43:05PM +, Meta via Digitalmars-d-announce wrote: [...] Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental). I think you misunderstood what happened here. Originally std.experimental.all *was* the same thing as today's std/package.d; the only reason it was put in std.experimental was because it was still an experiment to see if importing all of Phobos is actually feasible in practice. Since it apparently worked quite well, it was moved from std/experimental/all.d to std/package.d. Ergo, import std.experimental.all != import std.experimental.*; rather, import std.experimental.all == import std.* in the past, and now we've just made it official by allowing you to write: import std; T Ah, I misunderstood. Thanks.
Re: Release D 2.090.0
On Wednesday, 8 January 2020 at 12:13:50 UTC, Simen Kjærås wrote: Something seems to be wrong with the 2.090.0 Windows installer. After successfully installing, it proceeds to delete every file it has just added. Looking closely at how it happens, it seems that it might actually be caused by the uninstaller deleting itself and the directory it's in. If I wait long after the previous version has been uninstalled before clicking 'next', it doesn't happen. So, how to reproduce: 1) have a previous DMD version installed 2) start the 2.090.0 installer 3) answer yes to uninstalling the previous version 4) quickly finish installing 2.090.0 If you do this with the install folder open in an explorer window, you should see the files disappearing during the uninstall of the previous version, until the only item in the D folder is uninstall.exe. As the new install proceeds more files and folders will be added, and finally they will all be deleted again, sometimes leaving an empty folders, other times a partial installation (I've only once managed to get a partial installation). -- Simen Through three iterations, I couldn't reproduce this problem by following the provided steps. I used checksums of a clean 2.090.0 installation to ensure there was no partial installation after each upgrade. ╮(￣ω￣;)╭
Re: Release D 2.090.0
On Wed, Jan 08, 2020 at 09:43:05PM +, Meta via Digitalmars-d-announce wrote: [...] > Deprecated module std.experimental.all was removed > All symbols contained in Phobos can now be used with import std > > Maybe I'm wrong, but this seems like a bad idea to me (unless we're > getting rid of std.experimental). I think you misunderstood what happened here. Originally std.experimental.all *was* the same thing as today's std/package.d; the only reason it was put in std.experimental was because it was still an experiment to see if importing all of Phobos is actually feasible in practice. Since it apparently worked quite well, it was moved from std/experimental/all.d to std/package.d. Ergo, import std.experimental.all != import std.experimental.*; rather, import std.experimental.all == import std.* in the past, and now we've just made it official by allowing you to write: import std; T -- May you live all the days of your life. -- Jonathan Swift
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental).
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Something seems to be wrong with the 2.090.0 Windows installer. After successfully installing, it proceeds to delete every file it has just added. Looking closely at how it happens, it seems that it might actually be caused by the uninstaller deleting itself and the directory it's in. If I wait long after the previous version has been uninstalled before clicking 'next', it doesn't happen. So, how to reproduce: 1) have a previous DMD version installed 2) start the 2.090.0 installer 3) answer yes to uninstalling the previous version 4) quickly finish installing 2.090.0 If you do this with the install folder open in an explorer window, you should see the files disappearing during the uninstall of the previous version, until the only item in the D folder is uninstall.exe. As the new install proceeds more files and folders will be added, and finally they will all be deleted again, sometimes leaving an empty folders, other times a partial installation (I've only once managed to get a partial installation). -- Simen
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 11:12:09 UTC, JN wrote: Loving the JSON getter :) Did you give jsonwrap[1] a try? [1] https://code.dlang.org/packages/jsonwrap
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Loving the JSON getter :)
Release D 2.090.0
Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin
