Re: Would be nice if compiler gave more 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! Make sure you are building with -g (debug information).
Re: Would be nice if compiler gave more information!
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.
Re: Would be nice if compiler gave more 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
Re: Would be nice if compiler gave more information!
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.
Re: Would be nice if compiler gave more information!
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.
Re: Would be nice if compiler gave more information!
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
Re: Would be nice if compiler gave more information!
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
Re: Would be nice if compiler gave more information!
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.
Re: Would be nice if compiler gave more information!
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
Re: Would be nice if compiler gave more information!
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`.
Re: Would be nice if compiler gave more information!
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.
