Somehow I have managed to squash the main window of Jvisualvm: it is not longer coming up with the list of running jvm's. How can this be reset?
I have tried killing and restarting a few times now.
After snooping around the os/x filesystem I found it here:
~/Library/Application\ Support/VisualVM/8u40/config/Windows2Local/
So the following cleaned it up:
rm -rf ~/Library/Application\ Support/VisualVM/8u40/config/Windows2Local/
Related
Steps to reproduce are very easy.
Create a Dockerfile.
My Dockerfile has many more lines, but I have trimmed them so we can focus in the source of the problem.
Said that, these two lines alone (without anything more) show the problem.
FROM microsoft/iis
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $VerbosePreference = 'Continue'; "]
Run docker build . and you get hcsshim::PrepareLayer - failed failed in Win32: Función incorrecta. (0x1).
Windows 10 Pro 1909 (but it happened too in 1903)
Docker version: 2.1.0.5
Engine: 19.03.5
Machine: 0.16.2
I have found the solution to the problem.
Reading all the https://github.com/docker/for-win/issues/3884 bug, some have found a simple solution: rename C:\windows\system32\driver\cbfsconnect2017.sys so it isn't loaded the next boot.
Disabling that driver enables me to do a docker build for the first time in windows containers in almost a year.
In my case Box Sync was the one using that driver.
EDIT: #GustavoTM have found that pCloud raises the same problem.
EDIT2: #VonC have noticed that some people in the issue in GitHub has solved it deleting this other file: C:\Windows\System32\drivers\cbfs6.sys. I haven't tried that, but i put it if it helps others.
The good thing is that I don't need to uninstall Box, but only rename that file.
This is still an issue (still open) with Win10.
Looks like uninstalling cloud storage providers with file system filters like Dropbox, Box, etc. as a workaround is an option for some users.
Deinstall cloud storage providers or virus scanners; if you identify which one is not working please share in https://github.com/docker/for-win/issues/3884
In my case was the problem similar but the file cbfs6.sys was placed somewhere in the rest of uninstalled application Jungle disk, somewhere in the folder c:\Program files\Jungle disk .... It's part of Callback File System signed by EldoS Corporation.
The folder could be rename only and not delete directly. So I could delete its immediately after the PC restart, before running the Docker. So it could be delete during the Docker service restart too.
I just started using fugitive in my workflow... very useful! But I've seem to have run into a weird annoyance that I'm hoping someone might have a solution to:
When I run :Gpush, sometimes control never returns to vi. Vi hangs on the output of git push until I Ctrl+C to kill "it". I've also tried installing vim-dispatch and, within tmux, the result is that the git push pane never closes. This is even more annoying because I've got to switch down to that pane to Ctrl+C it.
Oddly, if I ps, I do not see any git processes running, so I'm not sure what is hanging, exactly... but Ctrl+C does kill "it", whatever "it" is, and control returns to vi.
I've found a closed github issue that mentions similar behavior, but a solution was never posted... it appears the problem eventually just "went away" for the OP, so the issue was closed.
However, a second person replied to the issue some time later saying he was having a similar problem and it seemed to happen when git spawned some kind of "credential cache daemon". I'm not using a credential helper as he is, so that's not my exact issue... but that caused me to notice something else:
I have ssh configured to keep connections open for 5 minutes (ControlPersist 5m in my ~/.ssh/config). If I haven't pushed in a while, git push causes ssh to spawn a process to persist the connection. This triggers the issue. After 5 minutes, ssh exits, which will fix the problem and cause the tmux pane to close. If I do another push while the connection is still open, it works fine.
So, the problem seems to be when git spawns another process. This obviously doesn't cause any issues when I run git on the command-line, so why does it cause an issue here? And what can I do about it? I don't want to disable the ssh persistent connections because that's useful...
For anyone who stumbles upon this in the future, I've come up with a solution for my particular case where the ssh process is hanging vim: I disable the ControlPersist option, but only for git commands run inside vim via fugitive by setting the following option in my .vimrc:
let g:fugitive_git_executable = "env GIT_SSH_COMMAND='ssh -o ControlPersist=no' git"
It's ugly, and I'm sad that I have to disable the persistent connections, but it works.
I use tmux (tmux 1.8) from Ubuntu 14.04.
I wanted to configure it a bit via ~/.tmux.conf. But whatever I set inside this file my tmux session looks the same. Then I tried a fresh new /etc/tmux.conf but I still get the same display.
It seems that my config is hardcoded and that I cannot change it.
If I remove these two files (~/.tmux.conf and /etc/tmux.conf) my tmux session is still the same. Tmux runs but I can not configure it. But it should be so simple...
Does anybody have already seen this? And how I could solve that? Do I need to compile a fresh new release of tmux?
Today, I have more details :
on one machine it works as expected. It's OK. But I did not changed anything! Strange...
But on another machine (also running Ubuntu same release and up2date like the first machine) it does not work.
The file /etc/tmux.conf does not exist on none of these 2 machines. I put this little config file (~/.tmux.conf) :
# start Window Numbering at 2
set -g base-index 2
When I launch tmux on this second machine, window numbering starts at 0. On the first machine with the same config file, it behaves correctly : it starts at 2.
I'm going crazy!
After you make changes to ~/.tmux.conf make sure tmux sources them with the tmux source-file ~/.tmux.conf shell command.
Try removing all sessions before running tmux. I have noticed that if you have sessions still running, tmux will still load the previous .tmux.config file.
Executing tmux kill-server can stop the server and then try to run the server again using tmux command.
Please note that after killing the server you will lose all open sessions / tabs.
I have a simple bat file which does the following:
#echo off
mkdir folder1
mkdir folder2
echo.>file1
move file1 folder1\file1
When I run this on Windows 8 it will often hang the shell and explorer.
Interestingly, turning on/off the echo does seem to effect the chance of running into the bug (echo off hits the bug more often it seems) but I can get the bug either way. Suggests a race condition of some kind.
Anyone have an idea why this hangs on Windows 8? It doesn't on Windows 7.
I've also tried this using powershell. It happens less often (had to do it about a hunderd times before I hit the problem) but still occurs.
Turns out the problem was a combo of antivirus and search indexer. Both touch all the files in the FS as soon as they're created. I also suspect that the test machine being a VM has something to do with it (it is likely a little underpowered).
tldr; turning off windows.search from services fixed things.
I'm an android developer. I acquired recently a Samsung Galaxy S3 (I9300) and I am having some problems with it.
The error management doesn't work. I mean, when an app crashes, it doesn't show "Force close", the phone just freezes.
I had an HTC before; I use it when I'm developing too, and with the same malfunctioning app, my HTC shows me force close, but the S3 freezes and I have to restart it.
As you can imagine, this is very annoying.
I found a temporary solution, but it affects wifi. Using this app
https://play.google.com/store/apps/details?id=com.issess.fastforceclose&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5pc3Nlc3MuZmFzdGZvcmNlY2xvc2UiXQ..
and enabling "old fast force close" seems to solve the problem, but it has wifi related problems.
Things I have tried
Clean ROM, wiping data and Dalvik cache (it works at the beginning, but suddenly the phone freezes and when I restart, the error management doesn't work any more)
Delete all apps
What am I missing? How can I resolve this?
see http://forum.xda-developers.com/showthread.php?t=1843837 , especially post #8
quoting:
I finally figured out what "Fast Force Close" app is doing to stop the freeze. It does something rather simple: it basically "hides" the /data/log folder, by moving it aside, and replacing it by a symlink. And this then also, causes Wifi to not connect after a reboot (dunno why)
mv /data/log /data/log_backup
ln -s /dev/null /data/log
To "disable" the fix, it just does the reverse.
Anyway, this got me thinking that the solution was somehow related to stuff happening in that folder. And one of the things happening in that folder, on a Force Close, is that it receives the output of the dumpstate command:
dumpstate -k -t -n -z -d -o /data/log/dumpstate_app_error
So, my solution for the "Freeze instead of Force Close dialog" issue is to put some files in the /data/log folder, with such permissions that dumpstate can not do its thing.
I found this to solve the issue, but I don't know if there are side effects.
If you want to implement this, you can do it in many ways (e.g. even through terminal emulator or probably some root file explorer). I'm attaching a flashable zip that will do this for you. (see XDA link)
Apart from some boilerplate code, the essential bit is this (in updater-script in the zip):
ui_print("Apply fix...");
delete("/data/log/dumpstate_app_error");
delete("/data/log/dumpstate_app_error.txt.gz");
delete("/data/log/dumpstate_app_error.txt.gz.tmp");
package_extract_file("placeholder", "/data/log/dumpstate_app_error");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz.tmp");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz.tmp");
The issue was resolved for me by updating the phone to the latest available android version.