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.
Related
How can I determine where some function called in debug state? I'm in stuck with EXC_I386_GPFLT error hence I do not expect invocation such function with my test case.
You can try new Xcode 7 feature called Address Sanitizer.
In Xcode go to Product -> Scheme -> Edit Scheme, select Run, open Diagnostics tab and check Enable Address Sanitizer.
Then Product -> Clean project and run it again.
Objective-C and C code is susceptible to memory corruption issues such
as stack and heap buffer overruns and use-after-free issues. When
these memory violations occur, your app can crash unpredictably or
display odd behavior. Memory corruption issues are difficult to track
down because the crashes and odd behavior are often hard to reproduce,
and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled,
added instrumentation is built into the app to catch memory violations
immediately, enabling you to inspect the problem right at the place
where it occurs. Other diagnostic information is provided as well,
such as the relationship between the faulty address and a valid object
on the heap and allocation/deallocation information, which helps you
pinpoint and fix the problem quickly. The address sanitizer is
efficient—fast enough to be used regularly as well as with interactive
applications. It is supported in OS X, in the Simulator, and on iOS
devices.
New features in Xcode 7
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.
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.
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)}
My application is experiencing cashes in production.
The crash dump indicates a SIGSEGV has occurred in GCTaskThread
It uses JNI, so there might be some source for memory corruption, although I can't be sure.
How can I debug this problem - I though of doing -XX:OnError... but i am not sure what will help me debug this.
Also, can some of you give a concrete example on how JNI code can crash GC with SIGSEGV
EDIT:
OS:SUSE Linux Enterprise Server 10 (x86_64)
vm_info: Java HotSpot(TM) 64-Bit Server VM (11.0-b15) for linux-amd64 JRE (1.6.0_10-b33), built on Sep 26 2008 01:10:29 by "java_re" with gcc 3.2.2 (SuSE Linux)
EDIT:
The issue stop occurring after we disable the hyper threading, any thoughts?
Errors in JNI code can occur in several ways:
The program crashes during execution of a native method (most common).
The program crashes some time after returning from the native method, often during GC (not so common).
Bad JNI code causes deadlocks shortly after returning from a native method (occasional).
If you think that you have a problem with the interaction between user-written native code and the JVM (that is, a JNI problem), you can run diagnostics that help you check the JNI transitions. to invoke these diagnostics; specify the -Xcheck:jni option when you start up the JVM.
The -Xcheck:jni option activates a set of wrapper functions around the JNI functions. The wrapper functions perform checks on the incoming parameters. These checks include:
Whether the call and the call that initialized JNI are on the same thread.
Whether the object parameters are valid objects.
Whether local or global references refer to valid objects.
Whether the type of a field matches the Get<Type>Field or Set<Type>Field call.
Whether static and nonstatic field IDs are valid.
Whether strings are valid and non-null.
Whether array elements are non-null.
The types on array elements.
Pls read the following links
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/html/jni_debug.html
http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmtq
Use valgrind. This sounds like a memory corruption. The output will be verbose but try to isolate the report to the JNI library if its possible.
Since the faulty thread seems to be GCTaskThread, did you try enabling verbose:gc and analyzing the output (preferably using a graphical tool like samurai, etc.)? Are you able to isolate a specific lib after examining the hs_err file?
Also, can you please provide more information on what causes the issue and if it is easily reproducible?