DMD 2.055 Crashing on Windows 7 x64 (So is my D program)

Jonathan M Davis jmdavisProg at gmx.com
Mon Sep 26 16:24:26 PDT 2011


On Monday, September 26, 2011 16:07 Dmitry Olshansky wrote:
> On 27.09.2011 2:33, Jonathan M Davis wrote:
> > On Monday, September 26, 2011 14:53 Steven Schveighoffer wrote:
> >> On Mon, 26 Sep 2011 17:35:20 -0400, Mehrdad<wfunction at hotmail.com> 
wrote:
> >>> 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 at 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...
> >> 
> >> I think the reason Walter always gives is that dmd would then have to
> >> output COFF objects, whereas it currently outputs OMF. OPTLINK also does
> >> not accept COFF objects.
> >> 
> >> I think a lot of people would very much welcome this change, but it's
> >> somewhat of an underwhelming change. Instead of using DMC's runtime for
> >> C functions, you are using VC++'s runtime. But who cares? I want D's
> >> runtime to be better :)
> > 
> > The gain in switching to COFF would be _huge_, because then D code would
> > be properly interoperable with most of the C code on Windows - and in
> > particular C code compiled with Microsoft's compiler. The only thing
> > saving the current situation from being a complete disaster is that you
> > can still use dlls.
> 
> It's not that easy. I mean to gain this level of compatibility we'd have
> to do both: switch to MS runtime and use COFF object format. Linking
> together two C runtimes is *ehm* tricky.
> 
> But most importantly newer versions of VC++ use newer runtimes, I'm not
> sure how compatible they are, but judging by my previous experience -
> you still has to keep things separated like in DLLs and never mix
> allocation/FILE* stuff between them.

That may be, but the fact that I can't just link C code built with Visual 
Studio with D code is a major problem in enviroments where Visual Studio is 
what is used on Windows (such as where I work). In comparison, in Linux it 
works, because dmd actually uses the compiler which is the de facto standard 
on Linux - gcc. But since dmd uses optlink on Windows, you just don't have 
that level of compatibility. dmc and optlink may very well be solid tools, but 
as a D programmer trying to interoperate with C code, compatability matters a 
lot, and dmd on Windows just doesn't have it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list