Play Framework application crashes on Linux

I've got a Play (1.2.4) application that's working fine on my Windows 7 64bit dev machine.

I had a few crashes when I was running on Java 7.0 beta; this JavaVM crashes would appear on specific code modifications but without any "logical" reason (eg adding a crud admin class), but I switched to latest 7.0_2 and all is fine on windows now.

BUT my deployment machine(s) is/are Linux.

Again, all was working fine, but after my recent code update it keeps crashing.

~ play! 1.2.4, http://www.playframework.org
~
~ Ctrl+C to stop
~
Listening for transport dt_socket at address: 8000
05:20:36,845 INFO  ~ Starting /home/scrosta/PROJECT
05:20:36,849 INFO  ~ Module crud is available (/home/scrosta/play-1.2.4/modules/crud)
05:20:36,849 INFO  ~ Module jqueryui is available (/home/scrosta/PROJECTNAME/modules/jqueryui-1.0)
05:20:36,850 INFO  ~ Module logisimayml is available (/home/scrosta/PROJECTNAME/modules/logisimayml-1.5)
05:20:36,850 INFO  ~ Module secure is available (/home/scrosta/play-1.2.4/modules/secure)
05:20:36,851 INFO  ~ Module deadbolt is available (/home/scrosta/PROJECTNAME/modules/deadbolt-1.4.3)
05:20:37,461 WARN  ~ You're running Play! in DEV mode
05:20:37,522 INFO  ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...
05:21:07,468 INFO  ~ Connected to jdbc:h2:mem:play;MODE=MYSQL
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f3c3cb7a438, pid=17664, tid=139896551085824
#
# JRE version: 6.0_22-b22
# Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.10.4
# Distribution: Ubuntu 11.04, package 6b22-1.10.4-0ubuntu1~11.04.1
# Problematic frame:
# V  [libjvm.so+0x5ec438]  PhaseIdealLoop::build_loop_late_post(Node*)+0x158
#

The whole log is available on pastie

I tested with one Gentoo machine: IcedTea Java 6 and Oracle Java 7, and a different Ubuntu machine with IcedTea Java 6. Same problem. And no issue on Windows.

I did run dependencies again, and play clean too.

Any idea of what could be provoking this, how to solve, how to debug...?

PS.

play precompile

runs fine.

EDIT

As I mentioned, I used to get pretty much the same error on windows before switching to the latest Java 7.0_2.

Since on Linux I was getting it with both the JDK 6 and 7 from two different vendors, I thought it couldn't be related.

WELL, ends up that removing one of my Crud Controllers solves the issue - meaning, the application runs again.

I am thus tempted to blame the CRUD module (but hoping a new java update for Linux will solve the issue).

If somebody from play! is interested in knowing more about my crud classes, please comment.

Edit 2

Removing some crud classes had apparently solved the issue, as patchy as it might sound.

But I now had to move to a JBoss deployment, and the bug is back again!

It actually crashes the whole JBoss with exactly the same error...

回答1:

Just update JDK to latest Jdk 1.7 7u7 and problem will be solved , was facing the issue now resolved by udgrading jvm

回答2:

I think your Classes needs to much space. See

PSPermGen       total 40448K, used 40403K [0x000000067c400000, 0x000000067eb80000, x0000000686a00000)
object space 40448K, 99% used [0x000000067c400000,0x000000067eb74e08,0x000000067eb80000)

so I would recommend to increase the permsize and create an bug report at openjdk. Because I think a OutOfMemoryError should be thrown.

Here you can get more information about the permsize.

回答3:

This is definitely a bug with Java due to Eclipse compiler.

There is a bug to track on play.lighthouse.

It does seem that CRUD classes exacerbate the issue, and low memory too; the issue will tend to disappear, and only come back for hot-compilation (modifying Java code without restarting), and even there not always.

On the other side, deploying in JBoss definitely brings to full crashes.

With little crud classes and lot of available memory the situation improves, so as a workaround when you really can't do anything else: reduce to the minimum the number of CRUD classes; using the @For decorator again seems to worsen things.

Also, using Java 6 is much more stable - less memory sensitive - in particular with JBoss.

I'll mark this as solved because, beside the CRUD trick and the suggestion to use Java 6, there's nothing else that can be done at this level.