Bug 246 - ASMX web service call crashes app in 1.0.2
Summary: ASMX web service call crashes app in 1.0.2
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 1.0
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2011-08-09 13:25 UTC by Neal
Modified: 2011-08-24 16:50 UTC (History)
4 users (show)

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

DateTime showing in chinese (181.59 KB, image/jpeg)
2011-08-09 14:26 UTC, Neal
another DateTime in chinese (84.54 KB, image/jpeg)
2011-08-09 14:26 UTC, Neal

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Neal 2011-08-09 13:25:11 UTC

I have a production app "Logbook Pro" that's in the Android Market.  It has stability issues due to what seems to be GC issues with ListView and a Base Adapter implementation which I have reported on the Novell bugzilla.  I am happy to see the 1.0.2 update and hope it resolves the stability issues.  I just installed it and did a clean install of the app and deployed it to my Droid X running Gingerbread (2.3) to test.  When my app is first installed and run you have to initialize it by entering two credentials which then makes an ASMX web service call.  The app crashes when making the ASMX service call.  I ran logcat but it doesn't show anything other than the windowmanager died, etc. Nothing to provide to you.  Here is the method that is called and it's the App.Sync.Sync call:

protected void DoSync()
                if (!App.CanSync)
                    if (IsAirplaneMode)
                    if (SyncButton != null) SyncButton.Visibility = ViewStates.Invisible;
                        DataSet result = null;
                            result = App.Sync.Sync(Convert.ToInt32(App.Settings.AccountID), App.Settings.AccountUsername, GetChanges(), App.PCDataSyncDate, App.AppVersionCode, App.UDID, App.DeviceModel); //<--- this is the line where the app dies
                            if (App.NeedsSiteMapDownload)
                                if (App.Sync.GetSitemap())
                                    App.Settings.LastSiteMapDownload = DateTime.Now;
                        catch (Exception ex)
                            Logger.LogException(ex.Message, ex, "App.Sync.Sync");
                                if (SyncButton != null) SyncButton.Visibility = ViewStates.Visible;
                                bool completed = (result != null);
                                Toast.MakeText(this, completed ? "Sync Succeeded" : "Sync Failed", ToastLength.Short).Show();
                                if (SyncCompleted != null)
                            catch (Exception ex)
                                Logger.LogException(ex.Message, ex, "DoSync_RunOnUiThread");
            catch (Exception ex)
                Logger.LogException(ex.Message, ex, "DoSync()");

I can be reached by e-mail and I'd be happy to take a phone call if you want to dive into this ASAP and/or remote into my system to do any debugging that would assist you with this critical issue.

Thank you.
Comment 1 Jonathan Pryor 2011-08-09 13:47:47 UTC
Can you narrow down where the app dies further? Does it die before the App.Sync.Sync() call? Does it enter the call and die within it? What is App.Sync.Sync() doing?

My _guess_ -- based largely on the fact that I've angered the networking gods -- is that you're possibly hitting network connection issues, rather like:


IF App.Sync.Sync() is actually executing, then you might look to see if there are any IDisposable instances created within that method, and ensure that they're disposed of appropriately. You may also want to set HttpWebRequest.KeepAlive=false, if you're using HttpWebRequest at all. It was reported on the mailing list that setting KeepAlive=false improved stability:


If the app is dying before App.Sync.Sync() is invoked... I'll need to think about that.
Comment 2 Neal 2011-08-09 14:26:07 UTC
App.Sync is just an object in the Application class to keep the sync web service in memory to keep things running a little faster.

        private Synchronizer _sync;
        public Synchronizer Sync
                if (_sync == null)
                    _sync = new Synchronizer();
                return _sync;
            set { _sync = value; }

App.Sync calls the .Sync method which first does an IsConnected() check which just pings a web method for a result of 999, which does work.

        public bool IsConnected()
                int result = SyncService.Ping();
                return (result == 999);
            catch (Exception ex)
                Console.WriteLine("Ping failed: " + ex.Message); //catch web service exception without logging it
            return false;

I then call the Sync method and I stepped through every item and here is the exception on the Sync call:

