Again, Auto Model crashes at the end of the run on certain learners
pblack476
New Altair Community Member
I again have a problem with AutoModel. I am trying to run some data through it and depending on the learner selected, it freezes. In this specific case I have the GBT learner causing a freeze when execution ends. Every AM setting is at default.
Here is the Data. Can anyone replicate this? Just running this through GBT in AM does not happen for me. Trying to predict the 'Close' Attribute.
GLM and DL models run and finish without issues. DT and GBT cause RM to freeze at the end of the process.
I can only work around this by selecting SVM, and while SVM runs I can save the DT and GBT processes. If I let it finish it freezes.
Tagged:
0
Best Answer
-
The links i found on the forum were broken. Do you have a working one?@pblack476
If you are looking for an upgrade link, you don't need one. You just need to go to Extension --> Marketplace --> Updates tab in your rapidminer studio menu. There you can find the latest updates.1
Answers
-
Hi @pblack476,
Unfortunately, I'm not able to replicate what you observe ...
From my side, the AutoModel process runs sucessfully with your data :
I'm using RM 9.5 on a PC with Quad core / 16 Go RAM / Windows 10.
You can find in attached file(s) :
- the "results" folder (obtained by clicking on Save Results at the end of the run) :
https://drive.google.com/open?id=1mrQqxTdVFkJles31GEiIJwU_Sbgo-mV8
- the results comparaison (obtained by clicking on Export at the end of the run)
If I can do something for you with your dataset with RapidMiner, please let me know...
Regards,
Lionel0 -
@lionelderkrikor I am on 9.4. Maybe if I upgrade to 9.5? The links i found on the forum were broken. Do you have a working one? I'll try that.
0 -
@pblack476,
You speak of the link to the "results" folder I shared ?
It works for me.. I don't know what to do ...
Yes, try upgrading RM to the latest version.
Regards,
Lionel0 -
The links i found on the forum were broken. Do you have a working one?@pblack476
If you are looking for an upgrade link, you don't need one. You just need to go to Extension --> Marketplace --> Updates tab in your rapidminer studio menu. There you can find the latest updates.1 -
@lionelderkrikor even after updating nothing is changed here. It just happens when GBT or DT are the last models selected on the AM chain. If I select SVM as the last one, they all run and finish normally.
0 -
Hi @pblack476
I'm sorry but when DT (first screenshot) or GBT (second screenshot) are the last models selected, AutoModel works fine, without freezing, on my side :
Regards,
Lionel0 -
@pblack476
I dont have any issue in executing your data and RAM consumption is also normal at 3.2 GB.It just happens when GBT or DT are the last models selected on the AM chain.Do you mean by deselecting SVM, you are getting GBT as the last model? If so, it works fine for me as well as @lionelderkrikor mentioned.
0 -
Thanks for the help. Must be something on my configuration. Perhabs something to do with my java? I am on PopOS! 19.10, i7-8750h, 16Gb RAM.
0 -
Perhabs something to do with my java
PopOS is something new for me. Java requirement for rapidminer is JAVA 8.2 -
@varunm1 @lionelderkrikor Reinstalling Java did not fix my issue unfortunately. Still getting a hanged RM at the end of AutoModel if DT or GBT are the last processes selected.Now, the thing is. It only happens with Regression tasks. Classification Tasks do not cause it to hang. I tested with the S&P500 sample dataset and it also hangs at the conclusion of DT or GBT.Any insights on this from the dev team?0
-
Hi,
Impossible to tell what causes this. If you're up for it, and can install a JDK instead of a JRE, you could gather more information for us to look at
I have written some instructions for Windows a little while ago, they translate well enough to the Linux world I would say: https://community.rapidminer.com/discussion/comment/61496/#Comment_61496
The main difference is that you don't need to replace any JRE inside the Studio folder, as you're using the installed Java version. So you would need to install a JDK instead of only a JRE and then run the command when RapidMiner Studio hangs.
In case you need more details instructions, let me know.
Thank you,
Marco0 -
@Marco_Boeck I already have JDK installed. But the folder structure is a little different on linux so I am a little lost. There is no "Beta" Folder anywhere in RapidMiner Studio folder and from there I cannot follow but I am willing to find out more about this issue if you would care to help.thank you.0
-
Hi,
On Linux we don't ship the JRE with Studio, so you can ignore 1-5. Step 7 gets replaced by the location where you have installed the JDK.
Regards,
Marco1 -
@Marco_Boeck Whenever RM freezes this log file gets automatically generated. Is this what you are looking for? Seems like it is to me. (File Attached)But in any case, The issue actually affects Design mode as well. If the model is GBT (or DT or RF) it freezes at the result delivery phase.While the file attached has a lot of info to it, when I run
jstack -F <pid>
I get this output on the stack .txt:Attaching to process ID 354, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.232-b09
Deadlock Detection:
Can't print deadlocks:Unable to deduce type of thread from address 0x00007f81b0199800 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)And this output on the CLI:
java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007f81b0199800 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:166)
at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
at sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:66)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
at sun.tools.jstack.JStack.main(JStack.java:106)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x00007f81b0199800
at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
... 17 more
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
at sun.tools.jstack.JStack.main(JStack.java:106)
Caused by: java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007f81b0199800 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:166)
at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:75)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:66)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
... 6 more
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x00007f81b0199800
at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
... 14 more
0 -
Hi,
Thank you for the information! This unfortunately looks like a tricky one. I have forwarded this to the appropriate people, but I don't expect this to be an easily solvable problem, it is likely a combination of various factors like OS, Java, and some 3rd party libraries
Regards,
Marco1 -
Hello, I was having this issue on my own setup. (Ubuntu 20.04 & OpenJDK 1.8.).
I resolved it by following the workaround listed in this bug report from 2015 on Ubuntu's Java.
https://bugs.launchpad.net/ubuntu/+source/java-atk-wrapper/+bug/1510009comment out the line "assistive_technologies=org.GNOME.Accessibility.AtkWrapper" in /etc/java-7-openjdk/accessibility.properties
This resolved the issue on my system.0