Bug 53190 - Lots of problems debugging doc provider extensions
Summary: Lots of problems debugging doc provider extensions
Status: ASSIGNED
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 10.4 (C9)
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2017-03-09 13:15 UTC by tmrog
Modified: 2017-05-05 08:06 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test app to reproduce the issue. (1.11 MB, application/zip)
2017-03-09 13:15 UTC, tmrog
Details
Stack Dump from Xamarin Studio Hang (1.64 MB, text/rtf)
2017-03-09 15:33 UTC, tmrog
Details
Adobe Reader Hang Crash Dump (2.93 MB, text/plain)
2017-03-09 18:02 UTC, tmrog
Details
Adobe Reader Hang Crash Dump Take 2 (58.72 KB, text/rtf)
2017-03-09 18:19 UTC, tmrog
Details
Shows contents of my home directory (166.83 KB, image/png)
2017-03-14 13:29 UTC, tmrog
Details

Description tmrog 2017-03-09 13:15:23 UTC
Created attachment 20246 [details]
Test app to reproduce the issue.

I have had to mostly revert to printf style debugging for both the doc picker and file provider extensions I am writing.

I wish I could say I have reproducible steps but can't figure out why it works sometimes but mostly doesn't work.  When I say work I mean the debugger attaching to the process and hitting breakpoints.

What I see:

1. The doc picker extension seems to be the most finicky as the debugger rarely connects once I launch it from the hosting app.  I am testing using Pages, Adobe Acrobat Reader, and Word as the hosting apps.

2. The file provider extension seems to work more frequently than the doc picker extension but sometimes it just doesn't connect.

3. If Xamarin Studio is waiting to connect and fails, sometimes if hit the cancel button in the connect alert, XS will hang and needs to be force quit.

4. I have had cases where the hosting app hangs until a remove all the breakpoints.  Keep in mind, I am not sitting on a breakpoint when this happens.

5. I have had cases where it seems as though XS gets confused about what it should be debugging.  For example, I set the startup app to the the doc picker but it attaches to the file provider.  I have had cases where I can't run my main app until I do some undefined magic of killing XS, Clean All, and attaching chicken bones to the side of my monitor.

I have attached a sample app that can be used to see these problems.  Like I said before, I wish I could provide steps to reproduce these issues but I have not been able to sort that out.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-03-09 14:49:29 UTC
First of all I'd like to say that we're improving debugging extensions a lot in the next major release, so some of these issues are probably already fixed.

However,

> 
> What I see:
> 
> 1. The doc picker extension seems to be the most finicky as the debugger
> rarely connects once I launch it from the hosting app.  I am testing using
> Pages, Adobe Acrobat Reader, and Word as the hosting apps.
> 
> 2. The file provider extension seems to work more frequently than the doc
> picker extension but sometimes it just doesn't connect.

Please enable verbose logging, by doing this:

    echo 123456789 > ~/.mlaunch-verbosity

and then the verbose logging will show up in the Application Output.

Once something goes wrong, attach the Application Output here and I'll have a look at it.

> 
> 3. If Xamarin Studio is waiting to connect and fails, sometimes if hit the
> cancel button in the connect alert, XS will hang and needs to be force quit.

