🎉Community Raffle - Win $25

An exclusive raffle opportunity for active members like you! Complete your profile, answer questions and get your first accepted badge to enter the raffle.

Join and Win

Again, Auto Model crashes at the end of the run on certain learners

pblack476

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.

Find more posts tagged with

AI Studio

Errors

Auto Model

Accepted answers

varunm1

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.

All comments

lionelderkrikor

Hi @pblack476,

Unfortunately, I'm not able to replicate what you observe ...
From my side, the AutoModel process runs sucessfully with your data :

Image: https://us.v-cdn.net/6030995/uploads/editor/cc/legii1lwdunq.png

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,

Lionel

results_comparaison_pblack.xlsx

pblack476

@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.

lionelderkrikor

@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,

Lionel

varunm1

The links i found on the forum were broken. Do you have a working one?

pblack476

@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.

lionelderkrikor

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,

Lionel

varunm1

@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.

pblack476

@varunm1 @lionelderkrikor

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.

varunm1

Perhabs something to do with my java

PopOS is something new for me. Java requirement for rapidminer is JAVA 8.

pblack476

@varunm1 I do have Java 8 installed of course, that is why I can run RM at all. But maybe something got corrupted. I'll try to reinstall it

pblack476

@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?

Marco_Boeck

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,
Marco

pblack476

@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.

Marco_Boeck

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,
Marco

pblack476

@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

Marco_Boeck

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,
Marco

JEdward

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/1510009

comment out the line "assistive_technologies=org.GNOME.Accessibility.AtkWrapper" in /etc/java-7-openjdk/accessibility.properties

This resolved the issue on my system.