I get a slightly heisen error from eventmachine (0.12.10, on OSX 10.6.4):
terminate called after throwing an instance of 'std::runtime_error'
what(): no loop breaker
It only occurs in tests, and only when all tests are run together. Run individually they pass.
I spotted the only place in the eventmachine code that mentions the error's message:
http://github.com/eventmachine/eventmachine/blob/master/ext/em.cpp#L333
(What puzzles me as well is that it looks like a win32 code path, or am I wrong?)
To me it looks like some ressource like sockets are used up. That would explain the occurence pattern.
Ok, I found it myself.
The error comes in fact from the win32 conditionally compiled code. I get a plain old "Too many open files" error if I build locally, and that problem is easy to releave by increasing the ulimit value for open files (which is said to be quite modest by default on OSX).
ulimit -n 1024 # or whichever value you find appropriate
(Default is 255, look at the output of ulimit -a)
If I build and install from the cloned git repository using rake gem:install, I get the expected (Unix) error message. So the bug appears to be fixed in master.
Filed bug for the rubygems.org gem is here: http://github.com/eventmachine/eventmachine/issues#issue/88
Related
When using chromedriver 2.29 and watir-webdriver to drive a chrome browser on Windows 7 during automated tests or using IRB(interactive ruby shell) I constantly see errors and warnings written to standard output while the browser is in use.
Errors like this:
ERROR:gl_surface_egl.cc(690)] eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type
This makes it difficult to use IRB because of the error text constantly getting in the way. It also makes test output in rspec really problematic and hard to read because of all the NOISY ERRORS/WARNINGS.
How can all these errors be silenced? I've tried to load up the browser with the --silent option that chromedriver has and this hasn't stopped the errors.
Updated to latest:
Chrome: Version 60.0.3112.78 (Official Build) (64-bit)
AND chromedriver: version 2.30
No longer seeing the issue.
Well if you want to ignore these errors you can use exceptions to ignore all the errors, you can read about how to do this here if you don't already know: https://www.tutorialspoint.com/ruby/ruby_exceptions.htm
If you want to keep the errors but make less clutter I would either write the errors to an error log file or write the text to an output log file.
Hope this helped!
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I installed the Heroku Toolbelt following the instructions provided by RailsBridge's Installfest for Windows. I am running Windows 10 64-bit and the Command Prompt with Ruby and Rails provided by RailsBridge.
Each heroku command I attempt to input, be it 'version', 'login', or what have you, I get this:
heroku-cli: Adding dependencies... done
heroku-cli: Installing core plugins...Error reading plugin: heroku-cli addons.
Then I see a list of which plugins that there were reading errors for. The list is:
heroku-apps;
heroku-fork;
heroku-git;
heroku-local;
heroku-run;
heroku-status
Then:
ERROR: runtime error: invalid memory address or nil pointer dereference
Then it repeats this, adding dependencies, attempting to install core plugins, same reading plugin errors, but then after the runtime error runs again, it prints this:
! error getting commands pid 5052 exit 1
Previously, it was 'error getting commands pid 6912' or something like that. I looked around a bit and didn't see anything that specifically dealt with this, but I am sorry if I missed it before asking this question. I'm very new at this.
I would really appreciate any help or advice on how to correct this. I thank you very much ahead of time!
Edit: I now understand what pid is. Using another resource, I was told to check for the pid process in my task manager. I reran this process, got a different pid number, and searched for it in my task manager but to no avail. It isn't storing it.
I had the same problem and Heroku support team was quick to answer with:
can you delete ~/.heroku/heroku-cli and try again?
Next time you run a heroku command it will reinstall the toolbelt. Worked for me.
According to the support team it happened because:
It was a bug that was pushed yesterday we fixed this morning that some users ran into.
Good luck!
I had a problem with Terminal a Jekyll install but I didn't spot the site being not-uploaded to the server by rsync because I didn't see an error in the output. So, I was wandering:
Is there any way to make Terminal detect errors and give them a specific color?
My error here was:
rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-42/rsync/io.c(452) [sender=2.6.9]
It had other things, but if this line was highlighted, I would have spotted it way earlier.
Generally speaking, color output is a responsibility of a program and not a terminal.
For example, clang compiler produces colorful error and warning messages.
If the application you are using does not support this, the only option is to create a wrapper and parse its output, highlighting errors in different color. This approach is taken by colorgcc, for instance, to make GCC compiler output in colors.
Perhaps you can grab that script and adjust it for your needs? Check it out here - https://github.com/colorgcc/colorgcc
Also, if there are errors, the app should probably exit with non-zero exit code. It might be a good idea to check it and write an even bigger and noticeable message upon exit in case of errors.
Hope it helps.
Good luck!
You can enable highlighting of errors for one command with the hilite utility. It only works for commands you type hilite for – it isn’t enabled globally – but it’s still useful if you know or suspect that a command outputs errors and you want to locate them. So when you build with jekyll, you could do any of the following:
Change jekyll … to hilite jekyll … in your build script
Try to remember to always type hilite before jekyll
Run jekyll normally, but if its output or exit code makes you suspect you got errors, run it again with hilite to locate them
On OS X, you can install hilite with Homebrew using brew install hilite.
I am trying to install Maglev on Mac OS X Lion with rvm, but running
rvm install maglev
as instructed on the github page only yields a 404 error:
curl: (22) The requested URL returned error: 404
ERROR: The requested url does not exist: 'http://glass-downloads.gemstone.com/maglev/MagLev-26852.Darwin-i386.tar.gz'
which does not seem too helpful, as it just points out that the respective file does not exist on the gemstone server. Google does not seem to know about this, so I thought about asking a question here. However, before doing so I tried some more and and got a little further running
rvm install maglev-head
as mentioned in some blog posts. This finally finds an appropriate file, downloads a bunch of things and starts to compile. It starts to look really well at a point where it says
Installing maglev to /[user-dir]/.rvm/rubies/maglev-head
in green, but unfortunately it does not get much further. The installation hangs after saying
Creating default 'maglev' repository.
Generating maglev HTML documentation
Generating smalltalk FFI.
or at least it takes forever (more than 30 minutes) without saying anything.
Stopping the installation at this point still looks promising giving me
$ rvm list
rvm rubies
maglev-head [ x86_64 ]
but unfortunately
rvm use maglev-head
results in
startstone[Info]: Starting Stone repository monitor 'maglev'.
startstone[Error]: Stone process (id=61119) has died.
startstone[Error]: Examine '/[user-dir]/.rvm/rubies/maglev-head/log/maglev/maglev.log' for more information. Excerpt follows:
without displaying an excerpt and even without stopping. Actually the log file does exist and has a few error messages, the most telling seems to be
GemStone is unable to open the file !TCP#localhost6#dbf!/[user-dir]/.rvm/rubies/maglev-head/data/maglev/extent/extent0.ruby.dbf
but the directory does exist, it would just be the file that is missing, and I would expect the server to create that one on an new image. Still, the situation does not look too bad as i get
which irb
giving me
/[user-dir]/.rvm/rubies/maglev-head/bin/irb
but when I try to start up irb I get
maglev-ruby: [Error] The MagLev server "maglev" is not running.
To fix this run "rake maglev:start" before running maglev-ruby.
but if I call the rake task as instructed I again get
maglev-ruby: [Error] The MagLev server "maglev" is not running.
To fix this run "rake maglev:start" before running maglev-ruby.
putting me in a recursive causality loop. Trying to start the maglev server by hand using
maglev start
as I did on a previous installation using the shell scripts does not work either, giving me
startstone[Info]: Starting Stone repository monitor 'maglev'.
startstone[Error]: Stone process (id=61400) has died.
startstone[Error]: Examine '/[user-dir]/.rvm/rubies/maglev-head/log/maglev/maglev.log' for more information. Excerpt follows:
again without displaying an excerpt and hanging.
Any help would be appreciated as Maglev looks like a really promising piece of infrastructure.
You need to do "rvm get head" first; I can see it was looking for MagLev-26852.Darwin-i386.tar.gz, which was for an older version both of MagLev and of RVM.
I'd do an "rvm remove maglev; rvm install maglev" It shouldn't take more than a few minutes then to build once it's downloaded.