This is a known issue (bug #53150). In my experience XS eventually recover, but it takes about a minute.

> 4. I have had cases where the hosting app hangs until a remove all the
> breakpoints.  Keep in mind, I am not sitting on a breakpoint when this
> happens.

If this happens, please force crash the host app:

* Hold down the On/Off button until "slide to power off" appears.
* Release the On/Off button.
* Hold down the Home button.
* After a few seconds the app will be terminated, and a crash report will be generated (the app's exception code will be 0xdeadfa11). You can find these crash reports in Xcode's Organizer; please attach any of these crash report in this bug.

> 
> 5. I have had cases where it seems as though XS gets confused about what it
> should be debugging.  For example, I set the startup app to the the doc
> picker but it attaches to the file provider.  I have had cases where I can't
> run my main app until I do some undefined magic of killing XS, Clean All,
> and attaching chicken bones to the side of my monitor.

Make sure that the debugger port is different in all projects.

You can configure this in the project's iOS Debug options.

> 
> I have attached a sample app that can be used to see these problems.  Like I
> said before, I wish I could provide steps to reproduce these issues but I
> have not been able to sort that out.

Thanks for the test app, I'll have a look.
Comment 2 tmrog 2017-03-09 15:07:16 UTC
I tried the steps below with one of the host apps running but nothing appears in XCode Organizer. 

I get "No crashes" "No app records are associated with your accounts".

Is there some other setup I need to do?

I'll work on gather the other info.


If this happens, please force crash the host app:

* Hold down the On/Off button until "slide to power off" appears.
* Release the On/Off button.
* Hold down the Home button.
* After a few seconds the app will be terminated, and a crash report will be generated (the app's exception code will be 0xdeadfa11). You can find these crash reports in Xcode's Organizer; please attach any of these crash report in this bug.
Comment 3 tmrog 2017-03-09 15:20:00 UTC
I feel like making sure the ports are all different helped.  All extensions were using 10001.  

I can say this.  If you don't go through the deploy to device process, if app doesn't need building, the debugger never connects.

I'll keep plugging away on the investigation.

Ted
Comment 4 tmrog 2017-03-09 15:21:22 UTC
I did this "echo 123456789 > ~/.mlaunch-verbosity" but get absolutely nothing in Application Output when it doesn't connect.  At least so far.
Comment 5 tmrog 2017-03-09 15:33:30 UTC
Created attachment 20249 [details]
Stack Dump from Xamarin Studio Hang
Comment 6 tmrog 2017-03-09 15:34:00 UTC
Above hang occurred during a successful debug session when I went to remove a breakpoint.
Comment 7 tmrog 2017-03-09 18:02:31 UTC
Created attachment 20253 [details]
Adobe Reader Hang Crash Dump

Hope this helps.  This happened when I was trying to debug the file provider.  Adobe Reading hung on launch.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2017-03-09 18:11:12 UTC
Can you get the crash reports as well (not just the device log)?

* Launch Xcode on your desktop machine.
* Open Xcode's Devices window.  (Window menu -> Devices)
* Find your device in the left sidebar, then select “View Device Logs”.
* Select the crash report(s) and wait a few seconds for Xcode to automatically symbolicate them.
* Attach the crash report(s) here.
Comment 9 tmrog 2017-03-09 18:19:19 UTC
Created attachment 20255 [details]
Adobe Reader Hang Crash Dump Take 2

Sorry about that. I selected the wrong file.

Ted
Comment 10 Rolf Bjarne Kvinge [MSFT] 2017-03-09 18:29:08 UTC
Is that the only crash report, or did you get any crash reports for the extensions as well?

It looks like Adobe is stuck waiting for another process, so the question is what that other process (presumably one of the extensions) are doing.
Comment 11 tmrog 2017-03-09 18:51:21 UTC
I don't have a crash dump for my extension at that time.
Comment 12 tmrog 2017-03-09 19:50:29 UTC
One thing I have found that helps is to remove all breakpoints until XS attaches to my file provider process.  Usually, it does not connect if I have breakpoints or my debug session just seems to end.

Would like to get you some more verbose output but didn't seem like "echo 123456789 > ~/.mlaunch-verbosity" added any additional verbosity.

Also, I cannot seem to use JSON.net in my file provider.  When I call DeserializeObject the process just seems to disappear.  I added that to my FileProviderBug project to illustrate.  Do you have any ideas about this and/or should I open up a new bug?

I have used this same code in a Share Extension with no problems.

I removed all the extra stuff and if I add these two lines my file provider seems to go off the rails.

var serializedAccount = "{\"UserID\":2,\"Password\":\"\",\"AuthToken\":\"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJVc2VybmFtZSI6ImFkbWluIiwiVXNlcklEIjoiMiIsIlZhdWx0TmFtZSI6IlBETVRlc3QiLCJWYXVsdFZlcnNpb24iOiIxODAwIiwiUm9sZSI6IiIsImlzcyI6IlNvbGlkV29ya3NQRE0iLCJhdWQiOiJQRE1BcGlVUkwiLCJleHAiOjE0ODkxMjQ2NzMsIm5iZiI6MTQ4OTA4MTQ3M30.PTUBAnIekc00zNBspMJ9y37UtodkOb09 - 3_lQsigGpk\"}";

var account = JsonConvert.DeserializeObject<Account>(serializedAccount);

Ted
Comment 13 Rolf Bjarne Kvinge [MSFT] 2017-03-14 10:35:13 UTC
(In reply to tmrog from comment #4)
> I did this "echo 123456789 > ~/.mlaunch-verbosity" but get absolutely
> nothing in Application Output when it doesn't connect.  At least so far.

Do you get anything when it connects?

It should produce something like this: https://gist.github.com/rolfbjarne/3e4e775cfe77ab8ad13c1d16ab48e016.

(In reply to tmrog from comment #12)
> One thing I have found that helps is to remove all breakpoints until XS
> attaches to my file provider process.  Usually, it does not connect if I
> have breakpoints or my debug session just seems to end.
> 
> Would like to get you some more verbose output but didn't seem like "echo
> 123456789 > ~/.mlaunch-verbosity" added any additional verbosity.

For the FileProvider extension, it looks like you have to launch twice after a rebuild: the first time the extension will launch just after installing it, the debugger connects and then iOS immediately kills the extension. Then you have to launch again, and then iOS won't re-launch the extension until you actually trigger it in a host app.

I'll look into fixing this somehow.
Comment 14 tmrog 2017-03-14 13:29:04 UTC
Created attachment 20303 [details]
Shows contents of my home directory
Comment 15 tmrog 2017-03-14 13:30:10 UTC
My application output with FileProvider as my startup project:

2017-03-14 09:16:09.222 FileProvider[253:6562] Xamarin.iOS: Debugger loaded with custom transport (fd: 4)
2017-03-14 09:16:09.324 FileProvider[253:6570] Xamarin.iOS: Successfully received USB connection from the IDE on port 10002, fd: 6
2017-03-14 09:16:09.325 FileProvider[253:6570] Xamarin.iOS: Processing: 'start profiler: no'
2017-03-14 09:16:09.325 FileProvider[253:6562] Xamarin.iOS: Profiler not loaded (disabled)
Loaded assembly: /private/var/containers/Bundle/Application/5D12668B-453E-45FE-BC26-F2569F7D29E5/FileProviderBug.app/PlugIns/FileProvider.appex/.monotouch-64/System.dll [External]
Loaded assembly: /private/var/containers/Bundle/Application/5D12668B-453E-45FE-BC26-F2569F7D29E5/FileProviderBug.app/PlugIns/FileProvider.appex/.monotouch-64/Xamarin.iOS.dll [External]
Loaded assembly: /private/var/containers/Bundle/Application/5D12668B-453E-45FE-BC26-F2569F7D29E5/FileProviderBug.app/PlugIns/FileProvider.appex/.monotouch-64/FileProvider.dll
Thread started:  #2
Thread started:  #3
2017-03-14 09:16:09.807 FileProvider[253:6569] FileProvider starting up
Thread started:  #4
2017-03-14 09:16:53.671 FileProvider[253:6566] FileProvider starting up
Thread started:  #5
2017-03-14 09:16:53.731 FileProvider[253:6944] FileProvider starting up
Thread started:  #6
2017-03-14 09:16:54.390 FileProvider[253:6568] FileProvider starting up
Thread started:  #7
2017-03-14 09:16:54.405 FileProvider[253:6943] FileProvider starting up
2017-03-14 09:16:54.439 FileProvider[253:6566] StartProvidingItemAtUrl: url =  /private/var/mobile/Containers/Shared/AppGroup/25B206E5-9B2B-4E3C-8D9A-F96C5E94B5E0/File Provider Storage/FPBOpen-18.docx
2017-03-14 09:16:55.494 FileProvider[253:6569] FileProvider starting up
2017-03-14 09:16:55.507 FileProvider[253:6569] FileProvider starting up
2017-03-14 09:16:55.516 FileProvider[253:6566] StartProvidingItemAtUrl: url =  /private/var/mobile/Containers/Shared/AppGroup/25B206E5-9B2B-4E3C-8D9A-F96C5E94B5E0/File Provider Storage/FPBOpen-18.docx

Note You need to log in before you can comment on or make changes to this bug.