I've been contacted because this site crashes Safari everytime you click on any select in the search box (you might have to scroll a bit).
There's no error in the Developer Tools console and Safari throws an error everytime it crashes. I posted a sample here. A small extract of the error so it lets me post the pastebin link:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [0]
Application Specific Information:
Crashing on exception: -[__NSCFNumber length]: unrecognized selector sent to instance 0x7767687437
I've tried everything:
Changing the option values (to only numerics, to not contain negative numbers, to not have duplicates...)
Removing all non-bootstrap CSS code affecting the selects.
Removing all JS code affecting the form.
Removing all JS code on the site.
Disabling JS in Safari, clearing the caches, blocking cookies...
Installing Midori, another Webkit-based browser, to see if it also crashed. It didn't, so it seems a Safari-specific bug.
Installing Safari Technology Preview to check if it is fixed. Nope.
Nothing worked. It crashes everytime you click on a select.
Has anyone found this problem before? Any idea on how to fix it? To me it clearly seems like a Safari bug. After two days trying to make it work, I'm seriously thinking about telling my client that Safari has a problem and he should contact Apple Support.
After some time-wasting testing, I nailed it down to the webfont used in the site, Comfortaa. Apparently using this font with font-weight: 300 (loaded from Google fonts) in a select will make Safari crash when you click on it.
Yet another proof that Safari is the new IE.
Related
I run into a Problem with vueJS at version 2.6.11 and Safari version 12 and 13.
On some pages of the webapp the vue watchers are not initalizing correctly, appearently because of a race-condition inside the vue initalization.
The error results in, that on some pages of the Webapp, none of the v-if bindings and stuff like this works anymore.
Currently on version 2.6.11 i even do not get an error. Luckily on an older version (don't remember exactly which one it was), i got an console error which leaded me to:
this.getter.call(vm, vm);
in vue/src/core/observer/watcher.js:106
with the error string does not match the expected pattern
setting breakpoints to this part of the code, when the exception appeared, and running this.getter.call(vm, vm); again using the browser console, results in a working page after the rendering is finished. So it seems to be because of a race-condition i guess ?
This part of the code is called multiple times during the app initalization.
this.getter is using the function function (){e._update(e._render(),n)} (minified), when the error appears.
Anyone encountered the same issue, and/or knows a fix for this problem ?
I faced with problem in crashlytics ndk stacktrace parcing. All or particular lines in stacktrace is "missing".
I simulated crash on device ( nullptr SIGSEGV ) and got human frienly stacktrace in logcat with correct functions names.
At next session crashlytics properly sent the report, but in Fabric's dashboard I see that this crash has "missing" lines, despite the fact that it's correct in logcat.
The chance of the properly crash parsing increases when I upload the symbols. But only for the last build and not for all crashes.
It means that crashlytics stores only single symbols copy for all application versions so old version will send stacktrace with "missing" lines.
After all of that, I try to investigate mechanic of catching and parsing crashes in Android and create my sigaction catcher with libunwind.
It's give me the correct stacktrace which I put to crashlytics payload ( context->log() ).
Next, I return signal to crashlytics sigaction handler.
Finally, I have "missing" lines stacktrace in Fabric's report and valid stacktrace in my payload.
Sometimes this approach causes crashes in OS below android 8.0, I think its because I use non-safe-signals functions, but it still works on android 8+.
Also I created linker map file (-Xlinker -Map=output.map), but I can't link it with fabric report istead of my self-made stacktrace.
So, the question is: why the lines in crashlytics stacktrace is "missing" in this situation while logcat and simple sigaction catcher provides correct stacktraces?
Versions:
crashlytics 2.9.3
crashlytics-ndk 2.0.4
Code:
Fabric.with(context, new Crashlytics(), new CrashlyticsNdk());
I'm building this app in RN and after upgrading to 0.49, it started crashing only when in "release" mode. It crashes right after it starts. It took me awhile to even trace down the crash point because my crash reporter (bugsnag) isn't even triggering.
I set the scheme in xcode to "release" and I was finally able to reproduce the crash with a tethered device.
The output is:
43 JavaScriptCore 0x00000001880011ac _ZN3JSC8evaluateEPNS_9ExecStateERKNS_10SourceCodeENS_7JSValueERN3WTF8NakedPtrINS_9ExceptionEEE + 316
44 JavaScriptCore 0x000000018836a558 JSEvaluateScript +2017-10-15 02:54:24.331 [error][tid:com.facebook.react.JavaScript] undefined is not an object (evaluating 's.View.propTypes.style')
B56
INFO : BSG_KSCrashReport.c (2157): void bsg_kscrashreport_writeStandardReport(BSG_KSCrash_Context *const, const char *const): Writing crash report to /var/mobile/Containers/Data/Application/00FD4F8E-DFF5-4166-982B-0D4AB56048DE/Library/Caches/KSCrashReports/GP/GP-CrashReport-0659B2B2-1DB4-48B9-BDDB-5EC72DE8B201.json
2017-10-15 02:54:24.354 [fatal][tid:com.facebook.react.ExceptionsManagerQueue] Unhandled JS Exception: undefined is not an object (evaluating 's.View.propTypes.style')
2017-10-15 02:54:24.357 [error][tid:com.facebook.react.JavaScript] Module AppRegistry is not a registered callable module (calling runApplication)
INFO : BSG_KSCrashReport.c (2157): void bsg_kscrashreport_writeStandardReport(BSG_KSCrash_Context *const, const char *const): Writing crash report to /var/mobile/Containers/Data/Application/00FD4F8E-DFF5-4166-982B-0D4AB56048DE/Library/Caches/KSCrashReports/GP/GP-CrashReport-9288B937-E697-4571-AE3D-5377FB7EABAE.json
libc++abi.dylib: terminating with uncaught exception of type NSException
I suspect it's being caused by the bundler.. Could be Babel or something else. I've tracked down any references to "*.propTypes.style" and commented them out, thinking it'd be those, but that didn't change the result. It still crashes.
Any suggestions would be much appreciated. Thanks!
Try to
1) run your app in debug mode
2) uncheck 'JS Dev Mode' in Dev Settings
3) Reload app
you will see some errors related to propTypes.
I had a similar issue. by disabling JS Dev Mode I figured out my packages are using View.PropTypes.style.
In another similar issue, it was from fabric crashlytics. I changed it's version and problem solved.
I too suffered from this problem. The issue ended up being that some of the components I used were still using:
View.PropTypes.style
Unfortunately had to revert back to react-native 48.4 until the respective packages were updated.
In my case it was react-native-facebook-login.
Try searching your node modules to find the specific components using the above and inform the dev that it needs to be updated to be compatible with 0.49.x
Try to check log where it is breaking with adb log in simulator
View.proptypes is deprecated in latest react
native.use ViewPropTypes instead of View.proptypes.
import {ViewPropTypes } from 'react-native';
styles: PropTypes.shape({
view: ViewPropTypes.style,
})
From your logs, I can see 2 problems:
You use a third party module using ...View.propTypes. It'll not crash in debug mode, but it'll display a red screen during the launch
The module name you use, is not the right one.
Problem: I am unable to launch my OSX app.
Software versions:
XCode Version 8.1 (8B62)
macOS Siera 10.12.1 (16B2657)
I've already tried:
I don't have any changes in my version control.
Also it works fine on my colleague's computer
I've already tried to clean, Also used deep clean
I've overloaded my mac twice
I've already removed derived data
But still unable to run OSX app. It just build successfully all the time and isn't going to launch my app.
I googled about it.
https://www.google.com/search?q=xcode+%22build+secceded%22&oq=xcode+%22build+secceded%22&aqs=chrome..69i57.12138j0j7&sourceid=chrome&ie=UTF-8#q=xcode+%22build+succeeded%22+%22App+doesn%27t+run%22
But haven't found something helpful.
Any suggestions? Probably I missed something... but I think it is a system bug. And I have to clean or relaunch something. But I've already tried all what I was able to guess.
Information from console:
/Users/UserName/Library/Developer/Xcode/DerivedData/AppName-awtljghmrbqhgebrvruwulpmysqx/Build/Products/Debug/App Name.app/Contents/MacOS/App Name signature not valid: -67030
proc 1042: load code signature error 4 for file "App Name"
AMFI: allowing exception handler for 'App Name' (2504) because the process is unsigned.
Got a connection, waiting for process information for launching or attaching.
error: Attach failed: "No such process".
error: attach failed.
1 +0.000000 sec [09c9/1503]: error: ::read ( 3, 0x700009325a40, 1024 ) => -1 err = Bad file descriptor (0x00000009)
Exiting.
PS
Any way. thanks for attention.
I just changed my sandboxed app's bundle identifier, and ran it. I get a runtime exception before main() even runs. The top of the stack trace is runtime_init. I tried running the app outside of Xcode and got the standard crash report dialog. Scrolling through the information presented, I noticed:
Application Specific Information:
dyld: launch, running initializers
/usr/lib/libSystem.B.dylib
xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The operation couldn’t be completed. (Cocoa error 13.)
As soon as I run another time, there's no problem. I see that the container exists. As soon as I remove the container, though, the exception gets thrown again. I don't want my users' first experience with my app to be a crash. How can I fix this?
I tried repairing permissions, which made no difference. I also noticed that by the time Xcode breaks on the exception, the container has already been created. Also, Craig Hockenberry mentioned this error in a blog post, but he blamed symlinks in the user's Home directory. I don't have any symlinks there (not in the top level, at least, which is what I assume he means).
Additional input on Twitter suggests that it can be a symlink anywhere, in which case I definitely do have some. Has anyone discovered a workaround for it? I suppose that would be tough, as no application code executes before the exception. Hopefully Mountain Lion will fix it...?
Finally solved this crash by removing everything from the Desktop, Documents, Downloads, Movies, and Pictures user directories. I assume it's related to the sym link issue mentioned in other threads.