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