writeln() assertion failed in hybrid x64

[Jorge A. S. via Digitalmars-d-learn]

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)
>> >= 0);
>>
>> so for some reason .stdout._p.handle is null.
>
> Any ideas why this happens?