Bug 27339 - Error when call DateTime.Now()
Summary: Error when call DateTime.Now()
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 5.1
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2015-02-24 01:21 UTC by arition
Modified: 2017-09-12 18:26 UTC (History)
3 users (show)

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


Attachments
debug log (12.92 KB, text/plain)
2015-02-24 01:22 UTC, arition
Details
apk (6.86 MB, application/octet-stream)
2015-02-26 05:04 UTC, arition
Details


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 arition 2015-02-24 01:21:54 UTC
When I call DateTime.Now(), It give an System.EntryPointNotFoundException

System.EntryPointNotFoundException: monodroid_get_system_property
  at at (wrapper managed-to-native) System.TimeZoneInfo/AndroidTimeZones.monodroid_get_system_property (string,intptr&) <IL 0x00011, 0x0008c>
  at at System.TimeZoneInfo/AndroidTimeZones.GetDefaultTimeZoneName () <IL 0x0001e, 0x000db>
  at at System.TimeZoneInfo/AndroidTimeZones.get_Default () <IL 0x00025, 0x0013f>
  at at System.TimeZoneInfo.CreateLocal () <IL 0x00000, 0x0003b>
  at at System.TimeZoneInfo.get_Local () <IL 0x0000c, 0x0007b>
  at at Android.Runtime.AndroidCurrentSystemTimeZone..ctor () <IL 0x00001, 0x00047>
  at at Android.Runtime.AndroidEnvironment.GetCurrentSystemTimeZone () <IL 0x00000, 0x0004b>
  at at System.AndroidPlatform.GetCurrentSystemTimeZone () <IL 0x00011, 0x000bf>
  at at System.TimeZone.get_CurrentTimeZone () <IL 0x00039, 0x001e3>
  at at System.DateTime.get_Now () <IL 0x00025, 0x00163>
  at YiQuan.LoginActivity.OnCreate (Android.OS.Bundle) [0x00072] in d:\work\yiquan\YiQuan\YiQuan\LoginActivity.cs:32
  at at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (intptr,intptr,intptr) <IL 0x00013, 0x000ef>
  at at (wrapper dynamic-method) object.bf899bf9-73cb-4ea4-8aa4-d5a8a5e2f837 (intptr,intptr,intptr) <IL 0x00017, 0x00043>


It seems a timezone related issue, for DateTime.UtcNow() do not throw an Error.
Timezone is GMT+8:00 (Shanghai), both computer and phone.

Tested in Android 4.2.2 and 4.3, both have the same issue.
Comment 1 arition 2015-02-24 01:22:26 UTC
Created attachment 9994 [details]
debug log
Comment 2 Jonathan Pryor 2015-02-24 15:09:58 UTC
This is similar/identical to Bug #24756, and I can't currently fathom how either of them can happen.

monodroid_get_system_property() *should* be exported from libmonodroid.so, which needs to be synchronized with the mscorilb.dll bundled with the app. I can't think of any way for these to get out of sync, short of "messing around with" the .apk after its built, e.g. adding a Xamarin.Android 4.20 mscorlib.dll to a .apk containing libmonodroid.so from Xamarin.Android 4.10 (or something similarly crazy).

Furthermore, we haven't been able to reproduce this:

https://bugzilla.xamarin.com/show_bug.cgi?id=24756#c3

What device are you seeing this on?
Comment 3 arition 2015-02-25 01:22:29 UTC
Samsang Galaxy Note 3 Neo (N7505)

Can you give me the correct location of mscorilb.dll and libmonodroid.so? I will try to package the apk by myself.
Comment 4 Jonathan Pryor 2015-02-25 10:56:51 UTC
> Can you give me the correct location of mscorilb.dll and libmonodroid.so?

Yes, no, and it likely won't help.

mscorlib.dll can be found at:

> %ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0

However, this doesn't necessarily help you, because mscorlib.dll, along with other SDK assemblies, are *linked* as part of packaging a Release build.

libmonodroid.so is not a separate file, and is added to the .apk at package creation time. There is no way to separately add it.

Could you please attach the broken .apk? I'd like to examine it.
Comment 5 arition 2015-02-26 05:04:39 UTC
Created attachment 10045 [details]
apk

Attached apks
Comment 6 Jonathan Pryor 2015-02-26 10:25:11 UTC
Thank you for attaching the .apk.

There is a mismatch: Mono.Android.dll is coming from Xamarin.Android 4.20, while libmonodroid.so is coming from before Xamarin.Android 4.14. (Xamarin.Android 4.14 changed to a model wherein instead of statically linking libmonodroid.so and libmonosgen-2.0.a together, libmonodroid.so and libmonosgen-2.0.so are added to the .apk separately. Your .apk doesn't contain a separate libmonosgen-2.0.so library, only the single "unified" libmonodroid.so.)

The best I can fathom is that when you upgraded Xamarin.Android, mandroid.exe wasn't updated, so you have an "ancient" mandroid.exe paired with your up-to-date Xamarin.Android. (I'm not sure how this could happen; it's just a guess.)

Please *uninstall* Xamarin.Android from the Windows Control Panel, reboot, then reinstall from the .msi (or by re-running the unified installer?).
Comment 7 Jonathan Pryor 2015-02-26 10:30:37 UTC
Before uninstalling and reinstalling, please check and report the file timestamps for the following files:

> %ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\mscorlib.dll
> %ProgramFiles(x86)%\MSBuild\Xamarin\Android\mandroid.exe
Comment 8 Jon Douglas [MSFT] 2017-09-12 18:26:22 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!