Bug 45313 - HttpClient + https crashes after some time
Summary: HttpClient + https crashes after some time
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2016-10-12 12:54 UTC by Radek Matejka
Modified: 2017-06-28 22:22 UTC (History)
2 users (show)

Tags: XATriaged, bb
Is this bug a regression?: ---
Last known good build:

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:
Status:
RESOLVED NORESPONSE

Description Radek Matejka 2016-10-12 12:54:57 UTC
[0:] 00:48:42/1 - Executing action 'SaunaStatusUpdate'...
Xamarin.Android returned no custom HttpClientHandler. Defaulting to System.Net.Http.HttpClientHandler
[0:] Executing 'GET' request for: https://home.uhajicku.cz/SaunaService/getStatus?clientId=eaa00137-2835-4e1c-911f-303a6bcb84c2
10-11 00:48:42.038 I/mono-stdout( 1270): Xamarin.Android returned no custom HttpClientHandler. Defaulting to System.Net.Http.HttpClientHandler
10-11 00:48:42.046 D/Mono ( 1270): Unloading image System.dll [0xba3821e0].
10-11 00:48:42.046 D/Mono ( 1270): Image addref System[0xba37d050] -> System.dll[0xb909f0c0]: 888
10-11 00:48:42.046 D/Mono ( 1270): Config attempting to parse: 'System.dll.config'.
10-11 00:48:42.046 D/Mono ( 1270): Config attempting to parse: '/Users/builder/data/lanes/3415/7db2aac3/source/monodroid/builds/install/mono-x86/etc/mono/assemblies/System/System.config'.
10-11 00:48:42.046 D/Mono ( 1270): Unloading image System.dll [0xba3821e0].
10-11 00:48:42.046 D/Mono ( 1270): Image addref System[0xba37d050] -> System.dll[0xb909f0c0]: 889
10-11 00:48:42.046 D/Mono ( 1270): Config attempting to parse: 'System.dll.config'.
10-11 00:48:42.046 D/Mono ( 1270): Config attempting to parse: '/Users/builder/data/lanes/3415/7db2aac3/source/monodroid/builds/install/mono-x86/etc/mono/assemblies/System/System.config'.
10-11 00:48:42.046 E/dalvikvm( 1270): JNI ERROR (app bug): local reference table overflow (max=512)
10-11 00:48:42.046 W/dalvikvm( 1270): JNI local reference table (0xba3828b0) dump:
10-11 00:48:42.046 W/dalvikvm( 1270): Last 10 entries (of 512):
10-11 00:48:42.046 W/dalvikvm( 1270): 511: 0xa8d1eb08 java.lang.String ""
10-11 00:48:42.046 W/dalvikvm( 1270): 510: 0xa9f58808 java.lang.String "Android.Runtime.... (115 chars)
10-11 00:48:42.046 W/dalvikvm( 1270): 509: 0xa902b518 java.lang.Class<mono.android.TypeManager>
10-11 00:48:42.046 W/dalvikvm( 1270): 508: 0xa9f585c0 java.lang.Class<mono.android.runtime.InputStreamAdapter>
10-11 00:48:42.046 W/dalvikvm( 1270): 507: 0xaa335e40 java.lang.String "PKIX"
10-11 00:48:42.046 W/dalvikvm( 1270): 506: 0xaa335e28 java.security.cert.X509Certificate[] (1 elements)
10-11 00:48:42.046 W/dalvikvm( 1270): 505: 0xaa324d60 java.lang.String "PKIX"
10-11 00:48:42.046 W/dalvikvm( 1270): 504: 0xaa324d48 java.security.cert.X509Certificate[] (1 elements)
10-11 00:48:42.046 W/dalvikvm( 1270): 503: 0xaa2b87c8 java.lang.String "PKIX"
10-11 00:48:42.046 W/dalvikvm( 1270): 502: 0xaa2b87b0 java.security.cert.X509Certificate[] (1 elements)
10-11 00:48:42.046 W/dalvikvm( 1270): Summary:
10-11 00:48:42.046 W/dalvikvm( 1270): 2 of java.lang.Class (2 unique instances)
10-11 00:48:42.046 W/dalvikvm( 1270): 256 of java.lang.String (256 unique instances)
10-11 00:48:42.046 W/dalvikvm( 1270): 254 of java.security.cert.X509Certificate[] (1 elements) (254 unique instances)
10-11 00:48:42.046 E/dalvikvm( 1270): Failed adding to JNI local ref table (has 512 entries)
10-11 00:48:42.046 I/dalvikvm( 1270): "Thread-107" prio=5 tid=21 RUNNABLE
10-11 00:48:42.046 I/dalvikvm( 1270): | group="main" sCount=0 dsCount=0 obj=0xa9f3dcf0 self=0xb95a4840
10-11 00:48:42.046 I/dalvikvm( 1270): | sysTid=1316 nice=0 sched=0/0 cgrp=apps handle=-1174862944
10-11 00:48:42.046 I/dalvikvm( 1270): | state=R schedstat=( 3390574095 2227152558 149235 ) utm=198 stm=140 core=0
In mgmain JNI_OnLoad
10-11 00:48:42.046 I/dalvikvm( 1270): at mono.android.TypeManager.n_activate(Native Method)
10-11 00:48:42.046 I/dalvikvm( 1270): at mono.android.TypeManager.Activate(TypeManager.java:7)
10-11 00:48:42.046 I/dalvikvm( 1270): at mono.android.runtime.InputStreamAdapter.(InputStreamAdapter.java:26)
10-11 00:48:42.046 I/dalvikvm( 1270): at dalvik.system.NativeStart.run(Native Method)
10-11 00:48:42.046 I/dalvikvm( 1270): 
10-11 00:48:42.046 E/dalvikvm( 1270): VM aborting
10-11 00:48:42.046 F/libc ( 1270): Fatal signal 6 (SIGABRT) at 0x000004f6 (code=-6), thread 1316 (Threadpool work)


