Uncaught exception java.lang.stackoverflowerror - jmeter-3.2

I am getting the error "Uncaught Exception java.lang.stack overflow error null in Jmeter while performing only one thread. Initially, all requests passed, when I try to click on 11th request to see the HTML response type it starts throwing errors. Since that page contains more images with search functionality

You can run the Java VM with a larger stack size by applying a flag like -Xss1024k. From what I found, the default is 1024k (1 MB).
For example:
$ java -Xss2048k -jar myfile.jar
or
$ java -Xss256m -jar myfile.jar
The alternative is to optimize your code. However,
Premature optimization is the root of all evil.
- Donald Knuth

Related

Eclipse: Invalid maximum heap size:

I'm getting error messages on Eclipse (Mac):
Invalid maximum heap size: -Xmx5120m-Djavax.net.ssl.trustStore=/usr/local/keystore/JavaKeyStore.jks-Djavax.net.ssl.trustStorePassword=changeit-Dtls.key.store=/usr/local/keystore/JavaKeyStore.jks-Dtls.trusted.store=/usr/local/keystore/JavaKeyStore.jks-Dawsmock.directory=/ijmeang/elis/s3-mock-Dcatalina.base=/usr/local/workspace/workspace-eclipse/.metadata/.plugins/org.eclipse.wst.server.core/tmp0-Dcatalina.home=/Library/Tomcat-Dwtp.deploy=/usr/local/workspace/workspace-eclipse/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps-Djava.endorsed.dirs=/Library/Tomcat/endorsed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
How can I fix this?
Here are the arguments on Eclipse:
-Dcatalina.base="/usr/local/workspace/workspace-eclipse/.metadata/.plugins/org.eclipse.wst.server.core/tmp0" -Dcatalina.home="/usr/local/Tomcat-7.0.6.9" -Dwtp.deploy="/usr/local/workspace/workspace-eclipse/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps" -Djava.endorsed.dirs="/usr/local/Tomcat-7.0.6.9/endorsed" -Xss768m -Xmx5120m -XX:MaxPermSize=5120m -DmasterPropertiesLinux
I would suggest trying to decrease your value of -Xmx5120m, as described here:
https://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
Some JVMs put restrictions on the total amount of memory available on the heap.
It depends on what Java are you using. If you are using 32 bit Java you may not be able to use more than 2GB.

JMeter performance plugin report always showing 100% of errors on 200 success response code

After the build is completed, in the performance Trend report error column displays 100% error whereas the HTTP Response code is 200 (Successful)
Expected Result: That should be 0% error in error column.
We have performance plugin 1.13 in jenkins 1.607
My .jtl file contains:
1434631428652,2082,Deactivate_Enrollee,200,OK,setUp Thread Group 1-1,text,true,536,2073
1434631430748,574,Activate_Enrollee,200,OK,setUp Thread Group 1-1,text,true,536,574
1434631431323,315,User_Status,200,OK,setUp Thread Group 1-1,text,true,1317,315
1434631431711,1,Debug Sampler,200,OK,setUp Thread Group 1-1,text,true,807,0
Console output:
Started by user anonymous
Building in workspace /results/jtls
Performance: Percentage of errors greater or equal than 0% sets the build as unstable
Performance: Percentage of errors greater or equal than 0% sets the build as failure
Performance: Recording JMeter reports '*.jtl'
Performance: Parsing JMeter report file APITest_JMeter.jtl
Performance: File APITest_JMeter.jtl reported 100.0% of errors [FAILURE]. Build status is: FAILURE
Build step 'Publish Performance test result report' changed build result to FAILURE
Finished: FAILURE
Can anyone solve this for Jenkins?
It seems that it is due to a defect in Performance Plugin version 1.13.
You may use Performance Plugin version 1.9 or below and let us know if this resolves your issue.
Your jtl file is wrong for the plugin from :
https://github.com/jenkinsci/performance-plugin/blob/master/src/main/java/hudson/plugins/performance/JMeterCsvParser.java#L157
So this leads to failure of parsing this value to a boolean by this code:
sample.setSuccessful(Boolean.valueOf(values[successIdx]));
I think your configuration of saveservice is not well suited for the plugin, you should set:
jmeter.save.saveservice.response_message=false
I think you may be facing well-known critical bug 28426 of Performance Plugin.

JVM crashes frequently

