Hudson build fails with Maven JVM terminated unexpectedly with exit code 134
We use Hudson as a continuous integration tool for Twitter4J.
I really love the maven oriented and easy to use tool and it makes Twitter4J development much smoother.
But what unfortunate is the error message "ERROR: Maven JVM terminated unexpectedly with exit code 134" which can be seen quite often. This is really annoying because it happens randomly and when it happens, it persists until I restart Hudson.
I consulted the mailing list and knew that exit code 134 indicates that the process crashed with SEGV or something like that.
But somehow I don't couldn't find hs_err_pid[PID].log or core dump on the current directory.
Then I dug an important message from syslog, saying
Nov 25 21:59:17 macmini com.apple.ReportCrash.Root[3736]: 2010-11-25 21:59:17.966 ReportCrash[3736:1407] Saved crash report for java[3732] version 1.0 (1.0) to /Library/Logs/DiagnosticReports/java_2010-11-25-215917_localhost.crash
It seems that Apple's JVM stores crash reports under /Library/Logs/DiagnosticReports/ as same as other native OSX apps.
Here's snippet of the crash report:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff82e7a3d6 __kill + 10
1 libSystem.B.dylib 0x00007fff82f1a972 abort + 83
2 com.apple.LaunchServices 0x00007fff80a31c9c GetOurLSSessionIDInit() + 298
3 libSystem.B.dylib 0x00007fff82e447fa pthread_once + 95
4 com.apple.LaunchServices 0x00007fff80a31b6a GetOurLSSessionAttributeBits() + 23
5 com.apple.LaunchServices 0x00007fff80a31b3b NormalizeLSSessionID(LSSessionID) + 28
6 com.apple.LaunchServices 0x00007fff80a30c10 _LSApplicationCheckIn + 44
7 com.apple.HIServices 0x00007fff85e473ce _RegisterApplication + 1086
8 com.apple.HIServices 0x00007fff85e4e926 SetApplicationIsDaemon + 90
9 libawt.jnilib 0x00000001150a9884 +[AWTStarter startAWT:] + 902
10 libawt.jnilib 0x000000011506d625 -[CPerformer perform] + 93
11 com.apple.Foundation 0x00007fff811f563b __NSThreadPerformPerform + 219
12 com.apple.CoreFoundation 0x00007fff8734be91 __CFRunLoopDoSources0 + 1361
13 com.apple.CoreFoundation 0x00007fff8734a089 __CFRunLoopRun + 873
14 com.apple.CoreFoundation 0x00007fff8734984f CFRunLoopRunSpecific + 575
15 java 0x0000000100004696 0x100000000 + 18070
16 java 0x0000000100003eee 0x100000000 + 16110
17 java 0x00000001000017b4 0x100000000 + 6068
0 libSystem.B.dylib 0x00007fff82e7a3d6 __kill + 10
1 libSystem.B.dylib 0x00007fff82f1a972 abort + 83
2 com.apple.LaunchServices 0x00007fff80a31c9c GetOurLSSessionIDInit() + 298
3 libSystem.B.dylib 0x00007fff82e447fa pthread_once + 95
4 com.apple.LaunchServices 0x00007fff80a31b6a GetOurLSSessionAttributeBits() + 23
5 com.apple.LaunchServices 0x00007fff80a31b3b NormalizeLSSessionID(LSSessionID) + 28
6 com.apple.LaunchServices 0x00007fff80a30c10 _LSApplicationCheckIn + 44
7 com.apple.HIServices 0x00007fff85e473ce _RegisterApplication + 1086
8 com.apple.HIServices 0x00007fff85e4e926 SetApplicationIsDaemon + 90
9 libawt.jnilib 0x00000001150a9884 +[AWTStarter startAWT:] + 902
10 libawt.jnilib 0x000000011506d625 -[CPerformer perform] + 93
11 com.apple.Foundation 0x00007fff811f563b __NSThreadPerformPerform + 219
12 com.apple.CoreFoundation 0x00007fff8734be91 __CFRunLoopDoSources0 + 1361
13 com.apple.CoreFoundation 0x00007fff8734a089 __CFRunLoopRun + 873
14 com.apple.CoreFoundation 0x00007fff8734984f CFRunLoopRunSpecific + 575
15 java 0x0000000100004696 0x100000000 + 18070
16 java 0x0000000100003eee 0x100000000 + 16110
17 java 0x00000001000017b4 0x100000000 + 6068
From the stack, I can see that the JVM crashed while initializing AWT and it appears to be a Mac OSX specific issue.
Then I googled with "AWTStarter crashed __NSThreadPerformPerform java com.apple.main-thread GetOurLSSessionIDInit" and found this thread.
・Comments about Nasty problem with headless mode in Tomcat 6-0-24
In fact just after receiving this email from you I also got one from
Apple saying that it's a bug and that they're trying to solve it.
Apple saying that it's a bug and that they're trying to solve it.
The above thread doesn't tell any solution or workaround, but the subject hints that it happens only on headless mode.
So I turned -Djava.awt.headless=false to true and the problem solved, yay!
Things learned from the issue:
- usually exit code 134 is caused by SEGV
- Apple's JVM dumps crash report to /Library/Logs/DiagnosticReports/java_YYYY-MM-DD-******_[hostname].crash
- Apple's JVM dies with code 134 occasionally and it's a known issue
- the issue can be workarounded with -Djava.awt.headless=true (or just without -Djava.awt.headless option)
Tweet |