actually i see two bugs from this log:
1. reference table overflow after some time, nothing special, just GET operation, executed every second, "some time" = 1-2 hours, the server is available, you can test it against it
2. unloading/loading image System.dll


- it also happens with ModernHttpClient
- if i switch to http protocol everything is OK (even no unloading/loading of System.dll) and i cannot reproduce the bug, application is super stable, running for several days without problems, btw, application has 18 MB allocated memory and i see no increasing, so i think i free/dispose everything i can
- with https protocol, application is dead within 1-2 hours, because of "reference table overflow"


Radek
Comment 1 Radek Matejka 2016-10-12 13:07:27 UTC
the unloading/loading image System.dll is done every https GET request ! in my application every 1 second...
Comment 2 Marek Habersack 2016-10-13 12:31:20 UTC
Please provide a small app which demonstrates the problem so that we can reproduce it locally. It appears there is a local reference leak, that's obvious, but we do need to reproduce it in order to fix this issue.

As for the loading/unloading messages, they are debugging messages and can be ignored.

A GET request every second is definitely not something that can be done lightly, especially with SSL. For each request you are forcing the talking parties to perform an SSL handshake, set up the secure communications, transfer data etc. All of this is non-trivial amount of work which can take well over 1s and you might (and probably will) get overlapping requests thus creating a quite complex environment. Have you considered keeping the HTTP connection alive and instead of polling (which is what I suspect is going one) wait for the server to push information to your application?
Comment 3 Radek Matejka 2016-10-16 03:35:29 UTC
Hi Marek,

thank you for your responce, you are right, keep-alive is good point and also push notifications but thats not so easily implementable in my situation...

the usage is simple:

using (var client = await factory.Create())
using (var request = await CreateRequest(client, url, urlParams, headers, HttpMethod.Get))
{
    using (var response = await client.Execute(request))
        return await response.GetJsonContent<T>();
}

where client is HttpClient, request is HttpRequestMessage, response is HttpResponseMessage + some extension methods...

if i replace "using (var client..." with singleton HttpClient (i suppose keep-alive is in use) it is much more faster and application can run for about 10 hours without crash, but it crashes anyway with same exception and same objects in local reference table:

10-15 23:45:55.753 W/dalvikvm( 1265): JNI local reference table (0xba353280) dump:
10-15 23:45:55.753 W/dalvikvm( 1265):   Last 10 entries (of 512):
In mgmain JNI_OnLoad
10-15 23:45:55.753 W/dalvikvm( 1265):       511: 0xa8cf8b08 java.lang.String ""
10-15 23:45:55.753 W/dalvikvm( 1265):       510: 0xa9f48300 java.lang.String "Java.Lang.Thread... (117 chars)
10-15 23:45:55.753 W/dalvikvm( 1265):       509: 0xa9005508 java.lang.Class<mono.android.TypeManager>
10-15 23:45:55.753 W/dalvikvm( 1265):       508: 0xa9f480c8 java.lang.Class<mono.java.lang.RunnableImplementor>
10-15 23:45:55.753 W/dalvikvm( 1265):       507: 0xa9f3fff8 java.lang.String "PKIX"
10-15 23:45:55.753 W/dalvikvm( 1265):       506: 0xa9fc1150 java.security.cert.X509Certificate[] (1 elements)
10-15 23:45:55.753 W/dalvikvm( 1265):       505: 0xa9f2b648 java.lang.String "PKIX"
10-15 23:45:55.753 W/dalvikvm( 1265):       504: 0xa9f2b630 java.security.cert.X509Certificate[] (1 elements)
10-15 23:45:55.753 W/dalvikvm( 1265):       503: 0xaa2c3628 java.lang.String "PKIX"
10-15 23:45:55.753 W/dalvikvm( 1265):       502: 0xaa2c3610 java.security.cert.X509Certificate[] (1 elements)
10-15 23:45:55.753 W/dalvikvm( 1265):   Summary:
10-15 23:45:55.753 W/dalvikvm( 1265):         2 of java.lang.Class (2 unique instances)
10-15 23:45:55.753 W/dalvikvm( 1265):       256 of java.lang.String (256 unique instances)
10-15 23:45:55.753 W/dalvikvm( 1265):       254 of java.security.cert.X509Certificate[] (1 elements) (254 unique instances)

I can create some testing project for this if its really needed. I'm surprised nobody noticed this behavior or experienced the crashes from this "first-line" class/scenario... :)
Comment 4 Marek Habersack 2016-10-17 21:15:42 UTC
If you could please create the test project that would be really useful :) The reason we ask is that often there's something hidden that is unique to the way the app works/developer writes code that we might not reproduce (it can be the code or some project setting etc) and if the project you provide works correctly for us, then we have a clue that it's something in your environment (development machine, emulator, device etc) and we can ask for more information. Thanks!
Comment 5 Al Clark [MSFT] 2017-06-28 22:22:21 UTC
Because we have not received a reply to our request for more information we are closing this issue. If you are still encountering this issue, please reopen the ticket with the requested information. Thanks!