Error screenshot
I've been facing an intermittent issue with pandas profiling widget not rendering & it has been going on and off for awhile.
I've tried this in the command prompt:
jupyter nbextension enable --py widgetsnbextension
it comes up with " - Validating: ok" but still not rendering.
A quick google search led me to a few githubs/pandas-profiling/issues sections but they were a few years old.
I had this problem in Kaggle, I think it is related to memory. It happens when I repeat running my notebook a few times, without restarting the kernel.
To fix it, I just clicked Run, then Restart and Clear Outputs, and it's working again.
I have since then optimized my codes to release memory when done with them, as well as get into the habit of restarting and clearing outputs before a fresh run.
It hasn't happened on my local environment with Jupyter Notebook, probably because I have better memory locally. But if it did happen, I guess I would select Kernel, then Restart and Clear Output.
Related
I use Google Chrome to produce PDFs of webpages. I have noticed that once in a while, Chrome errors out. I started playing with it and from the command line, even when I execute Chrome with the bare minimum of flags, it errors out on occasion. This is the command I run:
google-chrome --headless --no-sandbox
And this is the error I get. But only sometimes. Most of the time, only the two warnings are triggered, and Chrome loads as expected.
[0930/042541.982039:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.
[0930/042542.096418:WARNING:sandbox_linux.cc(380)] InitializeSandbox() called with multiple threads in process gpu-process.
[0930/042542.120932:ERROR:command_buffer_proxy_impl.cc(128)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.
I've been trying to make sense out of the error, but the best I have come up with is that it's related to some sort of memory issue. What's confusing to me is that most of the time, it works fine.
I've gone through the list of flags and tried playing with turning off most of the features I don't need, but even so, the error appears, sometimes. Has anyone experienced a similar issue?
I'm running Ubuntu 20.04.05 LTS with Google Chrome 106.0.5249.61.
Disables GPU hardware acceleration. If software renderer is not in place, then the GPU process won't launch. ↪
https://peter.sh/experiments/chromium-command-line-switches/#disable-gpu
I am working with a 64-bit Windows installer on a 64-bit Windows 10 system that has intermittent crashing issues, where it will crash and close without displaying any kind of error message. This occurs when clicking through the installer's UI, it does not actually attempt to install anything. Collecting a crash dump, I saw that it listed the exception as an "unknown error) 0xC000409. When I ran the crash dump through Visual Studio's debugger in order to obtain information, the message said:
Unhandled exception at 0x00007FFCA685C56F (ntdll.dll) in msiexec__PID__9356__Date__11_01_2021__Time_01_46_34PM__594__Second_Chance_Exception_C0000409.dmp: RangeChecks instrumentation code detected an out of range array access.
The stack trace collected from the crash dump says the following:
ntdll!LdrpICallHandler+f
ntdll!RtlpExecuteHandlerForException+f
ntdll!RtlDispatchException+244
ntdll!KiUserExceptionDispatch+2e
ntdll!LdrpDispatchUserCallTarget+e
msi!CMsiRecord::Release+12e
msihnd!CMsiHandler::CreateControls+18e
msihnd!CMsiHandler::CreateNewDialog+6ba
msihnd!CMsiHandler::RunWizard+564
msihnd!CMsiHandler::DoAction+6e6
msi!MsiUIMessageContext::ProcessMessage+1816
msi!MsiUIMessageContext::RunInstall+1ed
msi!RunEngine+1c9
msi!MsiInstallProductW+11f
msiexec!DoInstallPackage+20e
msiexec!ServerMain+1009
msiexec!WinMain+36
msiexec!__mainCRTStartup+1a0
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
As far as I am aware, there were no major changes made to the installer recently. It just suddenly started getting reported that the installer was crashing, and this was the information that I was able to compile so far. My question is if there's any way to troubleshoot the installer during runtime so that I can get to the bottom of this, or are there any potential fixes I can explore applying? I've done lots of googling on this error and I haven't been able to find a related result yet.
I have also attempted to use ProcMon to see if a file is being blocked but have yet to find anything. I attempted to attach debuggers to the installer to produce a runtime failure, but because it appears to be going into Microsoft code, I can't get a look at the source or the information that it's working with.
I attempted to gather Windows Installer logs, but the log just cuts off at the moment of crashing without displaying any useful exception information. As best as I can gather, the crash occurs when the installer tries to create a dialog.
UPDATE: Some questions:
1) Do you have any custom actions in the setup GUI?
2) Is this a GUI-set from WiX or is it your own, custom GUI?
3) These machines are not Windows 11 are they?
4) Are you installing on a very clean virtual? The below entry in the stack trace makes me wonder if the Visual C/C++ Runtime is installed on the box in the appropriate version?:
msiexec!__mainCRTStartup+1a0
This would seem to refer to "The C runtime Library (CRT)". Please check if it is installed: Microsoft Visual C++ Redistributable Latest Supported Downloads.
Logging
Verbose logging with extra debugging information (very slow) - Comprehensive answer on logging:
msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log
Quick Parameter Explanation:
/i = run install sequence
/L*vx! C:\Your.log = verbose debug logging at specified path
The x adds extra debugging information, and the ! disables the log buffer. This means there is no lost log if there are any crashes.
Silent Installation
I am wondering if the crash comes from the setup GUI alone. If this is the case you might be able to install the setup silently successfully (since this bypasses the GUI entirely). Please try this? If this fails too, perhaps it is the Visual C/C++ runtime that is missing? Or likely something else. Logging is essential as explained above.
msiexec.exe /i c:\setup.msi /QN /L*V "C:\Temp\msilog.log"
Quick Parameter Explanation:
/L*V "C:\Temp\msilog.log"= verbose logging
/QN = run completely silently
/i = run install sequence
You can throw in the exclamation mark for continuous logging (no log buffer) here as well, but that will slow the installation down a lot.
Links:
Answer on silent installation here
Comprehensive answer on MSI logging
https://www.advancedinstaller.com/user-guide/read-log.html
Some time ago, I've deployed a YouTrack5 instance on OpenShift, using this excellent tutorial. It works fine and smoothly.
Now, I want to install YouTrack6. Unfortunately, the same method can't be used for it, as since version 6 YouTrack .war file is no longer available.
So, I've tried to deploy YouTrack6 jar via a DIY cart, which should be ok, as the jar can be run standalone.
This is the command line that I've provided in the
.openshift/action_hooks/start script:
nohup /usr/lib/jvm/java-1.7.0/bin/java -Xmx1g -XX:MaxPermSize=250m -Djetty.home=$OPENSHIFT_DATA_DIR -Duser.home=$OPENSHIFT_DATA_DIR -Ddatabase.location=${OPENSHIFT_DATA_DIR}teamsysdata -Djava.awt.headless=true -jar ${OPENSHIFT_REPO_DIR}youtrack-6.0.12463.jar ${OPENSHIFT_DIY_IP}:${OPENSHIFT_DIY_PORT} &
Indeed, it works, the application is deployed and started - BUT: it is very unstable, looks like it crashes and caused to restart after just every few actions.
From the logs, I couldn't understand where the problem lies, looks like on YouTrack's side everything's ok.
My question is - what can be the problem that causes this unstable behavior, and is there any way to work around it (maybe by changing the command line flags, etc.)?
I am just getting started with Packer, and have had several instances where my build is failing and I'd LOVE to log in to the box to investigate the cause. However, there doesn't seem to be a packer login or similar command to give me a shell. Instead, the run just terminates and tears down the box before I have a chance to investigate.
I know I can use the --debug flag to pause execution at each stage, but I'm curios if there is a way to just pause after a failed run (and prior to cleanup) and then runt he cleanup after my debugging is complete.
Thanks.
This was my top annoyance with packer. Thankfully, packer build now has an option -on-error that gives you options.
packer build -on-error=ask ... to the rescue.
From the packer build docs:
-on-error=cleanup (default), -on-error=abort, -on-error=ask - Selects what to do when the build fails. cleanup cleans up after the previous steps, deleting temporary files and virtual machines. abort exits without any cleanup, which might require the next build to use -force. ask presents a prompt and waits for you to decide to clean up, abort, or retry the failed step.
Having used Packer extensively, the --debug flag is most helpful. Once the process is paused you SSH to the box with the key (in the current dir) and figure out what is going on.
Yeah, the way I handle this is to put a long sleep in a script inline provisioner after the failing step, then I can ssh onto the box and see what's up. Certainly the debug flag is useful, but if you're running the packer build remotely (I do it on jenkins) you can't really sit there and hit the button.
I do try and run tests on all the stuff I'm packing outside of the build - using the Chef provisioner I've got kitchen tests all over everything before it gets packed. It's a royal pain to try and debug anything besides packer during a packer run.
While looking up info for this myself, I ran across numerous bug reports/feature requests for Packer.
Apparently, someone added new features to the virtualbox and vmware builders a year ago (https://github.com/mitchellh/packer/issues/409), but it hasn't gotten merged into main.
In another bug (https://github.com/mitchellh/packer/issues/1687), they were looking at adding additional features to --debug, but that seemed to stall out.
If a Packer build is failing, first check where the build process has got stuck, but do the check in this sequence:
Are the boot commands the appropriate ones?
Is the preseed config OK?
If 1. and 2. are OK, then it means box has booted and the next to check is the login: SSH keys, ports, ...
Finally any issues within the provisioning scripts
So I thought I would install Lazarus/Free pascal -latest version from the sourceforge website.
Downloaded the win32 version and install on my XP machine couple of nights ago.
Problem is, it can't seem to find any of its own files.
From the first and every subsequent run it comes up with an error which says it can't find its system.ppu file relating to win32.
I just ignore that error and it seems to still run.
I tried to make a simple calculator application and it couldn't even seem to find the system files or files in the project directory. After battling these problems and setting every single path I could find in all the setups to every directory I could find it eventually compiled and run the program - once, not been able to make it do it again.
I also tried to make a user component library following the instructions on the web and that won't work either because, you guessed it, it can't the files. This time it gives an error saying it can't find a Ttreeview component, despite not even using that component in the library.
Being able to follow search paths is pretty fundamental stuff that they don't seem to have mastered.
Anybody managed to get a working system going, or any tips to sort these problems out?
Did you install in the default directory c:\lazarus? I thought there was an issue with installing to another directory, especially if the path contains spaces.
Nine times out of ten, its the old config of an earlier Lazarus attempt, that still lingers somewhere in the "local app" part of the profile.
If nothing else helps uninstall Lazarus, download Lazarus CodeTyphon edition, and run install as admin.