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());
Related
In relation to this post:
After upgrading from revit 21 to 22 in my company, we can no longer view anything else than the default 3D model in our forge viewer. Initially, i thought the issue arose due to this warning:
"Deprecated API usage: No "GlobalWorkerOptions.workerSrc" specified.".
However, i got that same message in the console of a working implementation i made today, leading me to believe that it has nothing to do with this warning at all.
However, i also see another warning:
"Warning: getOperatorList - ignoring errors during "GetOperatorList: page 0" task: "r: Cannot read properties of undefined (reading 'X')"."
I have tried creating a new nuxt app on Node version 14.9.0, implemented a forge viewer in accordance with the official v7 documentation, and the bug is no longer present.
I then tried to mimic that in my actual production app where the problem exists, by running it on Node version 14.9.0 instead of 10.0.0, getting rid of my entire forge implementation and implemented a simple viewer like above. That did not solve the problem, and i still see above warnings in the console.
The warning is thrown in pdf.worker.jss, which is loaded in via "webpack://adsk/node_modules/#adsk/pdfjs-dist/legacy/build/pdf.worker.jss".
I hope someone has a suggestion.
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.
Background: I decided a couple days ago that I was going to update Facebook SDK to FBSDKCoreKit from Facebook-iOS-SDK v3.24. I updated my Podfile accordingly and installed all libraries fine. I then began updating some of the code to work with the updated SDK spec.
After working on it for a short amount of time, I changed my mind and decided to rollback to the old version. I made all necessary cocoapods changes and installs, discarded all local changes in Xcode, recompiled and ran. Everything worked fine... or so I thought.
The Problem: Now, when I try to run on my old iOS7 test device, I get an error whenever the app launches. Below is the exact console output:
2015-10-15 20:14:31.271 hiatus[184:6003] [Error]: Failed to run command eventually with
error: Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be
completed. (Cocoa error 3840.)" (JSON text did not start with array or object
and option to allow fragments not set.) UserInfo=0x14d67d20 {NSDebugDescription=
JSON text did not start with array or object and option to allow fragments not set.}
After this error is displayed in the console, no Parse functionality works. Which means, in my case, that a user is unable to login. An empty error is displayed instead.
Everything works fine on iOS8, and iOS9 (simulators and real devices). I'm working with Parse v1.9. I've tried cleaning the project, resetting, etc, but without any success.
I've been able to track this down to a specific function within PFEventuallyQueue.m. It seems to occur within (void)_runCommandsWithRetriesCount:. I just have no way of knowing how to fix it.
This is a known issue with SDK v1.9.0 (https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/388). It has been fixed but not released yet (it will be part of the 1.9.1 release).
You have 3 options :
Use 1.8.5 until 1.9.1 is released.
Fix the bug yourself by making this change : https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/commit/edde3bfa8a4476ba460dddbef6f75772960e1718
Use the master branch of the git repository to get the latest commits. If you're using cocoapods you can do it by setting your pod like this : pod 'Parse', :git => 'https://github.com/ParsePlatform/Parse-SDK-iOS-OSX.git'
Now is available Parse 1.9.1 but I recommend using CocoaPods for any Framework: https://cocoapods.org/pods/Parse
Since upgrading to OSX 10.10, I have been getting these odd errors when running xcodebuild, the following in the terminal output:
xcodebuild[6484] (FSEvents.framework) FSEventStreamStart:
register_with_server: ERROR: f2d_register_rpc() => (null) (-21)
xcodebuild[6484] (FSEvents.framework) FSEventStreamInvalidate():
failed assertion 'streamRef != NULL'
xcodebuild[6484] (FSEvents.framework) FSEventStreamRelease(): failed
assertion 'streamRef != NULL'
xcodebuild[6484:104132] DVTFilePathFSEvents: Failed to start fs event
stream.
This hasn't been a particular problem, as my scripts will just continue and xcodebuild is fine, however today I found that some apps that use xcodebuild (like TestFlight) will see this as an error and stop working.
I tailed the system log and found the culprit may be Mac Mail, with constant entries like this:
fseventsd[20]: implementation_added_client : failed to add client for
path /Users/mok9/Library/Mail/V2/IMAP-...[removed full path for
privacy]...
Quitting Mac Mail caused this issue in xcodebuild to go away... that was not a dependency I was expecting!
So, is the Mail issue just a symptom of another problem, or is Mail setting up some issue that causes xcodebuild to be affected? I suppose I am less concerned about the Mail issue and more concerned with what causes Xcode to be affected by this issue...
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.