dmd(1.048/55/56) crashed on me:
AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
ModVer: 0.0.0.0	 Offset: 00000002
There is a lot of crash data but I do not know where to start looking.
I've also tried finding which part of the code is responsible, but I haven't found it yet.

strtr wrote:
> dmd(1.048/55/56) crashed on me:
> AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
> ModVer: 0.0.0.0	 Offset: 00000002
> There is a lot of crash data but I do not know where to start looking.
> I've also tried finding which part of the code is responsible, but I haven't found it yet.

Silent crashes are the worst compiler bugs. I'm desperately trying to eradicate them all, so please submit a test case if you can.
Known bugs which can cause a segfault or stack overflow on Windows DMD1 are:
3493
2315

The crash data doesn't tell you anything useful.
Try compiling with dmd -v, and it should give you a little bit of a hint of what it was doing.

Hello Strtr,

> dmd(1.048/55/56) crashed on me:
> AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
> ModVer: 0.0.0.0	 Offset: 00000002
> There is a lot of crash data but I do not know where to start looking.
> I've also tried finding which part of the code is responsible, but I
> haven't found it yet.


If you can try it on linux it's not to hard to build a debug version of dmd and run it under the debugger. That will at least give you a filename/line number for the bug report and with a little thinking and a stack trace you can take a guess at what code is causing the failure. I guess the same things can be done on windows (using windbg) but I've never done it there.

--

<IXOYE><

Don Wrote:

> strtr wrote:
> > dmd(1.048/55/56) crashed on me:
> > AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
> > ModVer: 0.0.0.0	 Offset: 00000002
> > There is a lot of crash data but I do not know where to start looking.
> > I've also tried finding which part of the code is responsible, but I haven't found it yet.
> 
> Silent crashes are the worst compiler bugs. I'm desperately trying to
> eradicate them all, so please submit a test case if you can.
> Known bugs which can cause a segfault or stack overflow on Windows DMD1 are:
> 3493
> 2315
Won't windows tell me about segfaults and buffer overflows?

The same code triggered the Data Execution Prevention on a different machine (also winXP)

> 
> The crash data doesn't tell you anything useful.
> Try compiling with dmd -v, and it should give you a little bit of a hint
> of what it was doing.
> 

-v ended like this :
semantic  Cg_shader
semantic  abgr
semantic  bgra
seman

This is code within Derelict I think.
Strange sudden break..

BCS Wrote:

> Hello Strtr,
> 
> 
> If you can try it on linux it's not to hard to build a debug version of dmd and run it under the debugger. That will at least give you a filename/line number for the bug report and with a little thinking and a stack trace you can take a guess at what code is causing the failure. I guess the same things can be done on windows (using windbg) but I've never done it there.
> 
> --
> 
> <IXOYE><
> 

I didn't even know it was possible to build dmd :)

Hello Strtr,

> -v ended like this :
> semantic  Cg_shader
> semantic  abgr
> semantic  bgra
> seman
> This is code within Derelict I think.
> Strange sudden break..

Stopping mid word makes me think that the output buffer didn't get flushed so something failed after the next to last line, but you don't know how far after.

--

<IXOYE><

strtr Wrote:

> dmd(1.048/55/56) crashed on me:
> I've also tried finding which part of the code is responsible, but I haven't found it yet.

I keep forgetting my best method yet : compiling module by module until something strange comes up, or in this case, the compiler chokes.

Seems to be related to AAs and invalid code being imported multiple times, or something :) Maybe tomorrow..

strtr wrote:
> BCS Wrote:
> 
>> Hello Strtr,
>>
>>
>> If you can try it on linux it's not to hard to build a debug version of dmd and run it under the debugger. That will at least give you a filename/line number for the bug report and with a little thinking and a stack trace you can take a guess at what code is causing the failure. I guess the same things can be done on windows (using windbg) but I've never done it there.
>>
>> --
>>
>> <IXOYE><
>>
> 
> I didn't even know it was possible to build dmd :)


Starting with versions 1.041 and 2.026, the DMD source code is included in the zip file. :)

-Lars

strtr wrote:
> strtr Wrote:
> 
>> dmd(1.048/55/56) crashed on me:
>> I've also tried finding which part of the code is responsible, but I haven't found it yet.
> 
> I keep forgetting my best method yet : compiling module by module until something strange comes up, or in this case, the compiler chokes. 
> 
> Seems to be related to AAs and invalid code being imported multiple times, or something :)
> Maybe tomorrow..

Nasty. Please post it to Bugzilla when you track it down. It's really important to get rid of these nightmare bugs.

strtr Wrote:

> dmd(1.048/55/56) crashed on me:
> AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
> ModVer: 0.0.0.0	 Offset: 00000002
> There is a lot of crash data but I do not know where to start looking.
> I've also tried finding which part of the code is responsible, but I haven't found it yet.

Everything is working again and I have found this piece of code which chokes the compiler.

module main;

//Digital Mars D Compiler v1.056
//bud_win_3.04.exe -full -cleanup

enum ENUM
{
	N0 = 1, //N0 = x; crashes for some values of x, ie. 1 and 10. and not for others ie. 3.
	N1,
	N2,
	N3,
	N4,
	N5,
	N6,
	N7,
	N8,
	N9,
	N10,
	N11,
	N12,
	N13,
	N14,
	N15,
	N16,
	N17,
	N18
}


const char[][ ENUM.max + 1 ] ENUM_NAME =
	[
		ENUM.N0 : "N0",
	];

void main()
{
	char[] text = `Hi`;

	switch(text)
	{
		//case `N0`:				//this works
		case ENUM_NAME[ENUM.N0]:	//this doesn't
			//return ENUM.N0;
		default:
			break;
	}
}

I will post it together with my previous reported enum incomprehensibility bug if it can't be further minimized.