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

pblack476
pblack476 New Altair Community Member
edited November 5 in Community Q&A
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:

Best Answer

  • varunm1
    varunm1 New Altair Community Member
    edited November 2019 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. 

Answers

  • lionelderkrikor
    lionelderkrikor New Altair Community Member
    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,

    Lionel
  • pblack476
    pblack476 New Altair Community Member
    @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
    lionelderkrikor New Altair Community Member
    @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
    varunm1 New Altair Community Member
    edited November 2019 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. 
  • pblack476
    pblack476 New Altair Community Member
    @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
    lionelderkrikor New Altair Community Member
    edited November 2019
    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
    varunm1 New Altair Community Member
    @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
    pblack476 New Altair Community Member
    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
    varunm1 New Altair Community Member
    Perhabs something to do with my java

    PopOS is something new for me. Java requirement for rapidminer is JAVA 8.
  • pblack476
    pblack476 New Altair Community Member
    @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
    pblack476 New Altair Community Member
    @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
    Marco_Boeck New Altair Community Member
    edited November 2019
    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
    pblack476 New Altair Community Member
    @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
    Marco_Boeck New Altair Community Member
    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
    pblack476 New Altair Community Member
    edited November 2019
    @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
    Marco_Boeck New Altair Community Member
    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
    JEdward New Altair Community Member
    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. 

Categories