object.Error@(0): Access Violation
----------------
0x00415999
0x0040A3B7
0x00518A2D
0x005751FD
0x005ABA41
0x005ABAEB
0x00525136
0x005246D6
0x005253E2
0x0066509D
0x00664F38
0x00529F68
0x77018744 in BaseThreadInitThunk
0x77C5582D in RtlGetAppContainerNamedObjectPath
0x77C557FD in RtlGetAppContainerNamedObjectPath

So, when the compiler crashes it would be really nice if more information than just the above was given!

All I know is that using the code

static foreach(a; ["wchar", "ushort"])
	mixin("void bar("~a~" value) { foo(); }");
	
is what is causing it. Manually giving the functions works fine.

On Thursday, 14 June 2018 at 11:30:46 UTC, DigitalDesigns wrote:
> object.Error@(0): Access Violation
> ----------------
> 0x00415999
> 0x0040A3B7
> 0x00518A2D
> 0x005751FD
> 0x005ABA41
> 0x005ABAEB
> 0x00525136
> 0x005246D6
> 0x005253E2
> 0x0066509D
> 0x00664F38
> 0x00529F68
> 0x77018744 in BaseThreadInitThunk
> 0x77C5582D in RtlGetAppContainerNamedObjectPath
> 0x77C557FD in RtlGetAppContainerNamedObjectPath
>
> So, when the compiler crashes it would be really nice if more information than just the above was given!

Make sure you are building with -g (debug information).

On Thursday, 14 June 2018 at 11:30:46 UTC, DigitalDesigns wrote:
> object.Error@(0): Access Violation
> ----------------
> 0x00415999
> 0x0040A3B7
> 0x00518A2D
> 0x005751FD
> 0x005ABA41
> 0x005ABAEB
> 0x00525136
> 0x005246D6
> 0x005253E2
> 0x0066509D
> 0x00664F38
> 0x00529F68
> 0x77018744 in BaseThreadInitThunk
> 0x77C5582D in RtlGetAppContainerNamedObjectPath
> 0x77C557FD in RtlGetAppContainerNamedObjectPath
>
> So, when the compiler crashes it would be really nice if more information than just the above was given!
>
> All I know is that using the code
>
> static foreach(a; ["wchar", "ushort"])
> 	mixin("void bar("~a~" value) { foo(); }");
> 	
> is what is causing it. Manually giving the functions works fine.

That code works great when I define foo, and doesn't crash when I don't. Please provide a full example that causes the crash so that we can figure out the cause.

Now, since this is a compiler crash, getting symbols in the stack trace isn't going to help you unless you're planning to fix the compiler itself. If you are, just follow Vlad's advice and build the compiler with -g.


On Thursday, 14 June 2018 at 11:55:03 UTC, Vladimir Panteleev wrote:
> Make sure you are building with -g (debug information).

This is from the compiler crashing. I doubt he's built that.

--
  Simen

On 14.06.2018 13:30, DigitalDesigns wrote:
> 
> All I know is that using the code
> 
> static foreach(a; ["wchar", "ushort"])
>      mixin("void bar("~a~" value) { foo(); }");
> 
> is what is causing it. Manually giving the functions works fine.

This works:

void foo(){}
static foreach(a; ["wchar", "ushort"])
    mixin("void bar("~a~" value) { foo(); }");

If you can give a code snippet that causes the crash, I can probably figure out what's going wrong.

On Thursday, 14 June 2018 at 12:12:34 UTC, Timon Gehr wrote:
> On 14.06.2018 13:30, DigitalDesigns wrote:
>> 
>> All I know is that using the code
>> 
>> static foreach(a; ["wchar", "ushort"])
>>      mixin("void bar("~a~" value) { foo(); }");
>> 
>> is what is causing it. Manually giving the functions works fine.
>
> This works:
>
> void foo(){}
> static foreach(a; ["wchar", "ushort"])
>     mixin("void bar("~a~" value) { foo(); }");
>
> If you can give a code snippet that causes the crash, I can probably figure out what's going wrong.

