Q) crash in openJ9 libcryp due to Memeory Violation in CRYPTO_memcmp - crash

The Context of my question
My server software is based on
openjdk version "1.8.0_242"
Nearly ever 2-3 week my server process crashes.
In the Java Dmp file is see that when doing
HttpsURLConnection conn = (HttpsURLConnection)myurl.openConnection();
there is a memory violation in the libcrypt-1_1 DLL in
4XENATIVESTACK CRYPTO_memcmp+0xe8ef8 (0x00007FFA122A5C18 [libcrypto-1_1-x64+0x185c18])
So for me it looks like that CRYPTO_memcmp
forces
1XHEXCPCODE Windows_ExceptionCode: C0000005
My Question
Did anybody observe a similar crash with openJ9 or have an idea about the root cause?
Many thanks in advance
Reinhold

I just think about my implementation which is a server and of cource I am using multitheading.
So I need to double check if libcrypto is Multi-Thread-safe.
If not then this could explain the crash.
But the real question is: Is the method myurl.openConnection()
realy thread-safe.
As far as I know it should be thread safe.
I will update with my finding as soon I found something

I think you've encountered OpenJ9 issue 8373 which is fixed in the 0.23 release of jdk8u275-b01.

Related

IntelliJ idea slow/hang during debug make phase

Currently experiencing very slow debug start up times (between 25-45 seconds) with idea CE 14.1.5. To reproduce:
Make change in code that will cause javac to be invoked.
Hit debug.
Status bar shows "Make" and entire IDE hangs.
I'm using a 2015 Macbook pro and Java 1.8.0_60 64bit.
After profiling with advice from above, I tracked it down to this issue:
IntelliJ freezes for about 30 seconds before debugging
Which in turn points to an issue with InetAddress.getLocalHost() on *nix. Following the advice in this linked post certainly helped it go away:
InetAddress.getLocalHost() throws UnknownHostException
I had similar problems of starting debugging application and tried different workaround tips to figure it out, but in my case i had a lot of forgotten breakpoints marked in application and removing them all application starts and performs lightening fast.
So, my advice remove all the breakpoints from the code at least at application startup.
You should assign more memory. This almost always reduces lagging / hanging issues. You can find a guide how to change this setting in IntelliJ manual.

Patching executable to avoid crashing

I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.

Devpartner reports GROOVEEX.DLL Leak exiting program

I'm using DevPartner 10.6.424.1 on x64 side, I see the huge leak in Grooveex.dll, i don't directly use this dll, i'm also seeing lots of false positive leaks. Anyone have experienced?, it is because devpartner is not good for x64 side?, any feedback is greatly appreciated.
Thanks
Well, I'm one of the developers on BoundsChecker. Could you bottle up a small example of this problem? Then I might be able to test it under my microscope. Other than that, I could only suggest you try our latest build . . . though that would require you to upgrade your license to 11.0.
The product has not been static: we have resolved quite a few issues since build 10.6.424.1, though I cannot guarantee we will have resolved your particular issue.

I have an error occurring in the machine code for a release that I wrote [duplicate]

I've got an app that gets information from a SOAP web service and I want to display the results in a UITableView.
I had a previous version of this app and I'm creating a new version to basically clean things up and get rid of a bunch of legacy code that's deprecated and no longer used.
In the previous version, this worked well. In the new version, not so much.
Basically, the current scenario is returning 3 strings that I'm trying to use as the basis for the data in my UITableView.
I'm struggling with this issue because it's so stinkin' hard to track down EXC_BAD_ACCESS errors!
(Parenthetically, if someone has a way to make the debug experience more like Visual Studio, I'd love to hear it! It's so frustrating to not have any idea which line caused the error, and also to not be able to look through my local variables at the time of the crash to see what's what. I've already added in the exception breakpoint, but that doesn't seem to do much.)
Anyway, the line that's causing the error APPEARS to be:
return [[self Libraries] count];
It occurs in tableView:numberOfRowsInSection:.
The error message I get APPEARS to reference a string that should be stored in the NSMutableArray [self Libraries].
What's going on here?
I'm using ARC, so shouldn't all of my memory management be correctly handled?
I don't have any manual release statements in my code ANYWHERE!
Please help me fix this!
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
ARC relies on the Apple standard/recommended naming practices. Check that you are not violating any of them.
Just for starters, if "Libraries" is an instance there are are naming issues.
OK, so I feel a little bit silly, but I've got two production machines. On one of them, I had installed a copy of Xcode 4.2 beta alongside the final, production copy. I forgot to uninstall the beta copy and was using it to run my code. As soon as I cleared that up and ran my code against the final, released Xcode 4.2, all works fine again.
As I mentioned to Jonathan Grynspan above, I DO understand Obj-C memory management. For some reason, I was getting a retain/release/release (performed by ARC), and that bug is remedied in the final version.
Thanks for the help in tracking this down! At least I got a definitive answer to WHY the problem existed!

System.Runtime.Remoting.RemotingException on Windows store app

I'm a new on windows 8 store app development, I got annoying problem with this IDE first time after I installed it, everything works well but on the time I got this exception event there are no error on my code. I always got it with different number of exception but the message is completely same. Here are the picture :
what should I do to fix this thing?? I need your help, thanks
I received the same exception after updating to VS 13 Update 3. This solution worked for me:
Go to C:\Users\{user}\AppData\Local\Microsoft\VisualStudio\12.0\Designer\ShadowCache and delete all the contents in that folder.
Source: https://connect.microsoft.com/VisualStudio/feedback/details/797072/designer-crashes-in-visual-studio-2013-with-system-runtime-remoting-remotingexception
Try running Blend as an administrator. It sounds a bit like this issue.
If you are building a Windows 8 Store application, keep in mind that the System.Runtime.Remoting APIs are not available in WinRT. See MSDN for a listing of all the .NET APIs that are supported here: http://msdn.microsoft.com/en-us/library/windows/apps/br230232.aspx.
Try removing the remoting code and see if this resolves the problem.
I ran into this same issue when I started using a static object variable, where the object loaded images from resource. Somehow this tripped up Blend (perhaps garbage collection with static variables was getting confused).
To fix it I just moved that static object variable inside my Application class as a non-static member and accessed it via a public accessor function.
UPDATE - I also ran into this when one of my DependencyObject implementations was causing a stack overflow, updating one property when another changes and vice versa... Look for stack overflows.
Hope this helps someone!
I had this, right now. The reproducible cause was a crash of the Display-Driver triggered by my code. As this might only be the Display-Drivers fault, it might just needs fixing in the Display-Driver - for the meantime you can try to find the location causing the Display-Driver to crash and do a workaround. But the Display-Driver should not crash, whatever you throw at it. I see strange colours and splits in your screenshots. So I assume something makes your Display-Driver crash also.
I have been receiving the same error after updating Microsoft Visual Studio 2013 to Update 3
Designer works with a new project but removing the code in old projects does not work.
Deleting all folders in C:\Users{user}\AppData\Local\Microsoft\VisualStudio\12.0\Designer\ShadowCache worked for me...
The workaround posted by #pcnThird doesn't work anymore. The issue was resolved in Update 1 and subsequently in the latest Visual Studio 2013 Update 3.