How to find the cause for the StackOverflow?

0
Our acceptance environment crashes with a stack overflow error (as below) Based on the stack trace I guess it is trying to execute a query and there is fails for some reason. What should be my course of action? I guess it's kind of strange that the runtime can just die on you like this. Dec 15 10:40:07.722 127.0.0.1 tr10000: INFO - WebUI: Login OK: user 'MxAdmin' (Number of concurrent sessions: 1). Dec 15 10:40:08.388 127.0.0.1 tr10000: CRITICAL - ActorSystem: Uncaught fatal error from thread [MxRuntimeSystem-action-dispatcher-10] shutting down ActorSystem [MxRuntimeSystem] Dec 15 10:40:08.392 127.0.0.1 tr10000: CRITICAL - ActorSystem: (1/1025) java.lang.StackOverflowError: null Dec 15 10:40:08.392 127.0.0.1 tr10000: CRITICAL - ActorSystem: (2/1025)     at java.security.AccessController.doPrivileged(Native Method) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (3/1025)     at org.apache.felix.framework.security.condpermadmin.DomainGripper.grab(DomainGripper.java:110) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (4/1025)     at org.apache.felix.framework.security.condpermadmin.ConditionalPermissionAdminImpl.hasPermission(ConditionalPermissionAdminImpl.java:860) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (5/1025)     at org.apache.felix.framework.SecurityProviderImpl.hasBundlePermission(SecurityProviderImpl.java:123) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (6/1025)     at org.apache.felix.framework.Felix.impliesBundlePermission(Felix.java:4300) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (7/1025)     at org.apache.felix.framework.BundleProtectionDomain.implies(BundleProtectionDomain.java:68) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (8/1025)     at java.security.AccessControlContext.checkPermission(Unknown Source) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (9/1025)     at java.security.AccessController.checkPermission(Unknown Source) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (10/1025)     at java.lang.SecurityManager.checkPermission(Unknown Source) Dec 15 10:40:08.393 127.0.0.1 tr10000: CRITICAL - ActorSystem: (11/1025)     at java.lang.SecurityManager.checkPropertyAccess(Unknown Source) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (12/1025)     at java.lang.System.getProperty(Unknown Source) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (13/1025)     at java.lang.Boolean.getBoolean(Unknown Source) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (14/1025)     at org.postgresql.jdbc2.AbstractJdbc2Statement.<init>(AbstractJdbc2Statement.java:43) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (15/1025)     at org.postgresql.jdbc3.AbstractJdbc3Statement.<init>(AbstractJdbc3Statement.java:34) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (16/1025)     at org.postgresql.jdbc3g.AbstractJdbc3gStatement.<init>(AbstractJdbc3gStatement.java:22) Dec 15 10:40:08.394 127.0.0.1 tr10000: CRITICAL - ActorSystem: (17/1025)     at org.postgresql.jdbc4.AbstractJdbc4Statement.<init>(AbstractJdbc4Statement.java:28) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (18/1025)     at org.postgresql.jdbc4.Jdbc4Statement.<init>(Jdbc4Statement.java:23) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (19/1025)     at org.postgresql.jdbc4.Jdbc4Connection.createStatement(Jdbc4Connection.java:30) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (20/1025)     at org.postgresql.jdbc3.AbstractJdbc3Connection.createStatement(AbstractJdbc3Connection.java:232) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (21/1025)     at org.postgresql.jdbc2.AbstractJdbc2Connection.createStatement(AbstractJdbc2Connection.java:286) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (22/1025)     at org.apache.commons.dbcp2.DelegatingConnection.createStatement(DelegatingConnection.java:257) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (23/1025)     at org.apache.commons.dbcp2.DelegatingConnection.createStatement(DelegatingConnection.java:257) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (24/1025)     at com.mendix.connectionbus.connections.jdbc.JDBCDataStore.execRetrieveQuery(JDBCDataStore.java:346) Dec 15 10:40:08.395 127.0.0.1 tr10000: CRITICAL - ActorSystem: (25/1025)     at com.mendix.connectionbus.connections.jdbc.JDBCDataStore.execRetrieveQueries(JDBCDataStore.java:221) Dec 15 10:40:08.396 127.0.0.1 tr10000: CRITICAL - ActorSystem: (26/1025)     at com.mendix.connectionbus.connections.jdbc.JDBCDataStore.retrieve(JDBCDataStore.java:178) ....
asked
2 answers
0

Could you try sharing the rest of the stacktrace somehow? When closely looking at the steps in the stacktrace you might be able to find out if it is a modelling issue. (Maybe you can share the full stacktrace in a file on rapidshare or something and add a link?)

With your current stacktrace we can only say it breaks on retrieving information from the database (there is a JDBC connection in the stacktrace), if you can share the rest of the stacktrace we can see where the db connection is called from.  

If there are circular references in there we can identify if
  for example we see something with objectmanagement and commit in there we can draw the conclusion that one of your commit events is causing this.
  If there is information in the stacktrace about attributes / executeAction / microflow (in that sequence) we can conclude you have calculated/virtual attributes that are the cause.

 

Basically by reading through the microflows you should be able to see a pattern such as retrieve / commit / retrieve / calculated attribute / retrieve / commit /retrieve / calculated attribute / etc   once you have found that, it's just a matter of reviewing all your actions that fit that pattern. 

answered
0

All the cases that I've seen of a stackoverflow error where cases where somehow an infinite loop was created. 

I've seen this when before or after commit events are committing the event object with events. This will create an infinite loop. Or some custom While loops with no right exit scenario. 

Can you reproduce the issue? If so, than finding the problem should be simple. Is it related to your MxAdmin sign in -> at the top of your log? 

In addition to the things Jasper said I have a few suggestions:

  • Check the running now microflows when the crash happens
  • Use tooling to help you more. There are quitte a few good products. APM can help to to identify what was happening when the crash occured. An other tool is Fit Test of Omnext, which can detect most of the infinite loops in your model. 
answered