I keep getting this error:
Jan 31 13:56:51 Michaels-MacBook-Air.local CocoaDrawing[2129] <Error>: The function 'CGContextErase' is obsolete and will be removed in an upcoming update. Unfortunately, this application, or a library it uses, is using this obsolete function, and is thereby contributing to an overall degradation of system performance.
My program doesn't call that method directly, and frustratingly, I can't find any documentation on this function.
This happens even with a blank (Cocoa) Xcode project. Why am I getting this error?
I had this problem. It was caused by an outdated Wacom Tablet driver. If you have such a driver installed I'd recommend removing it, then reinstalling a more recent driver. That did the trick for me.
Related
My Android app use web view like control based on Chromium 50 (V8 JavaScript engine 5.0). Using system WebView or newer Chromium version is not an option because of various reasons.
I receive a lot of Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR) crashes on Android 10 and arm64 version of the binary only. The same binary with older Android versions as well as 32 bit version of the binary with Android 10 has no problem.
Here is an example code containing infinite recursive function which crashes:
webView.evaluateJavascript("(function a(i) { a(i++); })()", null);
Stack trace from Android studio debugger:
art_sigsegv_fault 0x000000753da02e9c
art::FaultManager::HandleFault(int, siginfo*, void*) 0x000000753da033a4
___lldb_unnamed_symbol24$$app_process64 0x0000005ca3207da8
<unknown> 0x00000075c3f888c0
<unknown> 0x00000074784191e8
<unknown> 0x00000074784191e8
<unknown> 0x00000074784191e8
<unknown> 0x00000074784191e8
<unknown> 0x00000074784191e8
............... the same line 15560 times
<unknown> 0x000000747830be94
<unknown> 0x000000747841937c
<unknown> 0x0000007478339a28
<unknown> 0x000000747831fe30
Any ideas how to avoid these crashes are welcome.
V8 developer here. The link you mentioned talks about system libraries. I don't know of any reason why V8 would try to read system libraries. Are you sure that's what's happening? Can you run a Debug build and get a stack trace? Without further data, I would suspect that there's something else that's going on and causing those crashes.
FWIW:
--untrusted-code-mitigations causes the (optimizing) compiler to emit code sequences that (partially) mitigate the recently discovered "spectre" CPU security bugs. That's totally unrelated to Android 10 compatibility.
--jitless turns off all just-in-time code generation in new enough versions of V8 (at a significant performance cost, of course). That, too, is unrelated to execute-only memory for Android system binaries.
Update after updated question, and discussion in comments:
Based on the stack trace, it seems that the process crashes when it runs out of stack space. V8 is supposed to detect that situation and throw a RangeError before that happens; the mechanism to accomplish that works by knowing an estimate of how much stack space will be available to a process. Apparently for (at least) the specific combination of your app running on Android 10, there is less remaining stack space than V8 v5.0 expects. A workaround is to run with the flag --stack-size=800, or alternatively, to edit the V8_DEFAULT_STACK_SIZE_KB constant in src/globals.h.
A note to other readers: setting --stack-size to a huge value will not magically give you deeper recursion limits; instead it will let your process crash when the operating system defined stack limit is exceeded, rather than throwing a RangeError. Setting --stack-size too low will mean that JavaScript code won't be able to have many deep function calls (or, in the extreme, not run at all) before throwing a RangeError. It is generally recommended to leave this flag alone, unless you're running into a specific issue like here, where a small adjustment helps.
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
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.
In the past, I have tried to decrypt PDFs using PDFBox using the following code:
if (doc.isEncrypted()){
doc.openProtection(new StandardDecryptionMaterial(password));
doc.setAllSecurityToBeRemoved(true);
}
(Note that I don't use doc.decrypt(password) because the Javadoc for decrypt() says that openProtection() should be used instead, although why it's not just deprecated is beyond me).
Anyway, this has worked fine for quite a while. However, lately I seem to be getting the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not properly padded
at javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
<Stack trace continues with my call to openProtection()>
How can I fix this problem?
This is a known issue, which appears to have been introduced as a result of a Java update. At the time of this writing, a fix for this is in review to be included in version 1.8.8, so just upgrade to version 1.8.8 or later and this problem will go away.
I'm developing an app on Mac OS X which is suspected to crash sometimes (well, not due to my app, but due to unstable third-party plug-ins it loads. This app actually acts as a crash firewall; many crashes can happen at startup, so no need to bug the user about it at this time).
Is there a way to prevent the crash report window from popping in front of the user?
Thanks!
PS: this is about this window, but not for WebKit:
I'm not aware of any really supported solution, but there are some (ugly) ways to achieve it.
First, you need to catch the signal yourself. I assume you know how to do that (see sigaction). Then within your crash signal handler, call _exit(). That's with a leading underscore. It's a faster, less safe version of exit(). This will typically avoid the crash reporter. I've used this in some C++ projects that had such flakey memory management that they often crashed on shutdown. I'm not proud of it; I'm just saying it works....
The other solution is to launch another second process during your crash handler. The second process waits around for CrashReporter to launch. When it does, kill it. The last time I tested this approach was 10.5. I don't know if 10.7 still launches the same kind of process to display that alert.
For a system-wide solution, read man ReportCrash. However this solution is not specific to an application.
Using cli Swift 4.2.1
Building on Rob Napier's answer.
I don't know how signal(3) becomes Darwin.signal(_:Int32,_:#convention(c)(Int32)->()) but the following actually works (preventing reporter for uncaught NSException), whereas temporarily doing and reverting defaults write com.apple.CrashReporter DialogType none && defaults write com.apple.CrashReporter UseUNC 1 (from osxdaily.com 2010 & 2015) (on my macOS 10.13) does not work.
import Darwin
signal(SIGABRT ){n in _exit(128+n)}
(Using Bash(1) signal exit(3) convention.)
Moving on, I find "Unexpectedly found nil"-errors (from implicit unwrapping in my case) uses another signal:
signal(SIGILL ){n in _exit(128+n)}
This also skips the builtin call stack printing and though it doesn't show where the nil's found anyway, a variant can be printed by the following:
import Darwin
import Foundation
Thread.callStackSymbols.forEach{fputs($0+"\n",stderr)}