+		ex	{System.Net.WebException: Error getting response stream (ReadDone2): ReceiveFailure ---> System.Exception:    at System.Net.WebConnection.ReadDone(IAsyncResult result)
  at System.Net.WebConnection.HandleError (WebExceptionStatus st, System.Exception e, System.String where) [0x0003a] in /home/jon/Development/xamarin/mono/mcs/class/System/System.Net/WebConnection.cs:399 
  --- End of inner exception stack trace ---
  at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x0005e] in /home/jon/Development/xamarin/mono/mcs/class/System/System.Net/HttpWebRequest.cs:828 
  at System.Net.HttpWebRequest.GetResponse () [0x0000e] in /home/jon/Development/xamarin/mono/mcs/class/System/System.Net/HttpWebRequest.cs:836 
  at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse (System.Net.WebRequest request) [0x0000e] in /home/jon/Development/xamarin/mono/mcs/class/System.Web.Services/System.Web.Services.Protocols/WebClientProtocol.cs:188 }	System.Net.WebException

After the sync call, in the original code I provided is a App.Sync.GetSitemap()method which DOES work.  I think the exception is being caught in DEBUG mode while stepping through but when not in debug mode it just crashes the app as for some reason the try/catch doesn't seemed to be honored???

Anyways, another problem seems to have presented itself.  I don't know if this is something on my machine or something in the MonoDroid code but my DateTime objects are appearing in chinese!!!!  I'll attach the images for you!  This is really strange!  I checked my Windows 7 regions/settings and I'm only set to US but I have done some graphics work with a Chinese artist so I'm not sure if Adobe CS5 has done anything to my system in setting up chinese somewhere I'm not aware of.  I don't see any other properties showing as Chinese, it's just the DateTime objects.

I re-ran the app and this time without being in debug mode and it still crashes.  During the sync code logic there are no uses of "using" blocks or any calls to dispose, GC, etc.  I let the GC do its thing automatically.  I am not using any HttpWebRequest calls, all I'm using is ASMX web service web methods.

Hope this helps.  If you want to give me a call or remote into my system you're welcome to.
Comment 3 Neal 2011-08-09 14:26:34 UTC
Created attachment 100 [details]
DateTime showing in chinese
Comment 4 Neal 2011-08-09 14:26:50 UTC
Created attachment 101 [details]
another DateTime in chinese
Comment 5 Neal 2011-08-21 12:05:57 UTC
Anything additional needed on this?  I see it's still marked "need info" - am I supposed to change the status when responding?
Comment 6 Jeffrey Stedfast 2011-08-21 18:16:35 UTC
You can reopen when you add info - or a dev will (hopefully) :-)
Comment 7 Neal 2011-08-21 18:33:53 UTC
I added the info, didn't know I needed to reopen it.
Comment 8 Admin 2011-08-23 12:00:23 UTC
I can't reproduce your webservice connection issue. Are you using a webservice instance created by visual studio generated code, or do you have custom code to connect to it? Does it always crash at the same spot in the same way?
Comment 9 Neal 2011-08-23 13:07:18 UTC
The asp.net 2.0 web service was created by adding a reference from VS 2010.  I'll delete and recreate the reference and see if I can find a common pattern to provide you.
Comment 10 Admin 2011-08-23 13:09:53 UTC
I'm testing with several consecutive calls to a simple webservice and it doesn't crash in that way. The DataSet that the Sync call returns, how big is it?
Comment 11 Neal 2011-08-23 13:15:32 UTC
It's not that big.  It may be best if I give you the private info and let you consume the same service and I'll give you the parameters to pass in and you can try it exactly as I have it.  I'll get that to you as soon as I can.
Comment 12 Admin 2011-08-23 13:18:58 UTC
That would be great, thanks. The bugzilla private commenting feature is not working correctly at the moment, so send the info to andreia@xamarin.com instead.
Comment 13 Neal 2011-08-23 13:20:39 UTC
That is a good to know as this is sensitive info, I'll e-mail it to you from neal AT nc-software.com.  I'll try to get it to you in a few hours or less.
Comment 14 Neal 2011-08-23 13:34:50 UTC
E-mail sent, please keep confidential.  Let me know when you're done testing as well as I have the wsdl exposed for you, typically it's private.  My e-mail has my office number if you need it.

Thank you.
Comment 15 Neal 2011-08-24 16:50:42 UTC
So far tests are positive using MonoDroid 1.0.3.  I'll reopen this case if I need further assistance regarding this matter.

Thank you.