Run under debug using a real device - flutter

I don't understand how to view the debugged app on a real device. To begin with, I see such a picture, it lasts about 3-5 minutes.
And then I get an error -
Waiting for a connection from Flutter on M2003J15SC... Error
connecting to the service protocol: Exception: connection to device
ended too early
I put dots in the code, and it is important for me to know what is happening there at the time of execution, so I need a debug mode. Help please, what am I doing wrong?

Related

How to debug if app closes without error message?

Im facing an issue that i am unable to debug.
If i open the app, it opens normally and works. But if i launch the app and close the app within 1 second and then launch the app again, it crashes without error message.
How do i debug this as Xcode loses debug connection if i close the app?
I tried putting exception break point but since xcode loses debug connection, it wont trigger.
This ONLY happens when a user does the above mentioned steps (open, close within 2 seconds and open again).
Is there anyway to find out why the app is closing and why there is no error / crash message?
Clarification : The crash happens when user opens the app, within 1 sec terminates the app by manually by swiping up from recents menu and tries to open the app again within 1 or 2 seconds. (Open -> terminate -> open)
Let us imagine that you run the app and quickly force-quit. Then, if you start your second run of the app from the Xcode debugger, hopefully, you should see your crash in Xcode at that point.
If that does not work, you might consider a crash reporting tool (e.g., Crashlytics, etc.). That will help you monitor and track crash reports that happen (for both you and your users) in the wild. If you do this, make sure you test the crash reporting system with some forced crash/report because an absence of a report could just be a result of a misconfiguration, which is easy to do because the setup of these tools takes a little work the first time you do it. Just make sure you have the crash report system working with a positive crash report before you draw any conclusions from an absence of a crash report generated by this particular bug.
That having been said, the way these crash reporting systems often work is they capture the crash and send it the next time you start up the app. It seems like there might be a chance that your particular crash (firing it up after having quickly force-quit it the first time) is happening so fast that the crash reporting system may not have a chance to send off its report of the past crash. (That having been said, these are still invaluable for capturing information about user crashes that happen during the normal use of the app, so I would consider them even if it does not help in this particular scenario.)
So, let’s imagine that you are still unsuccessful in catching your crash for some reason. The last resort is to consider sprinkling your code with Logger/OSLog statements. The nice thing about these logging statements is that you can watch these logging statements on your macOS Console app. See WWDC 2020 Explore logging in Swift.

Swift SearchBar- [general] Connection to daemon was invalidated

I just added a ui searchbar to my program, and every time i rerun the program I get the error-
[general] Connection to daemon was invalidated
Despite this, my app is able to run perfectly and I can't seem to tell what is wrong.
Does anyone know what this means and how I could fix this?
If you'd like to to take a look at my code, please let me know and I'll clean it up.
I am running my app on a physical device and I have the same issue. Looking at other threads on Stack Overflow, it appears that this is just a glitch in Xcode and probably not an issue on your part.
If you are using a physical device, try running it on a simulator - the error shouldn't appear (at least it didn't for me)

NSXMLParser - the request timed out

I have been intermittently receiving a "The request timed out" message via the NSXMLParser parseError method. (NSError)
It doesn't happen in the simulator only on the actual device. (i4)
On the device it usualy happens when the app being launched the first time.
Once I have the first parse done (after one or two app restart) every other web service call will work just fine.
I can then restart the app as many times as I want it won't show the error anymore.
I don't see how this is a timeout error as the app won't hang up. The error pops up instantly.
Any idea?
Thank you
I could never figure out this error. It looks like this message appears only when the connection is very slow.

App crashes with "Watchdog has expired." message. No stack trace or crash dump

My app is crashing with the following message in the Xcode debugger:
Watchdog has expired. Remote device was disconnected? Debugging session terminated.
The Debugger has exited due to signal 15 (SIGTERM).The Debugger has exited due to signal 15 (SIGTERM).
The crash is quite severe and reboots the device most of the time. The debugger just exits and I get no crash log afterwards.
Is the "Watchdog has expired." message relevant at all? Or is this just an artifact of the debugger loosing touch with the app when it crashes?
If it is relevant, what does it mean?
"Watchdog has expired." could mean anything. The way the message is worded suggests that the "local" GDB (running on your Mac) GDB timed out waiting for data from the "remote" GDB (running on the phone). Alternatively, "Watchdog has expired" might be from the phone's console output shortly before it reboots.
What does it display if you disconnect the device while your app is running? What if you power it off? What if you issue a hard reset (Sleep+Home for 10 seconds)?
If it's causing the device to reboot, there's something seriously wrong happening. Your app shouldn't be able to take the phone down, but sometimes something slips through (IIRC, UIImagePickerController on some version of 2.x had a problem where either your app would get killed or the phone would reboot, depending on which kicked in first). "Large set of bitmaps" sounds like it might be causing CoreAnimation (or IOSurface or whatever) to run out of video memory.
I would hesitate to do drawing in a background thread unless you're very careful about thread-safety (to a first approximation, CoreAnimation is and UIKit isn't except a few functions that were made "thread-safe" in 4.0).

Unable to run instruments on my iphone app on the device

I'm trying everything i can to get instruments to profile my app on the actual iphone device, but it won't work no matter what i do. I tried the solution from Does Instruments (ObjectAlloc/Leaks) require the simulator? but that didn't work. Most of the time i get nothing of use from the console, but one time i did receive this error:
Mon Aug 31 11:27:48 unknown
lockdownd[14] : (0x83d400)
handle_connection: Could not receive
USB message #13 from Instruments.
Killing connection
I'm not sure what could be causing this; has anyone else seen this and know a solution?
Same problem - it worked the first two times, then after that never again (even after restarting Xcode, deleiting the device, etc).
Eventually I resorted to:
Set XCode to display the Console
Run with Performance Tool
(instruments starts, and goes "BEEP"
with no error - Apple "forgot" to
include the error message, I think.
ARGH!)
Build&Run on device
Once the (gdb) appears in console,
go to Instruments and select "Attach
to Process" from the drop-down at
top
If you cannot see the name of your
debugging app, wait a second, and
try again
Eventually your app appears in the
list of alread-running stuff, so
select it
Hit the Record button
On subsequent runs, Instruments will remember the name of your app, but will show an error if you hit "record" too soon. So you just keep hitting record and doing "OK" on the process it tries to connect to until it stops messing around and does what it's supposed to.
So far (20 odd runs) this works everytime. Obviously, it would be nicer if it just worked properly, without this manual hackery, but Apple is reporting zero error messages even to system console, so there's nothing we can do!