www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Would be nice if compiler gave more information!

reply DigitalDesigns <DigitalDesigns gmail.com> writes:
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.
Jun 14 2018
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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).
Jun 14 2018
prev sibling next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
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
Jun 14 2018
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 14 2018
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
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.
Jun 14 2018
next sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
 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.
Jun 14 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 14 2018
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
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.
Jun 14 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 14 2018
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 15 June 2018 at 03:54:34 UTC, DigitalDesigns wrote:
 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.
In my experience as a layman as far as DMD internals go, a compiler stack trace generally does little to elucidate what the cause of the crash is, or especially what part of the program is responsible. Tools to reduce the input (DustMite, or Digger for regressions) are generally more effective.
 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.
FWIW, Digger can build debug DMD binaries with `-c build.components.dmd.debugDMD=true`.
Jun 14 2018
parent DigitalDesigns <DigitalDesigns gmail.com> writes:
On Friday, 15 June 2018 at 04:19:28 UTC, Vladimir Panteleev wrote:
 On Friday, 15 June 2018 at 03:54:34 UTC, DigitalDesigns wrote:
 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.
In my experience as a layman as far as DMD internals go, a compiler stack trace generally does little to elucidate what the cause of the crash is, or especially what part of the program is responsible. Tools to reduce the input (DustMite, or Digger for regressions) are generally more effective.
Irregardless, any information is better than none. Just because it is not effective does not mean it is useless. In some cases it could lead directly to the problem. So it is wrong to think that it shouldn't be done because it doesn't help in ALL cases. That is throwing out the baby with the bath water. The question should be not how to get rid of the baby but how to keep the water.
 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.
FWIW, Digger can build debug DMD binaries with `-c build.components.dmd.debugDMD=true`.
The point is to include a debug version because not everyone wants to build things and go through that trouble nor do they necessarily have the time. dmd is about 3MB. Adding a debug version, what, might cost 100mb? That is nothing in to days world! There really is no reason to not do it if one really wants to cover as many bases as possible for fixing compiler bugs! There really is no excuse, but people will give them. All it would take is for someone to add a few lines to the automatic build environment and viola! There would be another vector of attack... potentially very strong in some cases. My experience with the D tools such as dustmite has not been friendly as it should. This might be because I use visual D though.
Jun 15 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 14 2018