PG::ConnectionBad(connection is closed) when running rspec after upgrading application from Rails 5.2 to 6.0 - ruby-on-rails-6

I tried to upgrade my application from Rails 5.2 to 6.0, after upgrading when run rspec it raises error PG::ConnectionBad: connection is closed.
The error is caused by the expression ActiveRecord::Migration.maintain_test_schema! in rails_helper.rb and the error is as follows,
root#00de976cbbd4:/app# rspec
An error occurred while loading rails_helper.
Failure/Error: ActiveRecord::Migration.maintain_test_schema!
PG::ConnectionBad:
connection is closed
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/postgresql/quoting.rb:21:in `escape_string'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/postgresql/quoting.rb:21:in `quote_string'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/abstract/quoting.rb:220:in `_quote'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/postgresql/quoting.rb:144:in `_quote'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/abstract/quoting.rb:18:in `quote'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/postgresql/schema_statements.rb:750:in `quoted_scope'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/postgresql/schema_statements.rb:727:in `data_source_sql'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/connection_adapters/abstract/schema_statements.rb:62:in `table_exists?'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/internal_metadata.rb:32:in `table_exists?'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/tasks/database_tasks.rb:347:in `schema_up_to_date?'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:594:in `block in load_schema_if_pending!'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:593:in `all?'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:593:in `load_schema_if_pending!'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:614:in `block in maintain_test_schema!'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:867:in `suppress_messages'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:619:in `method_missing'
# /usr/local/bundle/gems/activerecord-6.0.3.5/lib/active_record/migration.rb:614:in `maintain_test_schema!'
# ./spec/rails_helper.rb:30:in `<top (required)>'
No examples found.
No examples found.
I can launch RAILS_ENV=test rails c and run ActiveRecord::Migration.maintain_test_schema! in console without errors. And also tried to upgrade rspec from 3.10.1 to 4-0-dev but still got the same error. Thanks in advance.

Finally I created a new rails 6 app and then copy file by file to check what caused this error, it turns out that in my spec/support folder there is a file shared_db_conntection.rb which has following content, which is copied from this blog http://blog.plataformatec.com.br/2011/12/three-tips-to-improve-the-performance-of-your-test-suite/
class ActiveRecord::Base
mattr_accessor :shared_connection
##shared_connection = nil
def self.connection
##shared_connection || retrieve_connection
end
end
ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
After remove this file there is no such error

Related

"getNativeWindowHandle+0x54" on Gluon JavaFX 16 EA 4 via DRM

I was following the steps given at Gluon Documentation to run JavaFX on Raspberry Pi 4 via DRM. I downloaded the JavaFX EA 16 builds from here.
javafx.properties file :
javafx.version=16-internal
javafx.runtime.version=16-internal+28-2020-11-10-180413
javafx.runtime.build=28
After cloning the samples repository containing hellofx, I compiled it via javac (according to the steps) and then ran this command to run it using DRM:
sudo -E java -Dmonocle.platform=EGL -Djava.library.path=/opt/arm32hfb-sdk/lib -Dmonocle.egl.lib=/opt/arm32fb-sdk/lib/libgluon_drm.so --module-path /opt/arm32fb-sdk/lib --add-modules javafx.controls -cp dist/. hellofx.HelloFX
However, this caused the following error :
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x9c3314dc, pid=734, tid=746
#
# JRE version: OpenJDK Runtime Environment (11.0.9+11) (build 11.0.9+11-post-Raspbian-1deb10u1)
# Java VM: OpenJDK Server VM (11.0.9+11-post-Raspbian-1deb10u1, mixed mode, serial gc, linux-)
# Problematic frame:
# C [libgluon_drm.so+0x14dc] getNativeWindowHandle+0x54
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/pi/samples/CommandLine/Modular/CLI/hellofx/hs_err_pid734.log
#
# If you would like to submit a bug report, please visit:
# Unknown
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted
It seems that while loading libgluon_drm.so in JavaFXSDK/lib/ fails at getNativeWindowHandle
What's weird is that after I ran sudo apt install libegl* mesa* libgl*, it actually succeeded but was asking me to set variable ENABLE_GLUON_COMMERCIAL_EXTENSIONS as true, which I had already done.
However, after rebooting, it started showing the same error.
I am using a Raspberry Pi 4 Model B with 2GB RAM. It is running on Raspberry Pi OS 32-Bit with desktop.
I had performed all of this on a clean installation.
Pi4 has both vc4 for render, and v3d for 3D. You can probe the devices for their capabilities - only one should acknowledge that it has DRIVER_RENDER or DRIVER_MODESET capabilities.
Pi4 DRM questions
The card which JavaFX selects by default is /dev/dri/card1. In my case, /dev/dri/card0 was the one to be used for render, and not card1. I solved the issue by using the following runtime argument :
-Degl.displayid=/dev/dri/card0
The JavaFX Version I used was 16-ea+5.

