Bug 2978 – Unhandled win32 exception on successful exe compilation
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2009-05-13T16:05:00Z
Last change time
2015-06-09T01:18:04Z
Keywords
ice-on-valid-code
Assigned to
bugzilla
Creator
sandford
Comments
Comment #0 by sandford — 2009-05-13T16:05:45Z
DMD generates an unhandled win32 exception when successfully compiling an exe from a set of object files. It has occurred over a wide variety of code and on multiple systems (Core 2 duo, Corde 2 quad and AMD dual core) and OS (XP, Vista) and has also occurred with the command shell's is limited to a single processor. The error is stochastic, though is almost always generated and occurs both on file creation and overwrite. It appears to not happen on first use, but does happen on subsequent uses (i.e. it may occur only when the file system is warmed up). Only occurs with relative exe pathnames, not with absolute path names.
Test cases derived from the Code::Blocks D program template
doesn't work
dmd.exe bin\Release\HelloWord.exe obj\Release\hello.obj
seemed to work on 2.029, but not 2.030
dmd.exe bin\HelloWord.exe obj\Release\hello.obj
works in 2.030
dmd.exe HelloWord.exe obj\Release\hello.obj
works
dmd.exe c:\really\long\path\bin\HelloWord.exe obj\Release\hello.obj
Comment #1 by sandford — 2009-05-13T22:40:17Z
(In reply to comment #0)
> DMD generates an unhandled win32 exception when successfully compiling an exe
> from a set of object files. It has occurred over a wide variety of code and on
> multiple systems (Core 2 duo, Corde 2 quad and AMD dual core) and OS (XP,
> Vista) and has also occurred with the command shell's is limited to a single
> processor. The error is stochastic, though is almost always generated and
> occurs both on file creation and overwrite. It appears to not happen on first
> use, but does happen on subsequent uses (i.e. it may occur only when the file
> system is warmed up). Only occurs with relative exe pathnames, not with
> absolute path names.
>
> Test cases derived from the Code::Blocks D program template
>
> doesn't work
> dmd.exe bin\Release\HelloWord.exe obj\Release\hello.obj
>
> seemed to work on 2.029, but not 2.030
> dmd.exe bin\HelloWord.exe obj\Release\hello.obj
>
> works in 2.030
> dmd.exe HelloWord.exe obj\Release\hello.obj
>
> works
> dmd.exe c:\really\long\path\bin\HelloWord.exe obj\Release\hello.obj
I spoke too soon. More test cases
dmd.exe HelloWord.exe obj\Release\hello.obj obj\Release\b.obj
occationaly fails if the root directory is deep.
dmd.exe c:\dmd\Test.exe obj\Release\hello.obj obj\Release\b.obj dfl.lib
Fails even if the root directory shallow. dfl.lib is located in C:\dmd\windows\lib.
dmd.exe c:\dmd\HelloWord.exe
fails if the root directory is long and many obj/lib files are included
Comment #2 by bugzilla — 2009-05-15T12:25:48Z
Try running dmd under windbg.exe and see where it fails.
(In reply to comment #3)
> (In reply to comment #2)
> > Try running dmd under windbg.exe and see where it fails.
>
> I'm not well versed in non-symbolic debugging
You don't need to be. <g>
>, but I've included the output
> from several runs, since the exit code was changing. Is there anything else I
> should try?
Compile a debug build of DMD:
c:\dmd\src\dmd> make -fwin32.mak
c:\dmd\src\dmd> copy dmd.exe c:\dmd\windows\bin
Then run dmd under windbg.
Comment #5 by sandford — 2009-06-05T20:46:31Z
Thanks Don.
Error appears to occur at line 1000 of root.c in function int File::read().
...
#elif _WIN32
DWORD size;
DWORD numread;
HANDLE h;
int result = 0;
char *name;
name = this->name->toChars();
004F69D6 mov eax,dword ptr [this]
Break-> 004F69D9 mov ecx,dword ptr [eax+14h]
Watch reports 'this' is null.
Unhandled memory exception at 0x00000014 (null+14)
--Call Stack--
> dmd.exe!File::read()() Line 1000 + 0x3 bytes C++
dmd.exe!startthread() Line 104 + 0x7 bytes C++
dmd.exe!___threadstartex@4() + 0x1d bytes
ntdll.dll!774e19bb()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!774e198e()
-- Output --
'dmd.exe': Loaded 'C:\dmd\windows\bin\dmd.exe', Symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\ntdll.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\kernel32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\shell32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\msvcrt.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\gdi32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\user32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\advapi32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\rpcrt4.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\shlwapi.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\imm32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\msctf.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\lpk.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\usp10.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\avgrsstx.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Windows\System32\apphelp.dll', No symbols loaded.
'dmd.exe': Loaded 'C:\Program Files\Common Files\LogiShrd\LVMVFM\LVPrcInj.dll', No symbols loaded.
The thread 'Win32 Thread' (0x3a0c) has exited with code 0 (0x0).
Unhandled exception at 0x004f69d9 in dmd.exe: 0xC0000005: Access violation reading location 0x00000014.
-- Start Thread Call frame --
startthread::p 0x00288cd8 void *
-startthread::aw 0x00288cd8 AsyncRead *
hThread 0x5c6e6962 void *
filesdim 1969382724 unsigned int
filesmax 103 unsigned int
-files 0x00288ce4 FileData [1]
startthread::i 0 unsigned int
-startthread::f 0x00288ce4 FileData *
Error at Line 104 of async.c
unsigned __stdcall startthread(void *p)
{
AsyncRead *aw = (AsyncRead *)p;
for (size_t i = 0; i < aw->filesdim; i++)
{ FileData *f = &aw->files[i];
f->result = f->file->read();
-- Main Call Stack (Location runLINK)--
ntdll.dll!77505e74()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77505620()
kernel32.dll!76f19884()
> dmd.exe!RTLMultiPool::SelectFree() + 0x1e bytes
kernel32.dll!76f197f2()
dmd.exe!__exec() + 0x16e bytes
dmd.exe!__mbschr() + 0x1a7 bytes
dmd.exe!__mbschr() + 0x2d4 bytes
dmd.exe!__mbschr() + 0x31e bytes
dmd.exe!___spawn() + 0xc4 bytes
dmd.exe!runLINK() Line 191 + 0xd bytes C++
dmd.exe!main() Line 1190 + 0x5 bytes C++
dmd.exe!_mainCRTStartup() + 0xa9 bytes
kernel32.dll!76f1d0e9()
ntdll.dll!774e19bb()
ntdll.dll!774e198e()
Comment #6 by clugdbug — 2009-07-09T06:54:13Z
Could this be the same as the random OPTLINK crash on multi-core machines? It sounds pretty similar. Check if it still fails in 1.046 and 2.031.
Comment #7 by sandford — 2009-07-09T08:31:30Z
(In reply to comment #6)
> Could this be the same as the random OPTLINK crash on multi-core machines? It
> sounds pretty similar. Check if it still fails in 1.046 and 2.031.
Actually, I tried the optlink patch when it came out, and that didn't seem to fix it. However, I haven't had a crash on valid code happen in 2.031, so it's probably fixed, for the most part. Since this has been a stochastic problem, I had been waiting to see if it just got less frequent or has disappeared, before making a comment. Since it appears to be fixed, thanks!
Note:
I did run into a few crashes on invalid code (stuff to do with the new integer rules) when porting my personal branch of DFL (since the main trunk is a few revs behind). But that's probably a different bug.
Comment #8 by braddr — 2009-07-09T17:08:13Z
Can you reproduce this with 2.031? Walter fixed a bug that might well be related in that release.
Comment #9 by bugzilla — 2009-07-09T18:43:53Z
I believe this was fixed in dmd 1.046 and 2.031. Reopen if not.