www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D Privileged instruction

reply Alex <AJ gmail.com> writes:
0xC0000096: Privileged instruction.

This happens when I run an app that throws an error inside visual 
D. When I run it on it's own I get the correct error.

std.file.FileException std\file.d(449): data.xml: The system 
cannot find the file specified.
----------------
0x00007FF61625E4B9 in  trusted bool 
std.file.cenforce!(bool).cenforce(bool, scope const(char)[], 
scope const(wchar)*, immutable(char)[], ulong)
0x00007FF61624ECB2 in  safe void[] std.file.readImpl(scope 
const(char)[], scope const(wchar)*, ulong)
0x00007FF615F8EC0E in std.file.read!string.read at 
X:\dmd2\windows\bin\..\..\src\phobos\std\file.d(313)
0x00007FF615F8B083 in D main at main.d(133)

The problem is that I have to open up a console and run the 
program in it to see this error.

This only happens with x64 and happens with every single throwing 
error.

Is there a bug in the code that handles exceptions for x64 that 
is causing the privileged instruction error?
May 16 2019
next sibling parent reply Alex <AJ gmail.com> writes:
Also, when I do a search for some things and it returns back the 
Visual D search, When I double click on an entry it does not take 
me to the location.

everything checks out in the list but the path is relative 
"..\Libs\moduleX.d"

I'm thinking that is the reason it doesn't open it because it 
doesn't turn that in to an absolute path. It's obviously 
collecting the right info since it's displaying it all correctly 
but the open file routine when double clicking on an entry is 
failing to open the file... suggesting it is most likely due to 
the relative path.
May 16 2019
next sibling parent Alex <AJ gmail.com> writes:
On Thursday, 16 May 2019 at 15:47:20 UTC, Alex wrote:
 Also, when I do a search for some things and it returns back 
 the Visual D search, When I double click on an entry it does 
 not take me to the location.

 everything checks out in the list but the path is relative 
 "..\Libs\moduleX.d"

 I'm thinking that is the reason it doesn't open it because it 
 doesn't turn that in to an absolute path. It's obviously 
 collecting the right info since it's displaying it all 
 correctly but the open file routine when double clicking on an 
 entry is failing to open the file... suggesting it is most 
 likely due to the relative path.
