The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here

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

pblack476pblack476 Member Posts: 83 Maven
edited November 2019 in Help
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

Answers

  • lionelderkrikorlionelderkrikor RapidMiner Certified Analyst, Member Posts: 1,195 Unicorn
    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
  • pblack476pblack476 Member Posts: 83 Maven
    @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.
  • lionelderkrikorlionelderkrikor RapidMiner Certified Analyst, Member Posts: 1,195 Unicorn
    @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
  • pblack476pblack476 Member Posts: 83 Maven
    @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.
  • lionelderkrikorlionelderkrikor RapidMiner Certified Analyst, Member Posts: 1,195 Unicorn
    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
  • varunm1varunm1 Member Posts: 1,207 Unicorn
    @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. 
    Regards,
    Varun
    https://www.varunmandalapu.com/

    Be Safe. Follow precautions and Maintain Social Distancing

  • pblack476pblack476 Member Posts: 83 Maven
    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.

  • varunm1varunm1 Member Posts: 1,207 Unicorn
    Perhabs something to do with my java

    PopOS is something new for me. Java requirement for rapidminer is JAVA 8.
    Regards,
    Varun
    https://www.varunmandalapu.com/

    Be Safe. Follow precautions and Maintain Social Distancing

  • pblack476pblack476 Member Posts: 83 Maven
    @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
  • pblack476pblack476 Member Posts: 83 Maven
    @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_BoeckMarco_Boeck Administrator, Moderator, Employee-RapidMiner, Member, University Professor Posts: 1,996 RM Engineering
    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
  • pblack476pblack476 Member Posts: 83 Maven
    @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_BoeckMarco_Boeck Administrator, Moderator, Employee-RapidMiner, Member, University Professor Posts: 1,996 RM Engineering
    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
  • pblack476pblack476 Member Posts: 83 Maven
    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_BoeckMarco_Boeck Administrator, Moderator, Employee-RapidMiner, Member, University Professor Posts: 1,996 RM Engineering
    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
  • JEdwardJEdward RapidMiner Certified Analyst, RapidMiner Certified Expert, Member Posts: 578 Unicorn
    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. 

Sign In or Register to comment.