Recently I wanted to try the gvim7.2 for its wonderful support of CSCOPE and installed it from my company's installation directory. However, when I execute it - I get a segmentation fault and the message looks thus,
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)
When I was searching for this issue in the online forums, I found general complaints about the reproducibility of the issue. Any insights on this would be greatly appreciated.
I have had crashes with incompatible shared libraries for Python3 IIRC.
I never got ultisnips working on Ubuntu Natty 64 for that very reason.
Removing the plugin made vim start normally (probably by not loading the incompatible library in the first place).
You may disable your plugins and reenable them one by one to see whether Python is the culprit, or test directly:
gvim -u NONE +'python3 print "test"'
On my box:
Fatal Python error: take_gil: NULL tstate
Vim: Caught deadly signal ABRT
Vim: Finished.
Conversely,
gvim -u NONE +'python2 print "test"'
Works correctly
This surely took me a long time to debug, I indeed went through the painful process of manually disabling every plugin that I had installed and yet the same error kept popping up.
[Solution] : It turned out that the gvim is tightly bound to the graphics settings used. We use a citrix client to remote login into UNIX servers and develop from there. As per my colleague's suggestion - I changed the color settings to "True Color 24 bit" and voila!!, things worked perfectly.
One of the classic examples of the times when we get hit by totally unsuspecting source of bugs!
Anyways, thanks for all your suggestions - I learned a lot :).
Try verbose logging,
vim -V10/tmp/vim.log
You can also try running strace to see where it is bombing,
strace vim
It's possible that it's a permissions issue, but that's a guess.
try starting Vim like so:
$ vim -u NONE
which will disable all plugins to see if the problem still persists.
If it starts OK, move all the plugins from Vim's runtime directory (usually):
~/.vim/
on Linux & add them back one by one until the seg fault occurs.
Can be a tedious process especially as there may be a conflict between two or more plugins & in that case, it hard to ascertain when exactly they clash, but nine times out of ten, it usually gets you to the root of the problem.
Related
I've searched for a similar problem on google but didn't find exactly what I face. I've ever uploaded dSYMs in Firebase before and used the same command
/path/to/pods/directory/FirebaseCrashlytics/upload-symbols -gsp /path/to/GoogleService-Info.plist -p ios /path/to/dSYMs
, but when I try to do it again on other days, now it says that:
[1] 13901 illegal hardware instruction -gsp -p ios /Users/jeffry_sandy/Downloads/appDsyms.zip~
(number 13901 keep changing whenever I try to upload the file), I'm using Mac OS Monterey, and XCode Version 12.5 (12E262).
I use the same format before that works with me, I still didn't understand what this illegal hardware meant, I try to run as admin, and still doesn't work. Can anyone help me please..
I am learning to program in Python and Rust. On different versions of Ubuntu these programs compiled and ran perfectly. Now that I have a dedicated Fedora 30 KDE system, every time I try and build a program, I get a warning: Failed to load module "appmenu-gtk-module"
I have tried looking this up and have re/installed anything GTK on my system. The programs otherwise function well, but no menus are drawn. I was also trying things in GNOME and hit the same thing.
I am also using QT. Those programs also build and run fine, but again, no menu.
I'm going bonkers with this. Any help is appreciated.
The appmenu-gtk module is not packaged on Fedora. (GNOME doesn't support them anyway.)
The real questions are:
Why is it configured to load? Did you copy or share GTK config files from an Ubuntu system? You should remove this module from your settings.
Even with improper configs I don't believe this should result in menus not appearing. It should just fail to load and work as normal. How is your application using menus?
I finally got so fed up with getting this error that I went full nerd-diagnosis, and ran this command to find out which file contained the errant reference to the appmenu-gtk (the package that would provide this is not installable on my system either).
(Replace "dolphin" with the command that is giving you the error.)
strace -e openat,access dolphin 2>&1 |grep -v ENOENT |awk '/appmenu-gtk/ {exit} !/appmenu-gtk/ {print}'|cut -d '"' -f2 |sort|uniq|xargs grep appmenu-gtk 2>/dev/null
This will then give you a list of files which contain the line appmenu-gtk, and in my case it was ~/.config/gtk-3.0/settings.ini. From there I just commented it out, and that gets rid of the error message (not sure if this will fix your problem of not having any menus, but you might just be able to edit that line to fix it in another way if commenting it out doesn't work).
I want to view an image in Jupyter notebook. It's a 9.9MB .png file.
from IPython.display import Image
Image(filename='path_to_image/image.png')
I get the below error:
IOPub data rate exceeded.
The notebook server will temporarily stop sending output
to the client in order to avoid crashing it.
A bit surprising and reported elsewhere.
Is this expected and is there a simple solution?
(Error msg suggests changing limit in --NotebookApp.iopub_data_rate_limit.)
Try this:
jupyter notebook --NotebookApp.iopub_data_rate_limit=1.0e10
Or this:
yourTerminal:prompt> jupyter notebook --NotebookApp.iopub_data_rate_limit=1.0e10
I ran into this using networkx and bokeh
This works for me in Windows 7 (taken from here):
To create a jupyter_notebook_config.py file, with all the defaults commented out, you can use the following command line:
$ jupyter notebook --generate-config
Open the file and search for c.NotebookApp.iopub_data_rate_limit
Comment out the line c.NotebookApp.iopub_data_rate_limit = 1000000 and change it to a higher default rate. l used c.NotebookApp.iopub_data_rate_limit = 10000000
This unforgiving default config is popping up in a lot of places. See git issues:
jupyter
IOPub data rate exceeded
It looks like it might get resolved with the 5.1 release
Update:
Jupyter notebook is now on release 5.2.2. This problem should have been resolved. Upgrade using conda or pip.
Removing print statements can also fix the problem.
Apart from loading images, this error also happens when your code is printing continuously at a high rate, which is causing the error "IOPub data rate exceeded". E.g. if you have a print statement in a for loop somewhere that is being called over 1000 times.
By typing 'jupyter notebook --NotebookApp.iopub_data_rate_limit=1.0e10' in Anaconda PowerShell or prompt, the Jupyter notebook will open with the new configuration. Try now to run your query.
Some additional advice for Windows(10) users:
If you are using Anaconda Prompt/PowerShell for the first time, type "Anaconda" in the search field of your Windows task bar and you will see the suggested software.
Make sure to open the Anaconda prompt as administrator.
Always navigate to your user directory or the directory with your Jupyter Notebook files first before running the command. Otherwise you might end up somewhere in your system files and be confused by an unfamiliar file tree.
The correct way to open Jupyter notebook with new data limit from the Anaconda Prompt on my own Windows 10 PC is:
(base) C:\Users\mobarget\Google Drive\Jupyter Notebook>jupyter notebook --NotebookApp.iopub_data_rate_limit=1.0e10
I have the same problem in my Jupyter NB on Win 10 when querying from a MySQL database.
Removing any print statements solved my problem.
For already running docker containers, try editing the file name - ~/.jupyter/jupyter_notebook_config.py
uncomment the line - NotebookApp.iopub_data_rate_limit =
and set high number like 1e10.
Restart the docker, it should fix the problem
I ran into this problem running version 6.3.0. When I tried the top rated solution by Merlin the powershell prompt notified me that iopub_data_rate_limit has moved from NotebookApp to ServerApp. The solution still worked but wanted to mention the variation, especially as internal handling of the config may become deprecated.
Easy workaround is to create a for loop and print. Then there wont be any issue. Printing directly wcc would cause if graph is huge. Hence any of below code will work as workaround.
wcc=list(nx.weakly_connected_components(train_graph))
for i in range(1,10):
print(wcc[i])
for i in wcc):
print(wcc)
Like others pointed out, print statement at a high rate can cause this. Resolve it by printing modulo a number using if statement. Example in python:
k = 10
if (i % k == 0):
print("Something")
Increase k if the warning persists.
Using Visual Studio Code, the Jupyter extension will be able to handle big data. launch from anaconda navigator
In general, trying to print something that is too long will trigger this error. I tried to print a string that was 9221593 characters long (too long), and that triggered the error.
I'm trying to move our projects to Java 8. When I run a compile I get this:
[error] (MyProject/compile:compileIncremental) javac returned nonzero exit code
This doesn't happen with Java 7. I suspect it's something to do with us using Lombok.
Is there any way to get the actual output from the javac? I've tried "last" and "lastgrep" but I only see SBT logs.
I'm using SBT 0.13.8
Thanks.
Ashley
When javaHome setting is set, sbt calls javac by forking the process, and attempts to screen scrape the error message out of the output, which is error-prone. sbt 1.2.0-RC3 improves it a bit, but it's a hack.
One way to avoid that is to make sure javaHome setting is set to None. Around 2015 sbt-extras used to set javaHome quietly from JAVA_HOME environment variable, but I think that's been dropped since 2016 in https://github.com/paulp/sbt-extras/pull/160. Since this question was asked in June 2015, maybe that's what it was hitting at the time. If you're using sbt-extras, please update to the latest.
This might be further supported by Parag's answer/observation:
The error message disappeared on my Mac when I removed the JAVA_HOME variable in .bash_profile and then restarting Terminal.
If you continue to see this issue using sbt 1.x, please report on https://github.com/sbt/zinc/issues/520
I had SBT 0.13.9, RHEL and OpenJDK1.8 installed and was getting the same error (no further stack trace), and swapping to Oracle's JDK fixed it. Probably some issue with javac-configuration, but didn't manage to quickly fix it with the OpenJDK. Probably not the best solution though.
The error message disappeared on my Mac when I removed the JAVA_HOME variable in .bash_profile and then restarting Terminal.
I downloaded Vim 7.3 and installed it on my Windows7 64 bit system. I coded a simple python 3.4 program and tried to run it without success using the :!python COMMAND. When I checked version, bottom of output said:
Dependency: python27.dll, python33.dll, x64-msvcrt-ruby200.dll, lva52.dll, libintl.dll, lidiconv.dll, iconv.dll.
When I checked, python27.dll is not found on my system at all, python33.dll is in a directory for a program called "Autodesk 123D Design". I didn't check for the others yet. Can someone explain if these are required and if so, where they go? I have no idea why they would not have downloaded with the program during install.
They are used for writing vim plugins in Python. They are not required for normal operation.
They are also unrelated to your problem; check the value of %PATH% to see if python.exe is accessible.