JVM crashes surprizingly and frequently on our prod environment and results in Jboss (EAP6.3) going down. We have java7 U72 installed
Crash logs has same output where current thread is:
Current thread (0x00000000d1d99000): JavaThread "Lucene Merge Thread #0" daemon [_thread_in_Java, id=1144, stack(0x00000000f6a00000,0x00000000f6b00000)]
and all the log is full of :
JavaThread "elasticsearch[Node BD852E44][search][T#68]" daemon [_thread_blocked, id=14396, stack(0x00000000f7b30000,0x00000000f7c30000)]
elasticsearch is some were related to indexing and it uses Lucene in hood as far as I understand but we have number or application deployed how to check on this can someone please help. complete crash logs are at : http://pastebin.com/845LU9iK
Looks like it didn't manage to record stack traces for the affected thread.
If that's the same for all crashes then it doesn't seem to match known lucene or jboss bugs.
# guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
AIUI this indicates an error in native exception handling, so it's one error masking another, probably making this crash log fairly useless.
So I can only provide really generic advice:
you're using an older JVM version, update to the latest java 7, java 8 or possibly even a java 9 dev build and see if it goes away. Even if they still crash they might provide different/more useful error reports
to diagnose potential compiler bugs you can try running with the following flags
-XX:-TieredCompilation 1 should disable the C1 compiler
-XX:+TieredCompilation -XX:TieredStopAtLevel=1 should disable the C2 compiler
-Xint disables all JIT, very slow
ask on the hotspot-dev mailing list for further guidance
1: Tiered compilation is a new java 7 feature, it basically combines the interpreter, C1 and C2 JIT compilers (which formerly were used separately in the client and server VMs) into different optimizing stages.
Each of them can have optimization bugs. Turning off individual stages helps isolating them as potential cause.
Edit: The new crash report is more useful since it at least has java frames, the interesting part is the following:
J 1559 sun.misc.Unsafe.getByte(J)B (0 bytes) # 0x000000000178e99b [0x000000000178e960+0x3b]
j java.nio.DirectByteBuffer.get()B+11
j org.apache.lucene.store.ByteBufferIndexInput.readByte()B+4
J 9447 C2 org.apache.lucene.store.DataInput.readVInt()I (114 bytes) # 0x000000000348cc00 [0x000000000348cbc0+0x40]
DataInput.readVInt seems to be an ongoing source of grief, see this SO answer for possible solutions

V8 version in node and ChromeDevTools?