How configure Rspec deprecation_stream so it logs deprecation warnings to a file?

In a Rails 5.0.7 app that is about to being upgraded to 5.1, we'd like to capture all the (many) deprecation warnings to a file.
Rspec 3.9 provides a pretty clear example of how to send deprecations to a text file:
https://relishapp.com/rspec/rspec-core/v/3-9/docs/configuration/custom-deprecation-stream
But it doesn't work:
# spec/spec_helper.rb
RSpec.configure do |config|
config.deprecation_stream = File.open('deprecations.txt', 'w')
end
When I run a spec that has warnings without the code above, stdout displays a bunch of instances of:
DEPRECATION WARNING: uniq is deprecated and will be removed from Rails 5.1 (use distinct instead) (called from...
If I add the config.deprecation_stream code above, and re-run the same spec:
the deprecation warnings no longer are shown on stdout as the specs run
the file deprecations.txt IS created, but
the file is blank.
How do I configure Rspec's deprecation_stream so it works as expected, eg, sends all deprecation warnings to a file?
To catch the Rails deprecation messages you can use active_support.deprecation option:
# config/environments/test.rb
config.active_support.deprecation = ->(message, callstack, deprecation_horizon, gem_name) {
# Do anything you want with the deprecation (append to a file, send to an external service, etc.)
puts "!!! [#{gem_name}] #{message}", callstack[0..2]
}
This will produce an output like:
!!! [Rails] DEPRECATION WARNING: ActiveRecord::Base.allow_unsafe_raw_sql= is deprecated and will be removed in Rails 6.2 (called from old_method at /my_project/app/models/post.rb:36)
/my_project/app/models/post.rb:36:in `old_method'
/my_project/spec/models/post_spec.rb:36:in `block (3 levels) in <main>'
/my_gems/rspec-core-3.10.1/lib/rspec/core/memoized_helpers.rb:317:in `block (2 levels) in let'
RSpec deprecation_stream is useful with RSpec's deprecations.
From the docs, an example can be:
class Foo
def bar
RSpec.deprecate "Foo#bar"
end
end

JDK 9 SIGSEGV Fatal Error

Running eclipse plugin with a WebView component ends with SIGSEGV error, which happens to be an ancient bug as in here.
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000013a06a254, pid=23881, tid=775
#
# JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C [libjfxwebkit.dylib+0x5ff254] WebCore::FrameTree::top() const+0x4
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Applications/Eclipse.app/Contents/MacOS/hs_err_pid23881.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Is there any new configuration or vm parameter we are missing specific to Java 9 ?

JuliaBox - LoadError: unlink: read-only file system (EROFS) Failed to precompile .julia/lib/v0.4/PyCall.ji

I'm running a small Julia program using PyPlot in Juliabox (IJulia Notebook) but it's errors out with an error mesg as listed below. I not sure if it's trying to use my machine's disk to write to but I have valid R+W access there. Basically I'm trying out the examples as mentioned here: https://www.juliabox.org/notebooks/tutorial/Plotting%20in%20Julia.ipynb#
LoadError: unlink: read-only file system (EROFS)
Pkg.add("PyPlot")
using PyPlot
for i = 1.0:300.0
for j = 1.0+i:250.0, k=1.0:10
plot(i+j, i*k/j, color="red", linewidth=1.0, linestyle="--")
i += 0.1
j += 0.05
k += 0.01
end
end
Error log:
INFO: Nothing to be done
INFO: Precompiling module PyPlot...
INFO: Recompiling stale cache file /opt/julia_packages/.julia/lib/v0.4/Compat.ji for module Compat.
ERROR: LoadError: unlink: read-only file system (EROFS)
in unlink at fs.jl:102
in rm at file.jl:59
in create_expr_cache at loading.jl:330
in recompile_stale at loading.jl:461
in _require_from_serialized at loading.jl:83
in _require_from_serialized at ./loading.jl:109
in require at ./loading.jl:219
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:304
[inlined code] from none:2
in anonymous at no file:0
in process_options at ./client.jl:257
in _start at ./client.jl:378
while loading /home/juser/.julia/v0.4/PyCall/src/PyCall.jl, in expression starting on line 26
ERROR: LoadError: Failed to precompile PyCall to /home/juser/.julia/lib/v0.4/PyCall.ji
in error at ./error.jl:21
in compilecache at loading.jl:384
in require at ./loading.jl:224
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:304
[inlined code] from none:2
in anonymous at no file:0
in process_options at ./client.jl:257
in _start at ./client.jl:378
while loading /home/juser/.julia/v0.4/PyPlot/src/PyPlot.jl, in expression starting on line 5
LoadError: Failed to precompile PyPlot to /home/juser/.julia/lib/v0.4/PyPlot.ji
while loading In[10], in expression starting on line 2
in error at ./error.jl:21
in compilecache at loading.jl:384
in require at ./loading.jl:250
If I use 0.3.12 version (IJulia Notebook), then it compiles and shows INFO: Nothing to be done but doesn't show anything as output (some graphics plot diagram etc).
Thanks to ali_m. Here's the main summary on what that post says.
The problem seems to be that JuliaBox ships some precompiled cache files in a read-only directory /opt/julia_packages/.julia/lib/v0.4. If at some point it detects that the cache is stale and tries to recompile it, it fails.
This needs to be fixed in Julia itself—it shouldn't try to delete cache files from a read-only directory when recompiling.
Issue link is https://github.com/JuliaLang/julia/issues/14368
To resolve it only in 0.4.2, one can use (this will remove the 3rd index value from Base.LOAD_CACHE_PATH array/set/tuple) to your .juliarc file on JuliaBox to remove the read-only cache directory from the search path. Or just run this manually before typing using Compat etc to rebuild the cache without using the read-only search path.
splice!(Base.LOAD_CACHE_PATH, 3)
A nice example of splice! function
(PS: A function in Julia which ends with ! with its names means, that function will not only do its work but also will change its arguments data/value).
# Remove elements from an array by index with splice!
arr = [3,4,5]
splice!(arr,2) # => 4 ; arr is now [3,5]
The suggested workaround works for 0.4.2 (using echo 'splice!(Base.LOAD_CACHE_PATH, 3)' > ~/.juliarc.jl to insert the line into juliarc) but apparently LOAD_CACHE_PATH isn't defined while launching Julia 0.3.12 so this would fail there.
Adding the following line in the same file fixed this issue (adding a condition to work when version in Julia is 0.4 or above). I didn't see this issue in the 0.5 development version so we are good there.
VERSION >= v"0.4" && splice!(Base.LOAD_CACHE_PATH, 3)

RStudio/R crashes when running script with data.table in Debian

While working in data.table I suddenly have crashes in while running a script that did not have problems before. The script runs in Windows, but crashes in my Linux Xubuntu 64 bit machine. I cannot reproduce the error.
The message I get is :
Error in mult %chin% c("first", "last", "all") :
Internal error: savetl_init checks failed (0 100 0x50a6b90 0x82141d0).
Please report to datatable-help.
The crash occurs at the moment when I try to set a key:
setkey(vars,parameter)
but earlier the crash occurred at different places - I can't localize it.
Other crash message I have seen occurring:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00007f5ffecdcd50, pid=6368, tid=140050620934144
JRE version: OpenJDK Runtime Environment (7.0_51) (build 1.7.0_51-b00)
Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
Problematic frame:
C [datatable.so+0x12d50] cradix_r+0x60
Failed to write core dump. Core dumps have been disabled.
To enable core dumping, try "ulimit -c unlimited" before starting Java again
When running in R [so not in RStudio] I get:
*** caught segfault ***
address 0xffffffffb3e13480, cause 'memory not mapped'
Traceback:
1: forder(x, cols, sort = TRUE, retGrp = FALSE)
2: setkeyv(x, cols, verbose = verbose)
3: setkey(vars, parameter)
4: eval(expr, envir, enclos)
5: eval(ei, envir)
6: withVisible(eval(ei, envir))
7: source("check_dt3.R")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Does anybody know what is happening here? [the only things I can think of are switching to Sun Java, re-installing RStudio, re-installing R].
Just to answer and open qestion.
Issue has been reported #20 and resolved on the same day.
The question is irrelevant for 1.9.2+ versions of data.table.

Resources