DMD 2.055 seems to be crashing on my computer (Windows 7 x64).

When I press Debug, I see it's doing so in CloseHandle, probably because I've turned on "Enable close exception" with Visual Studio's "Global Flags" tool. (It takes a reboot to take effect.)

So this means there's an incorrect handle being used somewhere... but interestingly, by the time it crashes, the output file is already produced. I don't have the time to make a debug build right now, but I thought I'd mention this so that it could be looked into at some point.

On 9/26/2011 7:55 AM, Mehrdad wrote:
> DMD 2.055 seems to be crashing on my computer (Windows 7 x64).
>
> When I press Debug, I see it's doing so in CloseHandle, probably because I've turned on "Enable close exception" with Visual Studio's "Global Flags" tool. (It takes a reboot to take effect.)
>
> So this means there's an incorrect handle being used somewhere... but interestingly, by the time it crashes, the output file is already produced. I don't have the time to make a debug build right now, but I thought I'd mention this so that it could be looked into at some point.
Actually, I just found out that the program itself crashes the same way, too.

Is there a bug in snn.lib or something?

On 9/26/2011 8:06 AM, Mehrdad wrote:
> Actually, I just found out that the program itself crashes the same way, too.

What program?

On Mon, 26 Sep 2011 15:05:44 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/26/2011 8:06 AM, Mehrdad wrote:
>> Actually, I just found out that the program itself crashes the same way, too.
>
> What program?

I think he means both dmd and the program it generates crash in the same way.

-Steve

On 9/26/2011 12:19 PM, Steven Schveighoffer wrote:
> On Mon, 26 Sep 2011 15:05:44 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 9/26/2011 8:06 AM, Mehrdad wrote:
>>> Actually, I just found out that the program itself crashes the same way, too.
>>
>> What program?
>
> I think he means both dmd and the program it generates crash in the same way.
>
> -Steve
Right; what Steve said. The program is empty.

It seems to be failing in the _close() method, but ONLY when I run it from my text editor, SciTE. It runs fine from the command prompt.

I don't believe it's a problem with the text editor (since it's just a pipe, and since it works fine with other languages) but I'll keep looking. Does anyone happen to know if there's a stray _close() method in snn.lib that closes a handle that might be already closed?

On Mon, 26 Sep 2011 16:38:10 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> On 9/26/2011 12:19 PM, Steven Schveighoffer wrote:
>> On Mon, 26 Sep 2011 15:05:44 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>> On 9/26/2011 8:06 AM, Mehrdad wrote:
>>>> Actually, I just found out that the program itself crashes the same way, too.
>>>
>>> What program?
>>
>> I think he means both dmd and the program it generates crash in the same way.
>>
>> -Steve
> Right; what Steve said. The program is empty.
>
> It seems to be failing in the _close() method, but ONLY when I run it from my text editor, SciTE. It runs fine from the command prompt.
>
> I don't believe it's a problem with the text editor (since it's just a pipe, and since it works fine with other languages) but I'll keep looking. Does anyone happen to know if there's a stray _close() method in snn.lib that closes a handle that might be already closed?

AHA!

Yes, there is a bug in snn.lib regarding pipes.  And I fixed it, waiting for Walter to incorporate it :)  I needed it for the new std.process.

What it comes down to is, DMC's FILE * implementation does not expect some of the quirks of pipe HANDLEs.  For instance, if you open a FILE * around a pipe handle, it still tries to do a seek on that handle, and crashes.  Also, when the write end of a pipe is closed, reading from the read end results in EPIPE from ReadFile, but this is translated to EBADF by the runtime.  Therefore, FILE * sets an error instead of EOF.

Is the email address you have for this message correct?  If so, I can send you a new version of snn.lib to try linking your code against (if you are willing to go through these steps), to see if it fixes your problem.

Using the command line dmd to build should be sufficient (I think).

-Steve

On 9/26/2011 1:51 PM, Steven Schveighoffer wrote:
> AHA!
Holy cow what happened XD

> Yes, there is a bug in snn.lib regarding pipes.  And I fixed it, waiting for Walter to incorporate it :)  I needed it for the new std.process.
yay!

> What it comes down to is, DMC's FILE * implementation does not expect some of the quirks of pipe HANDLEs.  For instance, if you open a FILE * around a pipe handle, it still tries to do a seek on that handle, and crashes.  Also, when the write end of a pipe is closed, reading from the read end results in EPIPE from ReadFile, but this is translated to EBADF by the runtime.  Therefore, FILE * sets an error instead of EOF.
>
> Is the email address you have for this message correct?  If so, I can send you a new version of snn.lib to try linking your code against (if you are willing to go through these steps), to see if it fixes your problem.
>
> Using the command line dmd to build should be sufficient (I think).
>
> -Steve

