I'm not being able to use the debugger in a UNNotificationServiceExtension.
Here's what I do when attempting to attach the debugger to the UNNotificationServiceExtension:
Run app
Set the breakpoint in the "Testing" UNNotificationServiceExtension
Select Debug > Attach to Process by PID or Name > Select the "Testing" UNNotificationServiceExtension
XCode indicates that the "Testing is waiting to attach"
I then send a push notification and my iPhone displays the notification, but the debugger doesn't hit the breakpoint. Instead, XCode shows a "Thread1: signal SIGKILL".
Does anyone know how to get the debugger to work in a UNNotificationServiceExtension?
Don't hit run on Xcode when the debugger is attached to the service extension.
Connect the debugger to the Containing app and run the app. Then attach the debugger to the service extension.
I don't know why you can't run it when the debugger is connected to the service extension. I'm guessing it has something to do with NSExtensionPointIdentifier set to com.apple.usernotifications.service and once the OS sees that things go to hell because only the OS should launch the service extension.
Related
When I try to build and run my keyboard extension, it sometimes just crashes with a Thread 1: signal SIGQUIT.
I am not able to reproduce the error. Sometimes I can build and run my app but most of the time the keyboard just quits. This happens on an actual device. In the simulator it does not open my keyboard and says Waiting to Attach.
The console does not output any errors at first. However, if I change the dropdown to View UI Hierachy in the Debug navigator I get the following description:
Details: No plist data for fetching view hierarchy: error evaluating expression “(id)[(Class)objc_getClass("DBGViewDebuggerSupport_iOS") fetchViewHierarchyWithOptions:(id)[(Class)objc_getClass("NSDictionary") dictionaryWithObjects:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:1]] arrayByAddingObject:(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"_UIVisualEffectBackdropView"] arrayByAddingObject:#"_UIBackdropEffectView"]] arrayByAddingObject:(id)[(Class)objc_getClass("NSNumber") numberWithBool:0]] forKeys:(id)[(id)[(id)[(Class)objc_getClass("NSArray") arrayWithObject:#"DBGViewDebuggerUseLayersAsSnapshots"] arrayByAddingObject:#"DBGViewDebuggerEffectViewsToSnapshotAsImage"] arrayByAddingObject:#"DBGViewDebuggerAlwaysEncodeLayers"]]]”: error: Execution was interrupted, reason: EXC_BREAKPOINT (code=1, subcode=0x18daddc34).
The process has been returned to the state before expression evaluation.
Method: -[DBGAbstractViewDescriber handleFetchedViewInfo:fetchError:resultHandler:]
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
I also took a screenshot of the processes.
Am I doing something wrong and how could I prevent that my keyboard extension quits all the time when running it? Is it actually a bug as it says in the description?
DISCLAIMER
It seems like something in xCode 8.2.1 is broken and the debugger is not correctly attaching to the correct process or the hosting process is not properly loading the new code.
This is a not a permanent solution but a temporary workaround.
WORKAROUND
I have been able to work around this issue by following the steps below.
Kill any process that is using your keyboard (important!)
Launch the application using the debugger so the latest code is deployed to the device
Navigate to Settings > General > Keyboards > etc.
Remove your custom keyboard
Re-add your custom keyboard
Debug the application once again
The reason this works is because removing the keyboard kills the process that is hosting the extension allowing Xcode to attach to the new binary.
As I understand this is a bug in Xcode 8.2.1. because before update my custom keyboard was working very well.
this is a temporary solution.
Run your code like always!
Bring up your keyboard until the error (SIGQUIT) appear!
Goto xcode > debug > detach
Goto again Xcode > debug > Attach to Process: attach the keyboard (it should be first process)
now, your breakpoints will work. but there are no log output unfortunately! I hope it temporary solve your problem
I got this warning when running my application with HockeyApp integration:
[HockeySDK] WARNING: Detecting crashes is NOT enabled due to running the app with a debugger attached.
Crash reports are not sent and no alert is displayed when opening the app again.
Any one have any idea how to resolve this issue?
This has very simple reasons:
If you are running the app with Xcode attached, your app is connected to lldb, Xcode's debugger. When lldb is attached, it will of course do its job as a debugger and catch any exception or crash that occurs. This means that the crash can never reach the HockeyApp SDK or any other crash reporting SDK while lldb is attached at the same time.
The solution is also pretty simple. If you just want to make sure the SDK is integrated properly and will catch crashes, do the following:
Do a quick "Build & Run" to install the current version of the app on the simulator or device.
Click the "Stop" button in Xcode to stop the debugging session.
Manually start the app on the device or simulator by tapping or clicking the app icon.
Cause a crash.
Restart the app. Now the HockeySDK should process the crash report and show a dialog to approve crash log sending.
One thing to keep in mind: Make sure to not make the app crash immediately after app start as this would not give the SDK enough time to process and send the crash report before crashing again.
Hockey app sdk by default does not send report when a debugger is attached. There is nothing wrong with this.
It will send report when a archive build that release to ur tester cause a crash. I personally think this should and remain as this because you are trying to track crashes from your tester not when you are developing.
I'm building a set of Notification Extensions (Service/Content).
I'm unable to connect to Xcode debugger or even log out to the device log or console.
Is there any way to see any kind of output?
Change the target to run the extension
then select run and choose your app from the 'Choose an app to run:' window.
I have tried as per brendan's Answer but is not working for me at all!
I am getting below error in console
Program ended with exit code: 0
Then after searching on google i have checked this answer. however this also not worked for me for while!
Then i have tried same steps again as given in answer, After stopping my current running app. then follow same steps.For clarity i am writing this steps as below:
After running the app that contains the extension,
1) Set your breakpoint in the extension
2) Select Debug / Attach to Process by PID or name
3) Enter the name of the extension target
4) Trigger the push notification
Before step 2 make sure to stop your current running app.
This worked for me to stop at breakpoints in the extension and see the extension log:
Choose the notification extension scheme, not the main app scheme
Run the app and select the main app from the list Choose an app to run
Stop the app in Xcode and terminate it manually on the device; not terminating it manually results in Message from debugger: Terminated due to signal 9 after step 6.
[Update: Terminating the app manually on the device doesn't seem to be necessary, try either way if it doesn't work.]
Select Menu Debug > Attach to Process by PID or Name
Enter the correct extension name, not the main app name
Send the push notification
Notification service extension (NSE) is not actually a part of your app but an extension that said it has a different process id (PID) from your app. You can have XCode listen to every process on your phone by going to the “Debug” tab, scroll down to “Attach to Process” and look to see if your NSE is listed under “Likely Targets”. If it's not there than try to sand another push notification to your device and attach to it when it appears.
Now in debug navigator you can see the NES process and you can successfully debug it.
In my case all methods above had some mistakes. Main point, that you need to send push one time, then connect through debugger, then send push to debug. So, full list:
Launch app (not extension).
Stop app from XCode.
Send one push.
Connect via "Attach to Process by PID or Name..." to your extension process.
Send another push.
If you have tried all the above solutions and still scratching your head and wondering why break point point is not being called. Then try checking the deployment target of your extension it should be less or equal to your device OS.
For me, the deployment target was higher than the device OS.
In my case (Xcode 11.1) debug starts after this steps:
run notification extension target with main app
switch app to background
lock the phone !
send push to device
I followed solutions mentioned here but nothing helped. I found out that problem is when payload of notification does not contain flag to enable content to be mutated. Notification without this flag are not handled by NotificationExtension at all. After I added "mutable-content": 1 to the payload and followed answers here I was able to alter content of push notification and to debug code in NotificationExtension.
{
"aps": {
"mutable-content": 1,
"alert": {
"title": "Push Title",
"body": "Push payload body"
}
},
"data": "what ever you need to be in userInfo"
}
Not sure if this will be helpful, but we have multiple builds of the same app (alpha, beta, etc). Kept getting a "don't have permissions to attach" error when trying to debug. Opening up the processes list, I noticed that there were 2 processes named notification-extension so xcode must have been defaulting to the one of the other build. By manually selecting the right one, or deleting the other builds from my phone things started working again.
The only way that worked for me was to see logs. I use xcode 10.1. The logs were available from Window -> Devices and Simulators -> Choose your device -> click on 'Open Console'.
This way i could see logs from extensions as well.
I'm developing iOS apps with Xcode. So when I build through Xcode I get device logs shown in the console output. But when I disconnect the iPhone from USB, or detach the process, then plug in the phone again and try to attach the process (my app is running on the phone still), the console doesn't output anything anymore.
If I go to Window -> Devices and my iPhone it doesn't show any output in that console either. The console app doesn't show any output either. I've tried to kill Xcode, clean the project, but to no success.
Anyone know how to show output logs from the built app after the iPhone have been detached?
I solved the log output mystery. Since we're using Cocoa Lumberjack it "devoured" the normal NSLog output, I added another log output by writing this row:
DEBUG_LOGS([DDLog addLogger:[DDASLLogger sharedInstance] withLevel:DDLogLevelDebug]);
Where DDASLLogger is the apple console.
I'm just getting started with Apple Watch. I found instructions from "Five Minute Watchkit", on getting the iOS app and the watch kit app both running in the simulator and both processes attached to the LLDB debugger.
What I do is launch and quit the iOS app to install a current version in the sim. Then I switch to the watchKit scheme and launch that, which displays my watch app UI on the watch simulator.
I then launch the corresponding iOS app in the simulator, then user "attach to process" in the Xcode menu to attach the debugger to the running iOS app.
This works. I can set breakpoints in either the watch kit InterfaceController or in my iOS app and the debugger breaks there when it should.
However, I'm not seeing NSLog() statements in the debug console from my iOS app. (I do see log statements from the WatchKit extension code.) If I set a breakpoint in my iOS app, it does stop at that breakpoint when it should. I assume the lack of console output from NSLog has SOMETHING to do with attaching to a running process on the sim rather than launching it from Xcode, but I don't know what that something is.
(BTW, attaching an action to a breakpoint that invokes NSLog from the breakpoint also doesn't display, but the "log message" debugger command DOES display.
Does anybody have any insights?)
EDIT:
The code in the iOS app doesn't seem to matter. In my case, it was a dirt simple IBAction that was attached to a button in the iOS app storyboard:
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(#"Button clicked on iPhone");
}
I can set a breakpoint on that NSLog statement. The debugger stops at that line, but I don't see the log statement in the debug console.
I can reproduce that with a simple test app, sans WatchKit. The app consists of a NSTimer that prints "Timer fired" every second. (This code is 100% correct ;). Nothing shows in the log after I have manually attached to the process.
As far as I know NSLog outputs to stderr, I guess attaching the debugger does not redirect stderr to the Xcode terminal.
If you are okay with using the console app or the terminal to look at your logs you can do that. iOS8 stores simulator logs in ~/Library/Logs/CoreSimulator/<Device-UUID>. In this directory you will find a system.log, which contains all your NSLog output.
You can look at it in terminal (cat, grep, tail), or open it in the Console.app.
Apple confirms that (at least for GDB) in Technical Note TN2239: iOS Debugging Magic.
Console Output
Many programs, and indeed many system frameworks, print debugging
messages to stderr. The destination for this output is ultimately
controlled by the program: it can redirect stderr to whatever
destination it chooses. However, in most cases a program does not
redirect stderr, so the output goes to the default destination
inherited by the program from its launch environment. This is
typically one of the following:
If you launch a GUI application as it would be launched by a normal
user, the system redirects any messages printed on stderr to the
system log. You can view these messages using the techniques described
earlier.
If you run a program from within Xcode, you can see its
stderr output in Xcode's debugger Console window (choose the Console
menu item from the Run menu to see this window).
Attaching to a
running program (using Xcode's Attach to Process menu, or the attach
command in GDB) does not automatically connect the program's stderr to
your GDB window. You can do this from within GDB using the trick
described in the "Seeing stdout and stderr After Attaching" section of
Technical Note TN2030, 'GDB for MacsBug Veterans'.
The mentioned TN2030 is no longer available on their server (mirror). It showed how you can redirect stdout and stderr to the Xcode console. However, since shell tty isn't a valid command for LLDB it won't help much. But maybe there is a different way to access the tty Xcodes console uses, so I attach the important part of that TN.
Seeing stdout and stderr After Attaching
If you attach GDB to a process (as opposed to starting the process
from within GDB), you won't be able to see anything that the process
prints to stdout or stderr. Programs launched by the Finder typically
have stdout and stderr connected to "/dev/console", so the information
they print goes to the console. You can view this by launching the
Console application (in the Utilities folder), however, it's
inconvenient to have to look in a separate window. Another alternative
is to connect the process's stdout or stderr to the terminal device
for GDB's Terminal window. Listing 9 shows how to do this.
Listing 9. Connecting stdout and stderr to GDB's terminal device.
(gdb) attach 795
[... output omitted ...]
(gdb) call (void) DebugPrintMenuList()
No output )-:
Close the stdout and stderr file descriptors.
(gdb) call (void) close(1)
(gdb) call (void) close(2)
Determine the name of the terminal device for GDB itself.
(gdb) shell tty
/dev/ttyp1
Reopen stdout and stderr, but connected to GDB's terminal.
The function results should be 1 and 2; if not, something
is horribly wrong.
(gdb) call (int) open("/dev/ttyp1", 2, 0)
$1 = 1
(gdb) call (int) open("/dev/ttyp1", 2, 0)
$2 = 2
Try the DebugPrintMenuList again.
(gdb) call (void) DebugPrintMenuList()
Yay output!
Index MenuRef ID Title
----- ---------- ---- -----
<regular menus>
00001 0x767725D3 -21629 Ed
00002 0x76772627 1128 <Apple>
00003 0x767726CF 1129 File
00004 0x76772567 1130 Edit
[... remaining output omitted ...]
To add onto Filipp Keks answer, here's a visual representation of a much much simpler way to do it than the accepted answer.
From Filipp Keks's answer:
Plug in the device and open Xcode
Choose Window -> Devices from the menu bar
Under the DEVICES section in the left column, choose the device
To see the device console, click the up-triangle at the bottom left of the right hand panel
Click the down arrow on the bottom right to save the console as a file"
This screenshot was taken in Xcode 7.3.1 of the Devices window.
With Xcode Version 7.2 and iOS 9.2 etc, I found the following works:
Kill both the phone app and watch apps
Select the Watch Extension Target and hit Cmd+R (build and run)
Select the Phone target and hit Ctrl+Cmd+R (Run without building)
In my case, I have both apps up in their simulators and get NSLog output for both. I don't need to attach separately. Hope this helps.
https://developer.apple.com/library/ios/qa/qa1747/_index.html
Plug in the device and open Xcode
Choose Window -> Devices from the menu bar
Under the DEVICES section in the left column, choose the device
To see the device console, click the up-triangle at the bottom left of the right hand panel
Click the down arrow on the bottom right to save the console as a file
When your Provisioning profile is set to AdHoc or Distribution then Xcode doesnot show log, you need set development to view log
This might not solve showing up NSLog messages, but it might be helpful when debugging app started in background.
You can use the breakpoint feature that allows you to log messages.
The idea is to:
Create a breakpoint with "Automatically continue after evaluating actions" checked
add "Log message" action (you can also use expressions and print out values, for example: "Log message #variable#")
Attach debugger using anticipated process name (XCode will wait for the process to start)
Trigger app start.
Credits and details:
https://fluffy.es/how-to-debug-app-which-got-launched-push-notification/
In my case a set Automatically to see NSLog, before don't show at all
I came to this question, via this one (Xcode console empty after attaching to process) which is now closed.
My issue is that the debug console in Xcode is showing nothing (just an empty white box).
The solution for me is a tiny toggle at the bottom which changes between "variable view" and the actual debug console.