Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way to illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R called Deducer. I am able to install without a hitch and even bring it up and run some functions and graphical displays. However, when I ask it to do a few specific functions, the windows all come crashing down. So, my question is: how do I figure out the source of the problem? I have used this program for years, and including last spring under F31, and linux has never been an issue. This has been tried on three F32 machines by me and a former student and all have resulted in crashes. Embarrasingly, these continue to work as expected with Windows and MacOS, though installation, especially for the latter is a pain.
How can I get error messages out of this mishap to file a meaningful and targeted bug report?
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I need R-core installed, as well as curl-devel, and of course java. Other fedora packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any are fine, the first one is from rstudio.com. Also, the installation function may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a jaguar logo (pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" -> "Quick" -> "simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR comes crashing down.
Btw, since I know the commands to give in R, on the commandline, when I call the function, things work as expected. It is only on the JGR() window that it crashes.
The worst part? I get no error messages. So, how can I get error messages out of this mishap to file a meaningful and targeted bug report?
Many thanks and best wishes, Ranjan
On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra maitra@email.com wrote:
Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way to illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R called Deducer. I am able to install without a hitch and even bring it up and run some functions and graphical displays. However, when I ask it to do a few specific functions, the windows all come crashing down. So, my question is: how do I figure out the source of the problem? I have used this program for years, and including last spring under F31, and linux has never been an issue. This has been tried on three F32 machines by me and a former student and all have resulted in crashes. Embarrasingly, these continue to work as expected with Windows and MacOS, though installation, especially for the latter is a pain.
It would be good to mention enough detail so others can reproduce your configuration:
graphics hardware and driver: did the 3 machines use the same graphics hardware and drivers? graphics display server: wayland +xwayland or X11 JRE -- some Java apps require Oracle's proprietary JRE
How can I get error messages out of this mishap to file a meaningful and targeted bug report?
https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I need R-core installed, as well as curl-devel, and of course java. Other fedora packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any are fine, the first one is from rstudio.com. Also, the installation function may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a jaguar logo (pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" -> "Quick" -> "simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR comes crashing down.
Btw, since I know the commands to give in R, on the commandline, when I call the function, things work as expected. It is only on the JGR() window that it crashes.
Have you checked rJava and JGR bug reports?
The worst part? I get no error messages. So, how can I get error messages out of this mishap to file a meaningful and targeted bug report?
Can you connect to the system with ssh or use a console <Alt Fn>? If so
the kernel is still alive and the graphics system has crashed. If not, you can first try adjusting your configuration. The last resort is kernel debugging.
This suggests a graphics issue. If you have been using wayland you should try the X11 server. if both graphics systems are failing you could try an Oracle JRE https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.ht... .
On Wed, 9 Sep 2020 08:08:23 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra maitra@email.com wrote:
Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way to illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R called Deducer. I am able to install without a hitch and even bring it up and run some functions and graphical displays. However, when I ask it to do a few specific functions, the windows all come crashing down. So, my question is: how do I figure out the source of the problem? I have used this program for years, and including last spring under F31, and linux has never been an issue. This has been tried on three F32 machines by me and a former student and all have resulted in crashes. Embarrasingly, these continue to work as expected with Windows and MacOS, though installation, especially for the latter is a pain.
It would be good to mention enough detail so others can reproduce your configuration:
graphics hardware and driver: did the 3 machines use the same graphics hardware and drivers?
Hi,
Thanks! The 3 machines are very different (all laptops, though) so likely have different graphics HW and drivers.
graphics display server: wayland +xwayland or X11
Sorry, how do I figure this out? I think one of the machines uses gnome so whatever comes with that (likely wayland +xwayland?) and mine I think uses X11 (these use openbox).
JRE -- some Java apps require Oracle's proprietary JRE
I am using the default Fedora version, and also tried with fedora's java-latest. Importantly, upto F31, this has never been an issue.
How can I get error messages out of this mishap to file a meaningful and targeted bug report?
https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I need R-core installed, as well as curl-devel, and of course java. Other fedora packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any are fine, the first one is from rstudio.com. Also, the installation function may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a jaguar logo (pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" -> "Quick" -> "simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR comes crashing down.
Btw, since I know the commands to give in R, on the commandline, when I call the function, things work as expected. It is only on the JGR() window that it crashes.
Have you checked rJava and JGR bug reports?
I looked around but was unable to find this specific crash detailed anywhere.
The worst part? I get no error messages. So, how can I get error messages out of this mishap to file a meaningful and targeted bug report?
Can you connect to the system with ssh or use a console <Alt Fn>? If so
the kernel is still alive and the graphics system has crashed. If not, you can first try adjusting your configuration. The last resort is kernel debugging.
Yes, the system and the graphics itself is up and running. It is only the JGR window that crashes (and brings down that part of the program). What surprises me is that only certain parts of the program crash. For instance, the histograph and density plots or scatterplot (both also using ggplot2 software) get displayed fine.
So, your message set me thinking of looking at
tail -f /var/log/messages
while there is a successful operation, such as using the histogram function, and an operation (boxplot) which crashes. Here is the output for when it succeeds (displays a histogram):
Sep 9 08:50:01 localhost audit[54034]: USER_ACCT pid=54034 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_localuser acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost kernel: audit: type=1101 audit(1599659401.299:4966): pid=54034 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_access,pam_unix,pam_localuser acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost kernel: audit: type=1103 audit(1599659401.299:4967): pid=54034 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost kernel: audit: type=1006 audit(1599659401.300:4968): pid=54034 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=310 res=1 Sep 9 08:50:01 localhost audit[54034]: CRED_ACQ pid=54034 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost systemd[1]: Started Session 310 of user usrnam. Sep 9 08:50:01 localhost audit[54034]: USER_START pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost kernel: audit: type=1105 audit(1599659401.342:4969): pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost audit[54034]: CRED_REFR pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:01 localhost kernel: audit: type=1110 audit(1599659401.343:4970): pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:05 localhost audit[54034]: CRED_DISP pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:05 localhost kernel: audit: type=1104 audit(1599659405.415:4971): pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:05 localhost audit[54034]: USER_END pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:05 localhost kernel: audit: type=1106 audit(1599659405.416:4972): pid=54034 uid=0 auid=1000 ses=310 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="usrnam" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' Sep 9 08:50:05 localhost systemd[1]: session-310.scope: Succeeded. Sep 9 08:50:15 localhost journal[54046]: _pango_color_parse_with_alpha: assertion 'spec != NULL' failed Sep 9 08:50:34 localhost slim[831]: (EE) event14 - Dell Dell QuietKey Keyboard: client bug: event processing lagging behind by 19ms, your system is too slow
Here is the output for when it crashes (displays a boxplot):
Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1 Sep 9 08:51:12 localhost kernel: audit: type=1701 audit(1599659472.313:4973): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1 Sep 9 08:51:12 localhost audit: BPF prog-id=175 op=LOAD Sep 9 08:51:12 localhost kernel: audit: type=1334 audit(1599659472.325:4974): prog-id=175 op=LOAD Sep 9 08:51:12 localhost kernel: audit: type=1334 audit(1599659472.325:4975): prog-id=176 op=LOAD Sep 9 08:51:12 localhost kernel: audit: type=1334 audit(1599659472.325:4976): prog-id=177 op=LOAD Sep 9 08:51:12 localhost audit: BPF prog-id=176 op=LOAD Sep 9 08:51:12 localhost audit: BPF prog-id=177 op=LOAD Sep 9 08:51:12 localhost systemd[1]: Started Process Core Dump (PID 54142/UID 0). Sep 9 08:51:12 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@10-54142-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 9 08:51:12 localhost kernel: audit: type=1130 audit(1599659472.327:4977): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@10-54142-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 9 08:51:12 localhost audit[54143]: NETFILTER_CFG table=filter family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost audit[54143]: NETFILTER_CFG table=broute family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost audit[54143]: NETFILTER_CFG table=nat family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost kernel: audit: type=1325 audit(1599659472.329:4978): table=filter family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost kernel: audit: type=1325 audit(1599659472.329:4978): table=broute family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost kernel: audit: type=1325 audit(1599659472.329:4978): table=nat family=7 entries=0 op=register pid=54143 subj=system_u:system_r:init_t:s0 comm="(coredump)" Sep 9 08:51:12 localhost systemd-coredump[54143]: Removed old coredump core.java.1000.5cd56b6bfbcb41fa9e929a1dcc39494e.911333.1599528957000000000000.lz4. Sep 9 08:51:15 localhost systemd-coredump[54143]: Process 53948 (java) of user 1000 dumped core.#012#012Stack trace of thread 53982:#012#0 0x00007fb3aacb8ab3 Rf_eval (libR.so + 0x157ab3)#012#1 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#2 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#3 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#4 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#5 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#6 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#7 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#8 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#9 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#10 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#11 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#12 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#13 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#14 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#15 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#16 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#17 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#18 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#19 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#20 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#21 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#22 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#23 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#24 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#25 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#26 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#27 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#28 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#29 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#30 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#31 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#32 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#33 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#34 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#35 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#36 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#37 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#38 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#39 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#40 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#41 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#42 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#43 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#44 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#45 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#46 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#47 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#48 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#49 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#50 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#51 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#52 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#53 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#54 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#55 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#56 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#57 0x00007fb3aacb9574 forcePromise (libR.so + 0x158574)#012#58 0x00007fb3aacb9848 getvar (libR.so + 0x158848)#012#59 0x00007fb3aaca2011 bcEval (libR.so + 0x141011)#012#60 0x00007fb3aacb8ab8 Rf_eval (libR.so + 0x157ab8)#012#61 0x00007fb3aacba78e R_execClosure (libR.so + 0x15978e)#012#62 0x00007fb3aacbb5f2 Rf_applyClosure (libR.so + 0x15a5f2)#012#63 0x00007fb3aaca7150 bcEval (libR.so + 0x146150)#012#012Stack trace of thread 53952:#012#0 0x00007fb407257e92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92)#012#1 0x00007fb406d4546b _ZN2os13PlatformEvent4parkEv (libjvm.so + 0x9ac46b)#012#2 0x00007fb406cf09e7 _ZN7Monitor5IWaitEP6Threadl (libjvm.so + 0x9579e7)#012#3 0x00007fb406cf168a _ZN7Monitor4waitEblb (libjvm.so + 0x95868a)#012#4 0x00007fb406975f2f _ZN13GCTaskManager8get_taskEj (libjvm.so + 0x5dcf2f)#012#5 0x00007fb40697766b _ZN12GCTaskThread3runEv (libjvm.so + 0x5de66b)#012#6 0x00007fb406d3d840 _ZL10java_startP6Thread (libjvm.so + 0x9a4840)#012#7 0x00007fb407251432 start_thread (libpthread.so.0 + 0x9432)#012#8 0x00007fb40738c913 __clone (libc.so.6 + 0x101913)#012#012Stack trace of thread 53949:#012#0 0x00007fb4072581b8 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0 + 0x101b8)#012#1 0x00007fb406d45644 _ZN2os13PlatformEvent4parkEl (libjvm.so + 0x9ac644)#012#2 0x00007fb406d459df _ZN2os5sleepEP6Threadlb (libjvm.so + 0x9ac9df)#012#3 0x00007fb406b1cf17 JVM_Sleep (libjvm.so + 0x783f17)#012#4 0x00007fb3f18d8b31 n/a (n/a + 0x0)#012#5 0x00007fb3f1007ffd n/a (n/a + 0x0)#012#6 0x00007fb3f1007ffd n/a (n/a + 0x0)#012#7 0x00007fb3f1007ffd n/a (n/a + 0x0)#012#8 0x00007fb3f10004e7 n/a (n/a + 0x0)#012#9 0x00007fb406a59e65 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread (libjvm.so + 0x6c0e65)#012#10 0x00007fb406dc24ef _ZN10Reflection6invokeE19instanceKlassHandle12methodHandle6Handleb14objArrayHandle9BasicTypeS3_bP6Thread (libjvm.so + 0xa294ef)#012#11 0x00007fb406dc360c _ZN10Reflection13invoke_methodEP7oopDesc6Handle14objArrayHandleP6Thread (libjvm.so + 0xa2a60c)#012#12 0x00007fb406b13ba2 JVM_InvokeMethod (libjvm.so + 0x77aba2)#012#13 0x00007fb3f1018427 n/a (n/a + 0x0)#012#14 0x00007fb3f1007d80 n/a (n/a + 0x0)#012#15 0x00007fb3f1007d80 n/a (n/a + 0x0)#012#16 0x00007fb3f1007e54 n/a (n/a + 0x0)#012#17 0x00007fb3f1007d80 n/a (n/a + 0x0)#012#18 0x00007fb3f1007ffd n/a (n/a + 0x0)#012#19 0x00007fb3f10004e7 n/a (n/a + 0x0)#012#20 0x00007fb406a59e65 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread (libjvm.so + 0x6c0e65)#012#21 0x00007fb406ad5c0d _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.constprop.1 (libjvm.so + 0x73cc0d)#012#22 0x00007fb406ad8d16 jni_CallStaticVoidMethod (libjvm.so + 0x73fd16)#012#23 0x00007fb40748c8a2 JavaMain (libjli.so + 0x48a2)#012#24 0x00007fb407251432 start_thread (libpthread.so.0 + 0x9432)#012#25 0x00007fb40738c913 __clone (libc.so.6 + 0x101913)#012#012Stack trace of thread 53951:#012#0 0x00007fb407257e92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92)#012#1 0x00007fb406d4546b _ZN2os13PlatformEvent4parkEv (libjvm.so + 0x9ac46b)#012#2 0x00007fb406cf09e7 _ZN7Monitor5IWaitEP6Threadl (libjvm.so + 0x9579e7)#012#3 0x00007fb406cf168a _ZN7Monitor4waitEblb (libjvm.so + 0x95868a)#012#4 0x00007fb406975f2f _ZN13GCTaskManager8get_taskEj (libjvm.so + 0x5dcf2f)#012#5 0x00007fb40697766b _ZN12GCTaskThread3runEv (libjvm.so + 0x5de66b)#012#6 0x00007fb406d3d840 _ZL10java_startP6Thread (libjvm.so + 0x9a4840)#012#7 0x00007fb407251432 start_thread (libpthread.so.0 + 0x9432)#012#8 0x00007fb40738c913 __clone (libc.so.6 + 0x101913)#012#012Stack trace of thread 53960:#012#0 0x00007fb407257e92 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xfe92)#012#1 0x00007fb406d4546b _ZN2os13PlatformEvent4parkEv (libjvm.so + 0x9ac46b)#012#2 0x00007fb406d234cd _ZN13ObjectMonitor4waitElbP6Thread (libjvm.so + 0x98a4cd)#012#3 0x00007fb406ebaf33 _ZN18ObjectSynchronizer4waitE6HandlelP6Thread (libjvm.so + 0xb21f33)#012#4 0x00007fb406b06aff JVM_MonitorWait (libjvm.so + 0x76daff)#012#5 0x00007fb3f1018427 n/a (n/a + 0x0)#012#6 0x00007fb3f1007ffd n/a (n/a + 0x0)#012#7 0x00007fb3f1007d80 n/a (n/a + 0x0)#012#8 0x00007fb3f1007d80 n/a (n/a + 0x0)#012#9 0x00007fb3f10004e7 n/a (n/a + 0x0)#012#10 0x00007fb406a59e65 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread (libjvm.so + 0x6c0e65)#012#11 0x00007fb406a576bf _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandleP6SymbolS4_P17JavaCallArgumentsP6Thread (libjvm.so + 0x6be6bf)#012#12 0x00007fb406a57c61 _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandleP6SymbolS5_P6Thread (libjvm.so + 0x6bec61)#012#13 0x00007fb406b04de0 _ZL12thread_entryP10JavaThreadP6Thread (lib Sep 9 08:51:15 localhost systemd[1]: systemd-coredump@10-54142-0.service: Succeeded. Sep 9 08:51:15 localhost kernel: audit: type=1131 audit(1599659475.377:4979): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@10-54142-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 9 08:51:15 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@10-54142-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 9 08:51:15 localhost systemd[1]: systemd-coredump@10-54142-0.service: Consumed 2.713s CPU time. Sep 9 08:51:15 localhost audit[52859]: NETFILTER_CFG table=nat family=7 entries=0 op=unregister pid=52859 subj=system_u:system_r:kernel_t:s0 comm="kworker/u16:5" Sep 9 08:51:15 localhost audit[52859]: NETFILTER_CFG table=broute family=7 entries=0 op=unregister pid=52859 subj=system_u:system_r:kernel_t:s0 comm="kworker/u16:5" Sep 9 08:51:15 localhost kernel: audit: type=1325 audit(1599659475.402:4980): table=nat family=7 entries=0 op=unregister pid=52859 subj=system_u:system_r:kernel_t:s0 comm="kworker/u16:5" Sep 9 08:51:15 localhost audit[52859]: NETFILTER_CFG table=filter family=7 entries=0 op=unregister pid=52859 subj=system_u:system_r:kernel_t:s0 comm="kworker/u16:5" Sep 9 08:51:15 localhost audit: BPF prog-id=177 op=UNLOAD Sep 9 08:51:15 localhost audit: BPF prog-id=176 op=UNLOAD Sep 9 08:51:15 localhost audit: BPF prog-id=175 op=UNLOAD
This suggests a graphics issue. If you have been using wayland you should try the X11 server. if both graphics systems are failing you could try an Oracle JRE https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.ht...
I could do that, I guess, but does the above help?
Many thanks again, and best wishes, Ranjan
On Wed, 9 Sep 2020 at 10:57, Ranjan Maitra maitra@email.com wrote:
On Wed, 9 Sep 2020 08:08:23 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra maitra@email.com wrote:
Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way
to
illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R called Deducer. I am able to install without a hitch and even bring it up and
run
some functions and graphical displays. However, when I ask it to do a
few
specific functions, the windows all come crashing down. So, my
question is:
how do I figure out the source of the problem? I have used this
program for
years, and including last spring under F31, and linux has never been an issue. This has been tried on three F32 machines by me and a former
student
and all have resulted in crashes. Embarrasingly, these continue to
work as
expected with Windows and MacOS, though installation, especially for
the
latter is a pain.
It would be good to mention enough detail so others can reproduce your configuration:
graphics hardware and driver: did the 3 machines use the same graphics hardware and drivers?
Hi,
Thanks! The 3 machines are very different (all laptops, though) so likely have different graphics HW and drivers.
graphics display server: wayland +xwayland or X11
Sorry, how do I figure this out? I think one of the machines uses gnome so whatever comes with that (likely wayland +xwayland?) and mine I think uses X11 (these use openbox).
I tried both wayland and weston in Fedroa 32 as a VM. It is the JRE that crashes. My system generated a problem report (which fails to upload -- I think the server is down) for java-1.8.0-openjdk-headless, which is odd considering the application uses graphics.
JRE -- some Java apps require Oracle's proprietary JRE
I am using the default Fedora version, and also tried with fedora's java-latest. Importantly, upto F31, this has never been an issue.
How can I get error messages out of this mishap to file a meaningful
and
targeted bug report?
https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I
need
R-core installed, as well as curl-devel, and of course java. Other
fedora
packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any are fine, the first one is from rstudio.com. Also, the installation
function
may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a jaguar
logo
(pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" -> "Quick"
->
"simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR comes crashing down.
Btw, since I know the commands to give in R, on the commandline, when I call the function, things work as expected. It is only on the JGR()
window
that it crashes.
Have you checked rJava and JGR bug reports?
I looked around but was unable to find this specific crash detailed anywhere.
The worst part? I get no error messages. So, how can I get error
messages
out of this mishap to file a meaningful and targeted bug report?
Can you connect to the system with ssh or use a console <Alt Fn>? If so
the kernel is still alive and the graphics system has crashed. If not, you can first try adjusting your configuration. The last resort is
kernel
debugging.
Yes, the system and the graphics itself is up and running. It is only the JGR window that crashes (and brings down that part of the program). What surprises me is that only certain parts of the program crash. For instance, the histograph and density plots or scatterplot (both also using ggplot2 software) get displayed fine.
So, your message set me thinking of looking at
tail -f /var/log/messages
while there is a successful operation, such as using the histogram function, and an operation (boxplot) which crashes. Here is the output for when it succeeds (displays a histogram):
[...]
Here is the output for when it crashes (displays a boxplot):
Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1
This suggests a graphics issue. If you have been using wayland you should try the X11 server. if both graphics systems are failing you could try
an
Oracle JRE
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.ht...
I could do that, I guess, but does the above help?
I can reproduce the problem. It merits a bug report against openJDK (best if you report it as I may be otherwise busy and not able to keep up with requests for more info or testing potential fixes).
Thanks, I will file the bug report: should it be upstream or on Fedora? I know about Fedora's BZ, but what is upstream?
Ranjan
On Wed, 9 Sep 2020 13:15:57 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Wed, 9 Sep 2020 at 10:57, Ranjan Maitra maitra@email.com wrote:
On Wed, 9 Sep 2020 08:08:23 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra maitra@email.com wrote:
Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way
to
illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R called Deducer. I am able to install without a hitch and even bring it up and
run
some functions and graphical displays. However, when I ask it to do a
few
specific functions, the windows all come crashing down. So, my
question is:
how do I figure out the source of the problem? I have used this
program for
years, and including last spring under F31, and linux has never been an issue. This has been tried on three F32 machines by me and a former
student
and all have resulted in crashes. Embarrasingly, these continue to
work as
expected with Windows and MacOS, though installation, especially for
the
latter is a pain.
It would be good to mention enough detail so others can reproduce your configuration:
graphics hardware and driver: did the 3 machines use the same graphics hardware and drivers?
Hi,
Thanks! The 3 machines are very different (all laptops, though) so likely have different graphics HW and drivers.
graphics display server: wayland +xwayland or X11
Sorry, how do I figure this out? I think one of the machines uses gnome so whatever comes with that (likely wayland +xwayland?) and mine I think uses X11 (these use openbox).
I tried both wayland and weston in Fedroa 32 as a VM. It is the JRE that crashes. My system generated a problem report (which fails to upload -- I think the server is down) for java-1.8.0-openjdk-headless, which is odd considering the application uses graphics.
JRE -- some Java apps require Oracle's proprietary JRE
I am using the default Fedora version, and also tried with fedora's java-latest. Importantly, upto F31, this has never been an issue.
How can I get error messages out of this mishap to file a meaningful
and
targeted bug report?
https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I
need
R-core installed, as well as curl-devel, and of course java. Other
fedora
packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any are fine, the first one is from rstudio.com. Also, the installation
function
may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a jaguar
logo
(pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" -> "Quick"
->
"simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR comes crashing down.
Btw, since I know the commands to give in R, on the commandline, when I call the function, things work as expected. It is only on the JGR()
window
that it crashes.
Have you checked rJava and JGR bug reports?
I looked around but was unable to find this specific crash detailed anywhere.
The worst part? I get no error messages. So, how can I get error
messages
out of this mishap to file a meaningful and targeted bug report?
Can you connect to the system with ssh or use a console <Alt Fn>? If so
the kernel is still alive and the graphics system has crashed. If not, you can first try adjusting your configuration. The last resort is
kernel
debugging.
Yes, the system and the graphics itself is up and running. It is only the JGR window that crashes (and brings down that part of the program). What surprises me is that only certain parts of the program crash. For instance, the histograph and density plots or scatterplot (both also using ggplot2 software) get displayed fine.
So, your message set me thinking of looking at
tail -f /var/log/messages
while there is a successful operation, such as using the histogram function, and an operation (boxplot) which crashes. Here is the output for when it succeeds (displays a histogram):
[...]
Here is the output for when it crashes (displays a boxplot):
Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1
This suggests a graphics issue. If you have been using wayland you should try the X11 server. if both graphics systems are failing you could try
an
Oracle JRE
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.ht...
I could do that, I guess, but does the above help?
I can reproduce the problem. It merits a bug report against openJDK (best if you report it as I may be otherwise busy and not able to keep up with requests for more info or testing potential fixes).
-- George N. White III
-- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
On Wed, 9 Sep 2020 at 13:33, Ranjan Maitra maitra@email.com wrote:
Thanks, I will file the bug report: should it be upstream or on Fedora? I know about Fedora's BZ, but what is upstream?
Fedora/RedHat bugzilla. If the automated bug reporting system was working the report would be seen by Fedora people. Since the failure is on Fedora and not other platforms, linux expertise may be needed to understand the issue. I have VM's for other linux distros so I plan to check to see if the issue occurs on other linux distros.
Ranjan
On Wed, 9 Sep 2020 13:15:57 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Wed, 9 Sep 2020 at 10:57, Ranjan Maitra maitra@email.com wrote:
On Wed, 9 Sep 2020 08:08:23 -0300 "George N. White III" <
gnwiii@gmail.com>
wrote:
On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra maitra@email.com wrote:
Dear friends,
I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The
way
to
illustrate this is rather complicated, so I will first summarize.
For my introductory students, I use a java-based front-end to R
called
Deducer. I am able to install without a hitch and even bring it up
and
run
some functions and graphical displays. However, when I ask it to
do a
few
specific functions, the windows all come crashing down. So, my
question is:
how do I figure out the source of the problem? I have used this
program for
years, and including last spring under F31, and linux has never
been an
issue. This has been tried on three F32 machines by me and a former
student
and all have resulted in crashes. Embarrasingly, these continue to
work as
expected with Windows and MacOS, though installation, especially
for
the
latter is a pain.
It would be good to mention enough detail so others can reproduce
your
configuration:
graphics hardware and driver: did the 3 machines use the same
graphics
hardware and drivers?
Hi,
Thanks! The 3 machines are very different (all laptops, though) so
likely
have different graphics HW and drivers.
graphics display server: wayland +xwayland or X11
Sorry, how do I figure this out? I think one of the machines uses
gnome so
whatever comes with that (likely wayland +xwayland?) and mine I think
uses
X11 (these use openbox).
I tried both wayland and weston in Fedroa 32 as a VM. It is the JRE
that
crashes. My system generated a problem report (which fails to upload --
I
think the server is down) for java-1.8.0-openjdk-headless, which is odd considering the application uses graphics.
JRE -- some Java apps require Oracle's proprietary JRE
I am using the default Fedora version, and also tried with fedora's java-latest. Importantly, upto F31, this has never been an issue.
How can I get error messages out of this mishap to file a
meaningful
and
targeted bug report?
https://www.linuxjournal.com/content/oops-debugging-kernel-panics-0
Any suggestions? Ranjan
If you are interested, here is how I go about installing Deducer. I
need
R-core installed, as well as curl-devel, and of course java. Other
fedora
packages may also be needed.
sudo dnf install R-devel curl-devel java-1.8.0-openjdk-devel
then:
sudo R install.packages(c('JGR','Deducer')) q()
Note that the second line will ask for which repo to use, and any
are
fine, the first one is from rstudio.com. Also, the installation
function
may ask for more libraries to be installed.
Once installed, go to R and inside R, type:
library(JGR) library(Deducer) JGR()
The last function call will open a graphical interface with a
jaguar
logo
(pretty cool). All is well. In the bottom window type: data(cars)
Then go to the graphical interface above, and under "Plots" ->
"Quick"
->
"simple boxplot" This opens a window, and put speed as x variable and run. A window begins to open and the entire window system running JGR
comes
crashing down.
Btw, since I know the commands to give in R, on the commandline,
when I
call the function, things work as expected. It is only on the JGR()
window
that it crashes.
Have you checked rJava and JGR bug reports?
I looked around but was unable to find this specific crash detailed anywhere.
The worst part? I get no error messages. So, how can I get error
messages
out of this mishap to file a meaningful and targeted bug report?
Can you connect to the system with ssh or use a console <Alt Fn>?
If so
the kernel is still alive and the graphics system has crashed. If
not,
you can first try adjusting your configuration. The last resort is
kernel
debugging.
Yes, the system and the graphics itself is up and running. It is only
the
JGR window that crashes (and brings down that part of the program).
What
surprises me is that only certain parts of the program crash. For
instance,
the histograph and density plots or scatterplot (both also using
ggplot2
software) get displayed fine.
So, your message set me thinking of looking at
tail -f /var/log/messages
while there is a successful operation, such as using the histogram function, and an operation (boxplot) which crashes. Here is the output
for
when it succeeds (displays a histogram):
[...]
Here is the output for when it crashes (displays a boxplot):
Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
pid=53948 comm="Thread-5"
exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java"
sig=11 res=1
This suggests a graphics issue. If you have been using wayland you
should
try the X11 server. if both graphics systems are failing you could
try
an
Oracle JRE
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.ht...
I could do that, I guess, but does the above help?
I can reproduce the problem. It merits a bug report against openJDK
(best
if you report it as I may be otherwise busy and not able to keep up with requests for more
info
or testing potential fixes).
-- George N. White III
-- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Wed, 9 Sep 2020 at 13:33, Ranjan Maitra maitra@email.com wrote:
Thanks, I will file the bug report: should it be upstream or on Fedora? I know about Fedora's BZ, but what is upstream?
Ranjan
I tried to reproduce the problem on Ubuntu 20.04. Using wayland the fonts in the JGR window are so tiny I can't read them, and the <Shift-Ctrl-I> increase fonts size key has no effect. Using X11 with openJDK11 the problem doesn't occur.
On Wed, 9 Sep 2020 15:52:26 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Wed, 9 Sep 2020 at 13:33, Ranjan Maitra maitra@email.com wrote:
Thanks, I will file the bug report: should it be upstream or on Fedora? I know about Fedora's BZ, but what is upstream?
Ranjan
I tried to reproduce the problem on Ubuntu 20.04. Using wayland the fonts in the JGR window are so tiny I can't read them, and the <Shift-Ctrl-I> increase fonts size key has no effect. Using X11 with openJDK11 the problem doesn't occur.
-- George N. White III
Thanks, so this appears to be a Fedora problem. Btw, I tried oracle's jdk-14.0.2_linux-x64_bin.rpm and had the same result.
I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1877524
Thanks again, Ranjan
On Wed, Sep 9, 2020 at 1:12 PM Ranjan Maitra maitra@email.com wrote:
Thanks, so this appears to be a Fedora problem. Btw, I tried oracle's jdk-14.0.2_linux-x64_bin.rpm and had the same result.
I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1877524
Why does everyone seem to think this is a Java bug? The system log showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in the R library. The stack trace shows a lot of calls to these functions:
bcEval forcePromise getvar R_execClosure Rf_appyClosure Rf_eval
It's possible that R is being handed an expression to evaluate that is so complex that it runs out of stack space, or there could be an infinite recursion bug in R somewhere. If the former, the solution is to bump up the stack space. I would try the -Xss argument to java first to see if that makes the issue go away. I'm not sure what the default value is, so I don't know what to suggest, but maybe start with something like -Xss4M. If that fixes the issue, then retry with successively smaller values to find something reasonable that is still big enough to work.
On Wed, 9 Sep 2020 13:33:05 -0600 Jerry James loganjerry@gmail.com wrote:
On Wed, Sep 9, 2020 at 1:12 PM Ranjan Maitra maitra@email.com wrote:
Thanks, so this appears to be a Fedora problem. Btw, I tried oracle's jdk-14.0.2_linux-x64_bin.rpm and had the same result.
I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1877524
Why does everyone seem to think this is a Java bug? The system log showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in the R library. The stack trace shows a lot of calls to these functions:
bcEval forcePromise getvar R_execClosure Rf_appyClosure Rf_eval
It's possible that R is being handed an expression to evaluate that is so complex that it runs out of stack space, or there could be an infinite recursion bug in R somewhere. If the former, the solution is to bump up the stack space. I would try the -Xss argument to java first to see if that makes the issue go away. I'm not sure what the default value is, so I don't know what to suggest, but maybe start with something like -Xss4M. If that fixes the issue, then retry with successively smaller values to find something reasonable that is still big enough to work.
Jerry,
Thanks for pointing this out. So, on the commandline for R, the equivalent call:
ggplot() + geom_boxplot(aes(y = speed), data = cars)
plots without a hitch. Now boxplots require calculations of three quartiles, and a couple more calculations to decide on outliers, and this may be a R problem, but this is a 50-observations dataset. Besides, the call inside JGR works with Windows as well as Mac and on Ubuntu 20.04 (per George), but crashes things on Fedora.
How do I add the argument to java that you suggest? Where do I do this?
Many thanks, Ranjan
On Wed, 9 Sep 2020 at 16:33, Jerry James loganjerry@gmail.com wrote:
On Wed, Sep 9, 2020 at 1:12 PM Ranjan Maitra maitra@email.com wrote:
Thanks, so this appears to be a Fedora problem. Btw, I tried oracle's
jdk-14.0.2_linux-x64_bin.rpm and had the same result.
I filed a bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1877524
Why does everyone seem to think this is a Java bug?
My system generated crash report (including a core dump) that identified a segfault in the Java runtime. A Java process is started by JGR(). JavaGD() seems to start another Java process
The OP's log starts with segfaults (signal 11) in a Java process: Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1 Sep 9 08:51:12 localhost kernel: audit: type=1701 audit(1599659472.313:4973): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1
The system log
showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in the R library. The stack trace shows a lot of calls to these functions:
bcEval forcePromise getvar R_execClosure Rf_appyClosure Rf_eval
It's possible that R is being handed an expression to evaluate that is so complex that it runs out of stack space, or there could be an infinite recursion bug in R somewhere. If the former, the solution is to bump up the stack space. I would try the -Xss argument to java first to see if that makes the issue go away. I'm not sure what the default value is, so I don't know what to suggest, but maybe start with something like -Xss4M. If that fixes the issue, then retry with successively smaller values to find something reasonable that is still big enough to work.
The problem seems to be specific to Fedora 32.
-- Jerry James http://www.jamezone.org/ _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Thanks, there has been no activity on the BZ report yet. Hopefully, this can be fixed soon, and I understand it is possible that it may be a memory leak in one of the R components. For instance, this morning, I noticed that even running the histogram command twice crashes the JGR window. I wonder if the issue also happens with Fedora 31.
Ranjan
On Thu, 10 Sep 2020 07:19:27 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Wed, 9 Sep 2020 at 16:33, Jerry James loganjerry@gmail.com wrote:
On Wed, Sep 9, 2020 at 1:12 PM Ranjan Maitra maitra@email.com wrote:
Thanks, so this appears to be a Fedora problem. Btw, I tried oracle's
jdk-14.0.2_linux-x64_bin.rpm and had the same result.
I filed a bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1877524
Why does everyone seem to think this is a Java bug?
My system generated crash report (including a core dump) that identified a segfault in the Java runtime. A Java process is started by JGR(). JavaGD() seems to start another Java process
The OP's log starts with segfaults (signal 11) in a Java process: Sep 9 08:51:12 localhost audit[53948]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1 Sep 9 08:51:12 localhost kernel: audit: type=1701 audit(1599659472.313:4973): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=53948 comm="Thread-5" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/bin/java" sig=11 res=1
The system log
showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in the R library. The stack trace shows a lot of calls to these functions:
bcEval forcePromise getvar R_execClosure Rf_appyClosure Rf_eval
It's possible that R is being handed an expression to evaluate that is so complex that it runs out of stack space, or there could be an infinite recursion bug in R somewhere. If the former, the solution is to bump up the stack space. I would try the -Xss argument to java first to see if that makes the issue go away. I'm not sure what the default value is, so I don't know what to suggest, but maybe start with something like -Xss4M. If that fixes the issue, then retry with successively smaller values to find something reasonable that is still big enough to work.
The problem seems to be specific to Fedora 32.
-- Jerry James http://www.jamezone.org/ _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- George N. White III
-- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
-
George N. White III -
Jerry James -
Ranjan Maitra