I can't because I have no idea what causes it. I changed the mixin to not use the foreach but a CTFE that generates a string using the foreach which is then mixed in.


Why can't the compiler give a stack trace? Any information is better than none!

I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now.

Why not ship with a debuggable dmd so that when it crashes it can be debugged and potentially fixed but at least see where it might be crashing.

> I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now.
>

There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash.

So, this is either a bug in modules or something in the module that crashed.

the two modules I removed were sumtype and openmethods... both public.

On Friday, June 15, 2018 02:31:49 DigitalDesigns via Digitalmars-d wrote:
> > I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now.
>
> There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash.
>
> So, this is either a bug in modules or something in the module that crashed.
>
> the two modules I removed were sumtype and openmethods... both public.

Regardless of whether there's a bug in any of the modules that you're using, the compiler should never crash. If it does, there's a bug in the compiler.

- Jonathan M Davis

On Friday, June 15, 2018 02:19:51 DigitalDesigns via Digitalmars-d wrote:
> Why can't the compiler give a stack trace? Any information is better than none!

It's not giving a stack trace with symbol names, because it wasn't compiled with debug symbols enabled.

- Jonathan M Davis

On Friday, 15 June 2018 at 02:47:56 UTC, Jonathan M Davis wrote:
> On Friday, June 15, 2018 02:31:49 DigitalDesigns via Digitalmars-d wrote:
>> > I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now.
>>
>> There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash.
>>
>> So, this is either a bug in modules or something in the module that crashed.
>>
>> the two modules I removed were sumtype and openmethods... both public.
>
> Regardless of whether there's a bug in any of the modules that you're using, the compiler should never crash. If it does, there's a bug in the compiler.
>
> - Jonathan M Davis

I know, but without having any type of feedback it becomes extremely difficult to find the code to figure out what is going on. I only was lucky to find the module issue relatively quickly because I just added a bunch of modules and it was working right before. If I would have not built the code right after or would have not tried to figure out what was going on then it would become a harder problem. Considering that some code I added before also asserted would have lead me to think it was related to that problem and not simply including a module.

So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly.

I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc.

On Friday, June 15, 2018 03:54:34 DigitalDesigns via Digitalmars-d wrote:
> On Friday, 15 June 2018 at 02:47:56 UTC, Jonathan M Davis wrote:
> > On Friday, June 15, 2018 02:31:49 DigitalDesigns via
> >
> > Digitalmars-d wrote:
> >> > I am getting the compiler to crash from a different problem after I moved some files around. I have no idea where the error is now.
> >>
> >> There was a module that was included that was crashing the compiler for some reason. When I removed it, which wasn't part of the original project the compiler didn't crash.
> >>
> >> So, this is either a bug in modules or something in the module that crashed.
> >>
> >> the two modules I removed were sumtype and openmethods... both public.
> >
> > Regardless of whether there's a bug in any of the modules that you're using, the compiler should never crash. If it does, there's a bug in the compiler.
> >
> > - Jonathan M Davis
>
> I know, but without having any type of feedback it becomes extremely difficult to find the code to figure out what is going on. I only was lucky to find the module issue relatively quickly because I just added a bunch of modules and it was working right before. If I would have not built the code right after or would have not tried to figure out what was going on then it would become a harder problem. Considering that some code I added before also asserted would have lead me to think it was related to that problem and not simply including a module.
>
> So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly.
>
> I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc.

I'm not against there being an easy way to get at a debug build of the compiler without building it yourself, but really, compiler errors shouldn't be happening often enough for it to matter much. And in most cases, the people who first run into the problem aren't the ones who end up debugging it anyway.

Regardless, if you haven't yet, I'd suggest using dustmite to reduce the problem:

https://github.com/CyberShadow/DustMite/wiki

- Jonathan M Davis