This may be a bigger bug because I've noticed a lot of times when I do things Visual D simply either ignores. For example, if I'm stepping through some code using F11 to step in to and I have function that uses another function like: if (foo(bar()) I will step in to bar but afterwards not in to foo. If I do a go to definition on foo I get 3 possibilities... One for the interface, one for the class, and one for the derived class. But clicking on any one of them does not take me anywhere. It seems there is some bug in the resolving of symbols in visual D. It might be related to these relative paths. I think we already talked about this in some way and there was some issues with how D resolved paths and it solved some other issue. It might be a pattern that Visual D uses based on the old code. I don't remember the details though. I code is too complex to upload and dustmiting it doesn't work. D:\dmd2\windows\bin\dustmite --strip-comments --split *.bat:lines D:\.dustmite "build.dustmite.bat 2>&1 | find \"Internal error\"" Suspicious file found: D:\.dustmite\build.dustmite.bat You should use a clean copy of the source tree. If it was your intention to include this file in the file-set to be reduced, re-run dustmite with the --force option. Not sure why it is using .dustmite in the root directory. It used to do it in the project directory.
May 17 2019
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16/05/2019 17:47, Alex wrote:
 Also, when I do a search for some things and it returns back the Visual
 D search, When I double click on an entry it does not take me to the
 location.
 
 everything checks out in the list but the path is relative
 "..\Libs\moduleX.d"
 
 I'm thinking that is the reason it doesn't open it because it doesn't
 turn that in to an absolute path. It's obviously collecting the right
 info since it's displaying it all correctly but the open file routine
 when double clicking on an entry is failing to open the file...
 suggesting it is most likely due to the relative path.
 
 
Do you mean the "Search File/Symbol" from the Visual D menu? And your project contains files that are outside the folder with the project file? Seems to work here with a simple test. What project type do you use?
May 17 2019
parent Alex <AJ gmail.com> writes:
On Friday, 17 May 2019 at 07:40:32 UTC, Rainer Schuetze wrote:
 On 16/05/2019 17:47, Alex wrote:
 Also, when I do a search for some things and it returns back 
 the Visual D search, When I double click on an entry it does 
 not take me to the location.
 
 everything checks out in the list but the path is relative 
 "..\Libs\moduleX.d"
 
 I'm thinking that is the reason it doesn't open it because it 
 doesn't turn that in to an absolute path. It's obviously 
 collecting the right info since it's displaying it all 
 correctly but the open file routine when double clicking on an 
 entry is failing to open the file... suggesting it is most 
 likely due to the relative path.
 
 
Do you mean the "Search File/Symbol" from the Visual D menu? And your project contains files that are outside the folder with the project file? Seems to work here with a simple test. What project type do you use?
When I use "Go to definition"[right mouse button on a function id, say] it pops up the same dialog from Search File/Symbol if there are multiple matches or it see's an ambiguity(I've seen it pop up 0 and 1). Sometimes it takes me to the definition, sometimes it pops up the dialog, sometimes it does nothing. I'm using standard D project(not the C/C++/D). I have a hard link in the project dir which points to other files. The hard link is dragged in to the project. ..\Libs SolutionDir\ProjectDir SolutionDir\Libs Hence ..\Libs goes down from the Project Dir and goes in to the Libs dir(which is a hard link to Libs somewhere else but it shouldn't matter). The search that pops up tends to use ..\Libs because that seems to be where it has the most trouble but also because I use oop a lot in Libs. This actually happens for a lot of symbols that exist in an interface and a class. It seems the "search" is finding the symbol in the interface and the symbol in the class(and derived) but cannot figure out which one to go to. It shows all 3 but then I can't double click any one to open up the file and go to that line. i.e., we know it is finding the right stuff but it's just not opening the file when clicked. So this is almost surely a path issue. Again, we already had an issue like this because of path's not being properly handled in D. (or maybe it was just a problem I had, but there is something were with std.path and relative paths). Also, There are two options: 1.Go to definition 2 Go to declaration they both do the same thing it seems. I don't mind the dialog popping up but if there are 0, 1, or 2 matches it seems it could avoid popping up the dialog in most of these cases. Ideally it would determine which is the actual call being made and choose that one. What I mean is that if I have something like interface X { foo } class Y : X { foo } class Z : T { foo } and I'm calling Y.foo(if it is clear) then it takes me to class Y. From there I could use goto definition again it would jump up higher in the chain and take me to X's foo. Basically work up the hierarchy from the lowest to the highest. This might not be good for large chains though but if it's 2(just a class and interface) then it might be best to have go to declaration use the interface and go to definition go to the class. Not a huge deal here as long as the search did work as it's just a click away. Maybe a better way to do all this would be to show the hierarchy in the search(as a tree) and then that would be far more informative. e.g., X.foo ..\Libs\mod.d 43 Y.foo ..\Libs\mod.d 55 Z.foo ..\Libs\modZ.d 22 F.foo ..\Libs\foo.d 4444 Q.bar ... ... (just determine the hierarchy and use tabs for inheritance level and maybe marking them as interface, class, abstract class, struct, etc so it's easier to tell without having to open the file). Anyways, not a huge deal since I could get by without that stuff if I could just get the search to work in the first place... But my feeling is this issue also is related to many of the other problems I experience such as when debugging and I can't step in to a function since it's not seeing the source code. They all seem to happen for code that is in ..\Lib but not absolutely specified files. One of the problems is that when VD can't seem to find the file it does't report anything such as an error message saying the file is not found. Also, I had this issue with std.stdio; I was trying to jump to stdout. import std.stdio; stdout.close(); "go to definition" on stdout failed with "no definition found for stdout". but "go to definition" on std.stdio worked fine and opened up std.stdio which I then could search for stdout. import std.stdio; stdout.open("CON", "w"); stderr.open("CON", "w"); It would be nice if the "no definition found for ..." was more informative such as giving the files it is trying to look for. (such as a popup window listing all them in a text window or in the output window) Without knowing why stuff fails it's hard to figure out why stuff fails ;/ Thanks again!
May 17 2019
prev sibling next sibling parent reply Alex <AJ gmail.com> writes:
After upgrading to VS2019, dragging a variable from the autos, 
locals, or watches copies the whole line, including any junk 
rather than the address or the name. In 2017 one could drag and 
it would just copy the address.
May 16 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17/05/2019 03:10, Alex wrote:
 After upgrading to VS2019, dragging a variable from the autos, locals,
 or watches copies the whole line, including any junk rather than the
 address or the name. In 2017 one could drag and it would just copy the
 address.
 
Yeah, I noticed this too, but wasn't sure whether it was related to the VS update or to something else. Thanks for clarifying.
May 17 2019
parent reply Alex <AJ gmail.com> writes:
On Friday, 17 May 2019 at 07:42:32 UTC, Rainer Schuetze wrote:
 On 17/05/2019 03:10, Alex wrote:
 After upgrading to VS2019, dragging a variable from the autos, 
 locals, or watches copies the whole line, including any junk 
 rather than the address or the name. In 2017 one could drag 
 and it would just copy the address.
 
Yeah, I noticed this too, but wasn't sure whether it was related to the VS update or to something else. Thanks for clarifying.
It would be nice too it would use the variable name since one can set the auto button to refresh it... if that works in some way. May be better to make it optional. This way I don't have to keep refreshing the ptr value every re-run to see the same memory or manually copy the variable name.
May 17 2019
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 17/05/2019 11:18, Alex wrote:
 On Friday, 17 May 2019 at 07:42:32 UTC, Rainer Schuetze wrote:
 On 17/05/2019 03:10, Alex wrote:
 After upgrading to VS2019, dragging a variable from the autos,
 locals, or watches copies the whole line, including any junk rather
 than the address or the name. In 2017 one could drag and it would
 just copy the address.
Yeah, I noticed this too, but wasn't sure whether it was related to the VS update or to something else. Thanks for clarifying.
It would be nice too it would use the variable name since one can set the auto button to refresh it... if that works in some way. May be better to make it optional. This way I don't have to keep refreshing the ptr value every re-run to see the same memory or manually copy the variable name.
If you enter the expression manually, it is shown with "auto" enabled and it works.
May 19 2019
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16/05/2019 17:28, Alex wrote:
 0xC0000096: Privileged instruction.
 
 This happens when I run an app that throws an error inside visual D.
 When I run it on it's own I get the correct error.
 
 std.file.FileException std\file.d(449): data.xml: The system cannot find
 the file specified.
 ----------------
 0x00007FF61625E4B9 in  trusted bool
 std.file.cenforce!(bool).cenforce(bool, scope const(char)[], scope
 const(wchar)*, immutable(char)[], ulong)
 0x00007FF61624ECB2 in  safe void[] std.file.readImpl(scope
 const(char)[], scope const(wchar)*, ulong)
 0x00007FF615F8EC0E in std.file.read!string.read at
 X:\dmd2\windows\bin\..\..\src\phobos\std\file.d(313)
 0x00007FF615F8B083 in D main at main.d(133)
 
 The problem is that I have to open up a console and run the program in
 it to see this error.
 
 This only happens with x64 and happens with every single throwing error.
 
 Is there a bug in the code that handles exceptions for x64 that is
 causing the privileged instruction error?
dmd doesn't use a standard exception handling for x64, but implements a generic version derived from older posix implementations. Usually all exceptions or errors are handled by the runtime showing the stack trace. But when running in a debugger, unhandled exceptions are not caught by the runtime but the privileged instruction is executed. This allows analyzing the code at the location of the throw. The debugger should show you the same callstack as the trace above. LDC uses (slightly modified) C++ exceptions, so debugger support for these is better.
May 17 2019
parent reply Alex <AJ gmail.com> writes:
On Friday, 17 May 2019 at 07:33:57 UTC, Rainer Schuetze wrote:
 On 16/05/2019 17:28, Alex wrote:
 0xC0000096: Privileged instruction.
 
 This happens when I run an app that throws an error inside 
 visual D. When I run it on it's own I get the correct error.
 
 std.file.FileException std\file.d(449): data.xml: The system 
 cannot find
 the file specified.
 ----------------
 0x00007FF61625E4B9 in  trusted bool
 std.file.cenforce!(bool).cenforce(bool, scope const(char)[], 
 scope
 const(wchar)*, immutable(char)[], ulong)
 0x00007FF61624ECB2 in  safe void[] std.file.readImpl(scope
 const(char)[], scope const(wchar)*, ulong)
 0x00007FF615F8EC0E in std.file.read!string.read at
 X:\dmd2\windows\bin\..\..\src\phobos\std\file.d(313)
 0x00007FF615F8B083 in D main at main.d(133)
 
 The problem is that I have to open up a console and run the 
 program in it to see this error.
 
 This only happens with x64 and happens with every single 
 throwing error.
 
 Is there a bug in the code that handles exceptions for x64 
 that is causing the privileged instruction error?
dmd doesn't use a standard exception handling for x64, but implements a generic version derived from older posix implementations. Usually all exceptions or errors are handled by the runtime showing the stack trace. But when running in a debugger, unhandled exceptions are not caught by the runtime but the privileged instruction is executed. This allows analyzing the code at the location of the throw. The debugger should show you the same callstack as the trace above.
The call stack does not show the actual error message though. So I have no idea what is actually causing the crash. The error string clearly exists somewhere because it is shown in the stack trace on the error when run outside the debugger. Can Visual D simply add to the error message the "last line" in the call stack(whatever line that would show the error string) or figure out where it's at and show it. Basically some information is better than none. Sometimes the error is not really matched up with the line that the debugger takes one to so it's difficult to diagnose since privileged instruction is completely uninformative. or maybe it could just print the full stacktrace to the output window on an exception/error?
May 17 2019
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 17/05/2019 11:16, Alex wrote:
 On Friday, 17 May 2019 at 07:33:57 UTC, Rainer Schuetze wrote:
 On 16/05/2019 17:28, Alex wrote:
 0xC0000096: Privileged instruction.

 This happens when I run an app that throws an error inside visual D.
 When I run it on it's own I get the correct error.

 std.file.FileException std\file.d(449): data.xml: The system cannot find
 the file specified.
 ----------------
 0x00007FF61625E4B9 in  trusted bool
 std.file.cenforce!(bool).cenforce(bool, scope const(char)[], scope
 const(wchar)*, immutable(char)[], ulong)
 0x00007FF61624ECB2 in  safe void[] std.file.readImpl(scope
 const(char)[], scope const(wchar)*, ulong)
 0x00007FF615F8EC0E in std.file.read!string.read at
 X:\dmd2\windows\bin\..\..\src\phobos\std\file.d(313)
 0x00007FF615F8B083 in D main at main.d(133)

 The problem is that I have to open up a console and run the program
 in it to see this error.

 This only happens with x64 and happens with every single throwing error.

 Is there a bug in the code that handles exceptions for x64 that is
 causing the privileged instruction error?
dmd doesn't use a standard exception handling for x64, but implements a generic version derived from older posix implementations. Usually all exceptions or errors are handled by the runtime showing the stack trace. But when running in a debugger, unhandled exceptions are not caught by the runtime but the privileged instruction is executed. This allows analyzing the code at the location of the throw. The debugger should show you the same callstack as the trace above.
The call stack does not show the actual error message though. So I have no idea what is actually causing the crash. The error string clearly exists somewhere because it is shown in the stack trace on the error when run outside the debugger. Can Visual D simply add to the error message the "last line" in the call stack(whatever line that would show the error string) or figure out where it's at and show it. Basically some information is better than none. Sometimes the error is not really matched up with the line that the debugger takes one to so it's difficult to diagnose since privileged instruction is completely uninformative. or maybe it could just print the full stacktrace to the output window on an exception/error?
The mago debug engine (that you can select with visualdproj projects) can actually show the exception type and its message (probably 32-bit only), but I have no idea yet how to get this into the (preferred) debugger extension.
May 19 2019