digitalmars.D.learn - writeln() assertion failed in hybrid x64
- Szymon Gatner (41/41) Sep 03 2014 Hey,
- Szymon Gatner (3/44) Sep 03 2014 Any ideas why this happens?
- Jorge A. S. (22/80) Sep 04 2014 I'm having an error related to yours: when I call writeln
- ketmar via Digitalmars-d-learn (4/9) Sep 04 2014 On Thu, 04 Sep 2014 15:10:21 +0000
- Szymon Gatner (3/12) Sep 04 2014 Shouldn't writeln() work tho instead of throwing or segfaulting?
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/17) Sep 04 2014 No, if stdout is closed, how should it work? Throwing is the
- Szymon Gatner (3/23) Sep 04 2014 Ah sorry, I totaly missed close() part.
- Kagamin (2/2) Sep 04 2014 Maybe some module constructor wasn't run due to linking mess. So
- Szymon Gatner (3/5) Sep 04 2014 Is there a way I can check if module c-tor run? rt_init()
- Kagamin (2/2) Sep 04 2014 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dm...
- Szymon Gatner (4/6) Sep 05 2014 Is there a way I can call module c-tors explicitly?
- Kagamin (3/3) Sep 05 2014 It's not a module ctor, this code is executed much earlier. You
- Kagamin (2/2) Sep 04 2014 https://github.com/D-Programming-Language/druntime/blob/master/src/core/...
- hane (3/23) Sep 05 2014 With DMD of git master, the latter code seems to raise Exception
- hane (2/34) Sep 05 2014 Oops, I meant 'former' of course.
Hey, I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage: D definition: extern (C++) void printSomething() { writeln("hello from D"); } usage from C++: extern "C++" void printSomething(); int main() { DRuntime druntime; // rt_init(), rt_term() printSomething(); } this causes run-time assertion in fprintf() called from within writeln(): int __cdecl fprintf ( FILE *str, const char *format, ... ) /* * 'F'ile (stream) 'PRINT', 'F'ormatted */ { va_list(arglist); FILE *stream; int buffing; int retval=0; _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here [...] } meaning that str arg passed is null. writelns()'s call site: enforce(fprintf(.stdout._p.handle, "%.*s\n", cast(int) args[0].length, args[0].ptr) >= 0); so for some reason .stdout._p.handle is null.
Sep 03 2014
On Wednesday, 3 September 2014 at 09:55:55 UTC, Szymon Gatner wrote:Hey, I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage: D definition: extern (C++) void printSomething() { writeln("hello from D"); } usage from C++: extern "C++" void printSomething(); int main() { DRuntime druntime; // rt_init(), rt_term() printSomething(); } this causes run-time assertion in fprintf() called from within writeln(): int __cdecl fprintf ( FILE *str, const char *format, ... ) /* * 'F'ile (stream) 'PRINT', 'F'ormatted */ { va_list(arglist); FILE *stream; int buffing; int retval=0; _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here [...] } meaning that str arg passed is null. writelns()'s call site: enforce(fprintf(.stdout._p.handle, "%.*s\n", cast(int) args[0].length, args[0].ptr)Any ideas why this happens?= 0);so for some reason .stdout._p.handle is null.
Sep 03 2014
I'm having an error related to yours: when I call writeln function in a closed stdout I will get a segfault message. Example: import std.stdio; void main() { stdout.close(); write("hello\n"); } The code above will crash with segfault buf the following code will raise an exception instead: import std.stdio; void main() { stdout.close(); stdout.write("hello\n"); } In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here). On Wednesday, 3 September 2014 at 18:48:00 UTC, Szymon Gatner wrote:On Wednesday, 3 September 2014 at 09:55:55 UTC, Szymon Gatner wrote:Hey, I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage: D definition: extern (C++) void printSomething() { writeln("hello from D"); } usage from C++: extern "C++" void printSomething(); int main() { DRuntime druntime; // rt_init(), rt_term() printSomething(); } this causes run-time assertion in fprintf() called from within writeln(): int __cdecl fprintf ( FILE *str, const char *format, ... ) /* * 'F'ile (stream) 'PRINT', 'F'ormatted */ { va_list(arglist); FILE *stream; int buffing; int retval=0; _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here [...] } meaning that str arg passed is null. writelns()'s call site: enforce(fprintf(.stdout._p.handle, "%.*s\n", cast(int) args[0].length, args[0].ptr)Any ideas why this happens?= 0);so for some reason .stdout._p.handle is null.
Sep 04 2014
On Thu, 04 Sep 2014 15:10:21 +0000 "Jorge A. S. via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> wrote:In one of the specializations of the write function in the=20 std.stdio (the call site that you showed in your post) no check=20 for closed stdout (when stdout._p is null) is done. I can't say=20 if this is a bug in the write function or the desired behaviour=20 (I'm a novice here).it's definitely a bug. writeln() should throw, not segfaulting.
Sep 04 2014
On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:On Thu, 04 Sep 2014 15:10:21 +0000 "Jorge A. S. via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> wrote:Shouldn't writeln() work tho instead of throwing or segfaulting?In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).it's definitely a bug. writeln() should throw, not segfaulting.
Sep 04 2014
On Thursday, 4 September 2014 at 17:57:47 UTC, Szymon Gatner wrote:On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:No, if stdout is closed, how should it work? Throwing is the correct behaviour.On Thu, 04 Sep 2014 15:10:21 +0000 "Jorge A. S. via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> wrote:Shouldn't writeln() work tho instead of throwing or segfaulting?In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).it's definitely a bug. writeln() should throw, not segfaulting.
Sep 04 2014
On Thursday, 4 September 2014 at 18:22:55 UTC, Marc Schütz wrote:On Thursday, 4 September 2014 at 17:57:47 UTC, Szymon Gatner wrote:Ah sorry, I totaly missed close() part. Any idea why it is null in my case tho?On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:No, if stdout is closed, how should it work? Throwing is the correct behaviour.On Thu, 04 Sep 2014 15:10:21 +0000 "Jorge A. S. via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> wrote:Shouldn't writeln() work tho instead of throwing or segfaulting?In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).it's definitely a bug. writeln() should throw, not segfaulting.
Sep 04 2014
Maybe some module constructor wasn't run due to linking mess. So it remains uninitialized.
Sep 04 2014
On Thursday, 4 September 2014 at 20:38:38 UTC, Kagamin wrote:Maybe some module constructor wasn't run due to linking mess. So it remains uninitialized.Is there a way I can check if module c-tor run? rt_init() returned no error.
Sep 04 2014
https://github.com/D-Programming-Language/druntime/blob/master/ rc/rt/dmain2.d#L270 well, this sucks.
Sep 04 2014
On Thursday, 4 September 2014 at 20:57:41 UTC, Kagamin wrote:https://github.com/D-Programming-Language/druntime/blob/master/ rc/rt/dmain2.d#L270 well, this sucks.Is there a way I can call module c-tors explicitly? I was under impression that D(dmd) was suppose to work with VisualC++ in x64bit mode.
Sep 05 2014
It's not a module ctor, this code is executed much earlier. You can write a function, which will initialize standard streams, and call it from the C code before rt_init.
Sep 05 2014
https://github.com/D-Programming-Language/druntime/blob/master/src/co e/stdc/stdio.d#L457 see? It's null. Hmm... where is it initialized?
Sep 04 2014
On Thursday, 4 September 2014 at 15:10:22 UTC, Jorge A. S. wrote:I'm having an error related to yours: when I call writeln function in a closed stdout I will get a segfault message. Example: import std.stdio; void main() { stdout.close(); write("hello\n"); } The code above will crash with segfault buf the following code will raise an exception instead: import std.stdio; void main() { stdout.close(); stdout.write("hello\n"); } In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).With DMD of git master, the latter code seems to raise Exception (stdio.d(2247): Enforcement failed) instead of segfault.
Sep 05 2014
On Friday, 5 September 2014 at 07:22:23 UTC, hane wrote:On Thursday, 4 September 2014 at 15:10:22 UTC, Jorge A. S. wrote:Oops, I meant 'former' of course.I'm having an error related to yours: when I call writeln function in a closed stdout I will get a segfault message. Example: import std.stdio; void main() { stdout.close(); write("hello\n"); } The code above will crash with segfault buf the following code will raise an exception instead: import std.stdio; void main() { stdout.close(); stdout.write("hello\n"); } In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).With DMD of git master, the latter code seems to raise Exception (stdio.d(2247): Enforcement failed) instead of segfault.
Sep 05 2014