Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 14:57:20 UTC, Vladimir Panteleev wrote: On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite. When I run the code in x86 the error is from a throw and is a first chance exception and the error message is shown as normal. In x64, no changes to source, it is a privileged instruction error. I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... I doubt it is my machine and it seems to be completely dmdx64's fault. Basically I just program in x86 most of the time and compile for x64 because of things like this.
Re: remove file access denied(remove broke)
On Saturday, 15 September 2018 at 06:13:29 UTC, bauss wrote:
On Friday, 14 September 2018 at 16:55:21 UTC, Josphe Brigmo
wrote:
On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
[...]
It woudln't help. I'm dealing with over a million files and
you'd need those files too.
But basically all I have done is created a new rename function:
void removeFile(string fn)
{
if (!isDir(fn))
{
// remove(fn)
setAttributes(fn, 0x80);
auto ls = executeShell(`del /F /Q "`~fn~`"`);
if (ls.status != 0) throw new Exception("Cannot delete file
`"~fn~"`!");
}
}
And this works and functions appropriately.
The other code is basically just recursively going through the
directory as standard practice using dirEntries and deleting
certain files(it's a little more complex since there is some
logic on the file name, but nothing touches the file except
delete).
Went ahead and did the following in case anyone comes across
your issue in the future:
https://github.com/dlang/phobos/pull/6707
That way the documentation will at least be clear about it.
Thanks. The problem ultimately is MAX_PATH.
Seems that phobo's does not detect windows 10 nor use unicode for
such things as it should which would not break simple code(one
expects file routines to be well used and the bugs fixed). Seems
not to many people use D for windows with long paths and files
and hence D for windows.
The fix is relatively simple ("prepend \\?\ or use the wide
functions).
dealing with very long paths and names
Seems to break dirEntries when trying to deal with long pathnames(> 512) on windows. It's a strange error because it just fails with access denied or missing file.
Re: remove file access denied(remove broke)
On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
On Fri, Sep 14, 2018 at 02:36:34PM +, Josphe Brigmo via
Digitalmars-d-learn wrote: [...]
It happens on a bunch. I do get errors or overlong file names
but this doesn't seem to be the case.
The fact is, that simply using execute shell using the same
file name works. So this is a D problem.
It happens quite often and every time I can delete the files
in file explorer.
It would really help if you post a stripped-down version of the
code that exhibits the same problem. Otherwise we're just
guessing what the real problem is.
T
It woudln't help. I'm dealing with over a million files and you'd
need those files too.
But basically all I have done is created a new rename function:
void removeFile(string fn)
{
if (!isDir(fn))
{
// remove(fn)
setAttributes(fn, 0x80);
auto ls = executeShell(`del /F /Q "`~fn~`"`);
if (ls.status != 0) throw new Exception("Cannot delete file
`"~fn~"`!");
}
}
And this works and functions appropriately.
The other code is basically just recursively going through the
directory as standard practice using dirEntries and deleting
certain files(it's a little more complex since there is some
logic on the file name, but nothing touches the file except
delete).
Re: remove file access denied(remove broke)
On Friday, 14 September 2018 at 13:28:41 UTC, Adam D. Ruppe wrote: On Friday, 14 September 2018 at 08:32:48 UTC, Josphe Brigmo wrote: Seems remove is broke. The source code for remove is DeleteFile(name), so not much room for bugs there, except maybe string conversion. What is the filename you are working on? It happens on a bunch. I do get errors or overlong file names but this doesn't seem to be the case. The fact is, that simply using execute shell using the same file name works. So this is a D problem. It happens quite often and every time I can delete the files in file explorer.
Re: remove file access denied(remove broke)
On Friday, 14 September 2018 at 04:48:09 UTC, Norm wrote: On Thursday, 13 September 2018 at 23:25:24 UTC, Josphe Brigmo wrote: I am trying to remove a file remove(filename); and I get an access denied! I can remove it from explorer just fine. I am able to remove other files but there should be no reason why the file can't be removed in this case. All I am doing to mess with the file is reading it's contents right before to do a file compare(I am removing the file if it is a duplicate). Does read() lock the file at all? (maybe the lock is persisting just long enough to make the remove fail? Since I can delete the file outside the program and since the filename is valid(I copied and pasted it to remove it to check), This seems like a D problem. Do you have the file open when you call remove? If so close the file handle before the remove call. If you can post a stripped down version of your code it would also help. bye, Norm No, I use read, there is no file handles. Pointless to post code because it won't offer much. Also, I have security privileges. I simply read the file to compare it's contents then I try to remove the file if it had the same contents and it says it is invalid. I also, of course, check that it exist and is a file. This is all I'm doing that is related to file reading and I cannot remove the file(but can read it and such). So, I'm really wondering if read locks the file but doesn't release it in time. Using lockHunder shows the file isn't locked but the directory is(Probably because I'm iterating through it. Seems it is an error with remove, using executeShell works fine: auto ls = executeShell(`del /F /Q "`~fn~`"`); which does not give an error but remove(fn) does. Seems remove is broke.
remove file access denied
I am trying to remove a file remove(filename); and I get an access denied! I can remove it from explorer just fine. I am able to remove other files but there should be no reason why the file can't be removed in this case. All I am doing to mess with the file is reading it's contents right before to do a file compare(I am removing the file if it is a duplicate). Does read() lock the file at all? (maybe the lock is persisting just long enough to make the remove fail? Since I can delete the file outside the program and since the filename is valid(I copied and pasted it to remove it to check), This seems like a D problem.
Re: x64 Privileged instruction
On Wednesday, 12 September 2018 at 13:26:03 UTC, Stefan Koch wrote: On Wednesday, 12 September 2018 at 10:42:08 UTC, Josphe Brigmo wrote: x64 gives Privileged instruction but x86 gives First-chance exception: std.file.FileException "C:\": The filename, directory name, or volume label syntax is incorrect. at std\file.d(4573) which is much more informative... seems like a bug to me. More context needed. What code does produce this behavior. Lots of code. I pretty much always get this error. Just throw. It is a first chance exception so that should be clear enough. The point is that x64 doesn't seem to handle first chance exceptions and gives a privileged instruction. This happens windows 10 visual D and I've had it happen for a long time.
x64 Privileged instruction
x64 gives Privileged instruction but x86 gives First-chance exception: std.file.FileException "C:\": The filename, directory name, or volume label syntax is incorrect. at std\file.d(4573) which is much more informative... seems like a bug to me.
DlangUI and android
Is there an emulator that can run the apks? Android emulator does not work, I suppose, because it isn't java. Complains about a missing classes.dex file. I'd rather have an emulator version if possible for quicker dev.
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 07:30:35 UTC, Alex wrote: On Saturday, 8 September 2018 at 06:56:40 UTC, Josphe Brigmo wrote: My project does not use the term update at all in any other context except that one. But I did find: void update(K, V, C, U)(ref V[K] aa, K key, scope C create, scope U update) Ok... found something here: https://dlang.org/changelog/2.082.0.html#require_update and here: https://dlang.org/spec/hash-map.html#advanced_updating It seems, they were added in 2.082.0. No idea why they are conflicting with your existing code, however... And even whether they are the source of conflict... obviously who ever added it screwed the pooch.
Re: Error: expression `update` of type `void` does not have a boolean value
On Saturday, 8 September 2018 at 05:39:39 UTC, Alex wrote:
On Saturday, 8 September 2018 at 03:12:56 UTC, Josphe Brigmo
wrote:
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type `void` does not have a
boolean value
when update is clearly a bool.
Why the hell is the compiler now thinking update is a void?
1. This code compiles fine in a test app and 2. when I rename
update to something else it works fine.
2. There is no other use of update in the entire module(not
that it should matter)
Seems this is a compiler bug but only has a problem in
context. Remember, it worked find before I updated dmd and
there is no reason why it shouldn't work.
Could you show some more code, as this works for me:
´´´
import std.stdio;
void main()
{
foo;
}
auto foo(bool update = false)()
{
static if(update)
{
}
}
´´´
compiled with
dmd --version
DMD64 D Compiler v2.082.0
Copyright (C) 1999-2018 by The D Language Foundation, All
Rights Reserved written by Walter Bright
dmd ./source/app.d
used on a Mac with Darwin Kernel Version 17.7.0
I can't, the code is from a very large project and it's too
intertwined.
I already said it worked in simple form and that it worked with a
previous compiler, so this is a regression.
Changing no code and only swapping compilers produces this bug...
and as you can see, it's obviously a bug given the form of the
function and the error message and that it worked before without
changes.
Why the specific term update? I don't know.
My project does not use the term update at all in any other
context except that one. But I did find:
void update(K, V, C, U)(ref V[K] aa, K key, scope C create, scope
U update)
Error: expression `update` of type `void` does not have a boolean value
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type `void` does not have a boolean
value
when update is clearly a bool.
Why the hell is the compiler now thinking update is a void?
1. This code compiles fine in a test app and 2. when I rename
update to something else it works fine.
2. There is no other use of update in the entire module(not that
it should matter)
Seems this is a compiler bug but only has a problem in context.
Remember, it worked find before I updated dmd and there is no
reason why it shouldn't work.
GTKD for android?
I have an app I'm writing using GtkD on windows. Eventually I'd like to port it to android. Since I have never been able to actually get anything to work on android I'm curious if there are any demos with gtkD for android? I'm wondering if I just scrap the idea of using it because it won't port without a ton of work. Ideally I'd like to just cross compile and it all work out except for a few bugs.
compiler asserts
import std.stdio, std.variant;
class Wrapper(Interface, Wrapped) : Interface
{
import std.traits;
Wrapped wrapped;
static foreach (member; __traits(allMembers, Interface))
{
}
}
void main()
{
}
when I try to compile this
v2.080.0
object.Error@(0): Access Violation
0x00415999
0x0040A3B7
Seems to work fine online so maybe this is an issue with the dmd
version? Seems like it shouldn't crash though, nothing is being
done.
Updated to latest 2.082 and it was fixed... so I'll post anyways
for anyone else that might have this issue.