Yup, feel free to send it to this one. It's not my main one but I do check it so I'll get it. :)
Thanks!

On 9/26/2011 1:51 PM, Steven Schveighoffer wrote:
> AHA!
>
> Yes, there is a bug in snn.lib regarding pipes.  And I fixed it, waiting for Walter to incorporate it :)  I needed it for the new std.process.
>
> What it comes down to is, DMC's FILE * implementation does not expect some of the quirks of pipe HANDLEs.  For instance, if you open a FILE * around a pipe handle, it still tries to do a seek on that handle, and crashes.  Also, when the write end of a pipe is closed, reading from the read end results in EPIPE from ReadFile, but this is translated to EBADF by the runtime.  Therefore, FILE * sets an error instead of EOF.
>
> Is the email address you have for this message correct?  If so, I can send you a new version of snn.lib to try linking your code against (if you are willing to go through these steps), to see if it fixes your problem.
>
> Using the command line dmd to build should be sufficient (I think).
>
> -Steve
Thanks for the email.

It seems like it still crashes from SciTE, though. :(
When I try debugging, I see it's doing so inside _close() which is /immediately/ above kernel32.dll!@BaseThreadInitThunk@12()  -- in other words, it seems to be called directly from the entrypoint of the program, assuming it hasn't undergone optimizations. The error is: 0xC0000008: An invalid handle was specified.

Is there any other place in which this can happen?

On 9/26/2011 2:30 PM, Mehrdad wrote:
> On 9/26/2011 1:51 PM, Steven Schveighoffer wrote:
>> AHA!
>>
>> Yes, there is a bug in snn.lib regarding pipes.  And I fixed it, waiting for Walter to incorporate it :)  I needed it for the new std.process.
>>
>> What it comes down to is, DMC's FILE * implementation does not expect some of the quirks of pipe HANDLEs.  For instance, if you open a FILE * around a pipe handle, it still tries to do a seek on that handle, and crashes.  Also, when the write end of a pipe is closed, reading from the read end results in EPIPE from ReadFile, but this is translated to EBADF by the runtime.  Therefore, FILE * sets an error instead of EOF.
>>
>> Is the email address you have for this message correct?  If so, I can send you a new version of snn.lib to try linking your code against (if you are willing to go through these steps), to see if it fixes your problem.
>>
>> Using the command line dmd to build should be sufficient (I think).
>>
>> -Steve
> Thanks for the email.
>
> It seems like it still crashes from SciTE, though. :(
> When I try debugging, I see it's doing so inside _close() which is /immediately/ above kernel32.dll!@BaseThreadInitThunk@12()  -- in other words, it seems to be called directly from the entrypoint of the program, assuming it hasn't undergone optimizations. The error is: 0xC0000008: An invalid handle was specified.
>
> Is there any other place in which this can happen?
Also, now that we're on the topic... this might or might not sound silly, but why not just use msvcrt.dll (if not the whole library, at least the I/O functions)? It's not like it introduces a new dependency (it's already in every version of Windows) and it's also proven to work. Not to mention that it reduces code size as well...

On Mon, 26 Sep 2011 17:30:42 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> On 9/26/2011 1:51 PM, Steven Schveighoffer wrote:
>> AHA!
>>
>> Yes, there is a bug in snn.lib regarding pipes.  And I fixed it, waiting for Walter to incorporate it :)  I needed it for the new std.process.
>>
>> What it comes down to is, DMC's FILE * implementation does not expect some of the quirks of pipe HANDLEs.  For instance, if you open a FILE * around a pipe handle, it still tries to do a seek on that handle, and crashes.  Also, when the write end of a pipe is closed, reading from the read end results in EPIPE from ReadFile, but this is translated to EBADF by the runtime.  Therefore, FILE * sets an error instead of EOF.
>>
>> Is the email address you have for this message correct?  If so, I can send you a new version of snn.lib to try linking your code against (if you are willing to go through these steps), to see if it fixes your problem.
>>
>> Using the command line dmd to build should be sufficient (I think).
>>
>> -Steve
> Thanks for the email.
>
> It seems like it still crashes from SciTE, though. :(
> When I try debugging, I see it's doing so inside _close() which is /immediately/ above kernel32.dll!@BaseThreadInitThunk@12()  -- in other words, it seems to be called directly from the entrypoint of the program, assuming it hasn't undergone optimizations. The error is: 0xC0000008: An invalid handle was specified.
>
> Is there any other place in which this can happen?

Hm... its hard for me to say.  Why would it be calling _close before main() is called?  Very strange.  Is there any more stack information?

Can you get it to crash by using a pipe from the command line?

In other words:

myprogram | more

or echo hi | miprogram

?

If this isn't killing the program in the same way, then it might be a different issue than the one I fixed.

-Steve