My main questions are:
What version of V8 am I running from node 0.4.10?
How can I tell if this version is compatible with ChromeDevTools 0.2.2 in Eclipse?
Background: I've almost got Eclipse working for debugging node.js remotely. In fact it works perfectly (after adding a server proxy) for a simple "Hello World" app, but it won't hook up properly when I add "express" to the mix. The Eclipse error is:
An internal error occurred during: "Debug session initialization:
Remote NodeJS". Exception occured in callback
...which I tracked down to line 61 of the this source code (Thanks to the misspelling of "occured".)
I'd like to eliminate version skew possibilities before going further.
EDIT: Dug the stack trace out of the error log. Hmmm, maybe I have an encoding problem in my server proxy?
java.lang.RuntimeException: Exception occured in callback
at org.chromium.sdk.CallbackSemaphore.tryAcquire(CallbackSemaphore.java:61)
at org.chromium.sdk.CallbackSemaphore.tryAcquireDefault(CallbackSemaphore.java:29)
at org.chromium.sdk.internal.JavascriptVmImpl.getScripts(JavascriptVmImpl.java:33)
at org.chromium.debug.core.model.VProjectWorkspaceBridge.reloadScriptsAtStart(VProjectWorkspaceBridge.java:121)
at org.chromium.debug.core.model.LaunchInitializationProcedure.execute(LaunchInitializationProcedure.java:80)
at org.chromium.debug.core.model.LaunchInitializationProcedure.access$0(LaunchInitializationProcedure.java:64)
at org.chromium.debug.core.model.LaunchInitializationProcedure$1.run(LaunchInitializationProcedure.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.Exception: Exception saved from callback
at org.chromium.sdk.CallbackSemaphore.callbackDone(CallbackSemaphore.java:72)
at org.chromium.sdk.internal.DebugSession$ScriptLoader$2.callbackDone(DebugSession.java:276)
at org.chromium.sdk.internal.tools.v8.BaseCommandProcessor.callThemBack(BaseCommandProcessor.java:136)
at org.chromium.sdk.internal.tools.v8.BaseCommandProcessor.processIncoming(BaseCommandProcessor.java:103)
at org.chromium.sdk.internal.tools.v8.V8CommandProcessor.processIncomingJson(V8CommandProcessor.java:109)
at org.chromium.sdk.internal.StandaloneVmImpl$4.messageReceived(StandaloneVmImpl.java:108)
at org.chromium.sdk.internal.transport.SocketConnection$RegularMessageItem.report(SocketConnection.java:120)
at org.chromium.sdk.internal.transport.SocketConnection$ResponseDispatcherThread.run(SocketConnection.java:206)
Caused by: java.lang.RuntimeException: org.eclipse.core.internal.resources.ResourceException: < is an invalid character in resource name '<eval #83>.chromium'.
at org.chromium.debug.core.util.ChromiumDebugPluginUtil$4.tryCreate(ChromiumDebugPluginUtil.java:247)
at org.chromium.debug.core.util.ChromiumDebugPluginUtil$4.tryCreate(ChromiumDebugPluginUtil.java:1)
at org.chromium.debug.core.util.UniqueKeyGenerator.createUniqueKey(UniqueKeyGenerator.java:22)
at org.chromium.debug.core.util.ChromiumDebugPluginUtil.createFile(ChromiumDebugPluginUtil.java:254)
at org.chromium.debug.core.model.ResourceManager.createAndRegisterResourceFile(ResourceManager.java:106)
at org.chromium.debug.core.model.ResourceManager.addScript(ResourceManager.java:72)
at org.chromium.debug.core.model.VProjectWorkspaceBridge$2.success(VProjectWorkspaceBridge.java:131)
at org.chromium.sdk.internal.DebugSession$ScriptLoader$1$1.call(DebugSession.java:236)
at org.chromium.sdk.internal.DebugSession$ScriptLoader$1.processCall(DebugSession.java:258)
at org.chromium.sdk.internal.DebugSession$ScriptLoader$1.success(DebugSession.java:233)
at org.chromium.sdk.internal.tools.v8.V8Helper$2.success(V8Helper.java:120)
at org.chromium.sdk.internal.tools.v8.V8CommandCallbackBase.messageReceived(V8CommandCallbackBase.java:25)
at org.chromium.sdk.internal.tools.v8.V8CommandCallbackBase.messageReceived(V8CommandCallbackBase.java:1)
at org.chromium.sdk.internal.tools.v8.BaseCommandProcessor$2.call(BaseCommandProcessor.java:99)
at org.chromium.sdk.internal.tools.v8.BaseCommandProcessor$2.call(BaseCommandProcessor.java:1)
at org.chromium.sdk.internal.tools.v8.BaseCommandProcessor.callThemBack(BaseCommandProcessor.java:129)
... 5 more
Caused by: org.eclipse.core.internal.resources.ResourceException: < is an invalid character in resource name '<eval #83>.chromium'.
at org.eclipse.core.internal.resources.Resource.checkValidPath(Resource.java:432)
at org.eclipse.core.internal.resources.File.create(File.java:116)
at org.eclipse.core.internal.resources.File.create(File.java:196)
at org.chromium.debug.core.util.ChromiumDebugPluginUtil$4.tryCreate(ChromiumDebugPluginUtil.java:245)
... 20 more
process.versions in the repl reveals this information:
> process.versions
{ node: '0.4.10', v8: '3.1.8.26', ares: '1.7.4', ev: '4.4', openssl: '1.0.0d' }
There shouldn't be any version-related problem here, at least at initialization stage.
V8 debug protocol is evolving quite slowly.
Unfortunately the message you cite is too general. Do you think you can find a stacktrace somewhere? The message may have 'details' button (but you would probably spot it), also the exception is usually logged. You can try to open a view "General->Error Log" (available in most Eclipse configurations), or you can take a look inside a file in your Eclipse workspace: /.metadata/.log.
The code indicates that there is a cause exception, which is missing from the error message.
Thank you for the spelling error report. :)

ClickOnce: DeploymentDownloadException: The operation has timed out

Symptom: ClickOnce installation starts and stops after around 600 kB (out of 2 MB).
Progress bar always stops at the same value (tried ten times).
Error log says that The operation has timed out (in inner exception) and fails with "DeploymentDownloadException (Unknown subtype)".
Error log details (irrelevant information trimmed):
ERROR DETAILS
Following errors were detected during this operation.
System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
- Downloading http://fullpath/name.dll.deploy did not succeed.
- Source: System.Deployment
- Stack trace: at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(Downloa
dQueueItem next)
at
System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
at
System.Deployment.Application.FileDownloader.Download(SubscriptionState
subState)
--- Inner Exception ---
System.Net.WebException
- The operation has timed out.
- Source: System
- Stack trace:
at System.Net.ConnectStream.Read(Byte[] buffer,
Int32 offset, Int32 size)
at
System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(Downloa
dQueueItem next)
This only happens for two customers. The install works OK for thousands of others. I have found numerous posts via google with no answer or generic "firewall is the issue" or "customer was using dialup".
Has anyone solved this? Is this a ClickOnce bug?
Disabling firewall software on the machine did not help because a hardware firewall installed on the network was the cause (FortiGate 30B).
I doubt that it's a bug. However, it seems like it gets stuck at one file in the deployment path. Maybe it is a type of file that is blocked by a firewall.
I would just remove all files but one from the build and see if that gets downloaded ok, and then add the rest of the files one by one (or maybe type by type) and see at what file ClickOnce gets stuck downloading.
If that doesn't seem to do anything, I'd build a dummy app and deploy it with ClickOnce and see if it installs at all on the customer's box.