dotnet tool broken with 3.0-preview4 on openSUSE Tumbleweed #29344

tarekgh · 2019-04-22T19:22:37Z

@ismail commented on Mon Apr 22 2019

This works with preview3, hence it's a regression:

havana ~ > dotnet tool

Welcome to .NET Core 3.0!
---------------------
SDK Version: 3.0.100-preview4-011223

Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
More about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Find out what's new: https://aka.ms/dotnet-whats-new
Learn about the installed HTTPS developer cert: https://aka.ms/aspnet-core-https
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
Write your first app: https://aka.ms/first-net-core-app
--------------------------------------------------------------------------------------
System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Globalization.CalendarData.NormalizeDatePattern(String input)
   at System.Globalization.CalendarData.LoadCalendarDataFromSystem(String localeName, CalendarId calendarId)
   at System.Globalization.CalendarData..ctor(String localeName, CalendarId calendarId, Boolean bUseUserOverrides)
   at System.Globalization.CultureData.GetCalendar(CalendarId calendarId)
   at System.Globalization.CultureData.DateSeparator(CalendarId calendarId)
   at System.Globalization.DateTimeFormatInfo.InitializeOverridableProperties(CultureData cultureData, CalendarId calendarId)
   at System.Globalization.DateTimeFormatInfo.set_Calendar(Calendar value)
   at System.Globalization.CultureInfo.get_DateTimeFormat()
   at System.Globalization.CultureInfo.GetFormat(Type formatType)
   at System.Globalization.DateTimeFormatInfo.get_CurrentInfo()
   at System.Globalization.DateTimeFormatInfo.GetInstance(IFormatProvider provider)
   at System.Globalization.TimeSpanFormat.TryFormat(TimeSpan value, Span`1 destination, Int32& charsWritten, ReadOnlySpan`1 format, IFormatProvider formatProvider)
   at System.TimeSpan.TryFormat(Span`1 destination, Int32& charsWritten, ReadOnlySpan`1 format, IFormatProvider formatProvider)
   at System.Text.StringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.TimeZoneInfo..ctor(Byte[] data, String id, Boolean dstDisabled)
   at System.TimeZoneInfo.GetTimeZoneFromTzData(Byte[] rawData, String id)
   at System.TimeZoneInfo.GetLocalTimeZoneFromTzFile()
   at System.TimeZoneInfo.CachedData.CreateLocal()
   at System.DateTime.get_Now()
   at System.DateTimeOffset.get_Now()
   at Microsoft.AspNetCore.DeveloperCertificates.XPlat.CertificateGenerator.GenerateAspNetHttpsCertificate()
   at Microsoft.DotNet.Cli.AspNetCoreCertificateGenerator.GenerateAspNetCoreDevelopmentCertificate()
   at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(IFirstTimeUseNoticeSentinel firstTimeUseNoticeSentinel, IAspNetCertificateSentinel aspNetCertificateSentinel, IFileSentinel toolPathSentinel, Boolean hasSuperUserAccess, DotnetFirstRunConfiguration dotnetFirstRunConfiguration, IEnvironmentProvider environmentProvider)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Looking at the backtrace, this might be due to ICU, here is the details of ICU packages installed:

havana ~ > rpm -qa | grep libicu
libicu64_1-ledata-64.1-1.1.noarch                                                                                                                                                              
libicu-suse64_1-64.1-1.1.x86_64                                                                                                                                                                
libicu-devel-64.1-1.1.x86_64

@karelz commented on Mon Apr 22 2019

@tarekgh @dagood can you please help route it? Is it a known problem?

@tarekgh commented on Mon Apr 22 2019

I'll try to look. Is there any more data here can help? like debugger dump or more info about the running environment (e.g. what is the locale on the failed machine)?

@dagood if we have a machine or image I can use to check that would be helpful if you point me to that. thanks.

CC @krwq

@dagood commented on Mon Apr 22 2019

No repro with a from scratch install from tarball on a opensuse/tumbleweed container. 😕

docker run -it --rm opensuse/tumbleweed bash -c '
  zypper install -y wget tar gzip libicu
  wget https://download.visualstudio.microsoft.com/download/pr/26d4dc1f-f674-4902-9921-f287f65266f9/ef8a67939f0c3e5729b2674a5e013328/dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz
  mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz -C $HOME/dotnet
  export DOTNET_ROOT=$HOME/dotnet
  export PATH=$PATH:$HOME/dotnet
  dotnet tool'

...

Welcome to .NET Core 3.0!
---------------------
SDK Version: 3.0.100-preview4-011223

Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
More about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Find out what's new: https://aka.ms/dotnet-whats-new
Learn about the installed HTTPS developer cert: https://aka.ms/aspnet-core-https
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
Write your first app: https://aka.ms/first-net-core-app
--------------------------------------------------------------------------------------
Required command was not provided.
Usage: dotnet tool [options] [command]

Options:
  -h, --help   Show command line help.
...

I think it's reasonable to try to repro on that base container if we can get more info, though.

@ismail commented on Mon Apr 22 2019

Locale is C.UTF-8, if you need more information you have to let me know :-)

@dagood commented on Mon Apr 22 2019

Apologies, I see now that looks pretty passive aggressive. I was just expressing my hope that @tarekgh can think of more things to ask about to get to the bottom of this. 🙂 I don't know enough about this area to know what other stuff to gather.

@tarekgh commented on Mon Apr 22 2019

@ismail @dagood what you have sent both is very useful. I'll try to look more here. Thanks for your help.

@tarekgh commented on Mon Apr 22 2019

I can repro this now.

The text was updated successfully, but these errors were encountered:

tarekgh · 2019-04-22T21:01:34Z

@ismail this issue doesn't seem specific for preview 4 as I believe it should repro on the previous versions too (including 2.2 and 2.1). If you want to work around it, change the locale to something different than C locale (something like en_US). meanwhile we'll work on fixing the issue.

tarekgh · 2019-04-23T01:24:25Z

@ismail I wondering about how did you get the ICU installed on the machine you are using? I am asking because what I am seeing is the problem in the ICU and not in the .NET. ICU reporting missing resources error. so, did you manually built or installed ICU? or you just got it with the image you are using?

ismail · 2019-04-23T07:12:38Z

@tarekgh This is a normal desktop system with openSUSE Tumbleweed installed, all the packages are from default openSUSE repositories, except dotnet core, which I installed from official binary tarball.

I see the following data files are installed:

havana ~ > rpm -ql libicu64_1-bedata                                                                                                                                                          
/usr/share/icu
/usr/share/icu/64.1
/usr/share/icu/64.1/icudt64b.dat

havana ~ > rpm -ql libicu64_1-ledata
/usr/share/icu
/usr/share/icu/64.1
/usr/share/icu/64.1/icudt64l.dat

What data exactly is missing?

dagood · 2019-04-23T14:13:26Z

I sent some of this via IM but might as well include it here for context. My original command didn't repro:

docker run -it --rm opensuse/tumbleweed bash -c '
  zypper install -y wget tar gzip libicu
  wget https://download.visualstudio.microsoft.com/download/pr/26d4dc1f-f674-4902-9921-f287f65266f9/ef8a67939f0c3e5729b2674a5e013328/dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz
  mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz -C $HOME/dotnet
  export DOTNET_ROOT=$HOME/dotnet
  export PATH=$PATH:$HOME/dotnet
  dotnet tool'

but adding C locale does repro:

docker run -it --rm opensuse/tumbleweed bash -c '
  zypper install -y wget tar gzip libicu
  wget https://download.visualstudio.microsoft.com/download/pr/26d4dc1f-f674-4902-9921-f287f65266f9/ef8a67939f0c3e5729b2674a5e013328/dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz
  mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-3.0.100-preview4-011223-linux-x64.tar.gz -C $HOME/dotnet
  export DOTNET_ROOT=$HOME/dotnet
  export PATH=$PATH:$HOME/dotnet
  LANG=C.UTF-8 dotnet tool'

This also uses default openSUSE repos--basically the exact same scenario.

It appears the ICU package for openSUSE is maintained somewhere around here:
https://build.opensuse.org/package/show/X11:common:Factory/icu
https://build.opensuse.org/package/show/openSUSE:Factory/icu
I'm not sure how to search the bug tracker for anything like this.

ismail · 2019-04-23T14:49:59Z

Well this seems to be a general ICU bug, see https://github.com/dotnet/corefx/issues/35717

dagood · 2019-04-23T15:08:05Z

True that there may be other issues lurking based on that bug, but the Tumbleweed ICU build does work worse than Leap 15.0's. The above reproing Docker command no longer repros if I replace opensuse/tumbleweed with opensuse/leap:15.0.

Tumbleweed installs:

libicu64_1-ledata-64.1-1.1.noarch
libicu-suse64_1-64.1-1.1.x86_64

Leap 15.0 installs:

libicu60_2-ledata-60.2-lp150.1.4.noarch
libicu60_2-60.2-lp150.1.4.x86_64

ismail · 2019-04-23T15:13:31Z

True that there may be other issues lurking based on that bug, but the Tumbleweed ICU build does work worse than Leap 15.0's. The above reproing Docker command no longer repros if I replace opensuse/tumbleweed with opensuse/leap:15.0.

Tumbleweed has basically new everything: new glibc, kernel, icu ... What would be really helpful is a C#/C++ reproducer, so we can go debug what's going wrong.

tarekgh · 2019-04-23T16:00:05Z

Well this seems to be a general ICU bug, see #962

This is a different issue. We should be supporting C locale. #962 is talking about the behavior when using C locale but for this current issue, is a problem I think in ICU that not providing the need info when having C locale.

tarekgh · 2019-04-23T16:01:18Z

Looks ICU issue is tracked here https://unicode-org.atlassian.net/browse/ICU-20558

Fixes https://github.com/dotnet/corefx/issues/37098 .NET Core depends on ICU when running on Linux/OSX. Recently some people raised some failure on the framework stack. After investigation we found a regression in ICU which is the root cause of this failure. The regression is, when calling ICU to get some date patterns/properties, in some cases ICU return error code U_MISSING_RESOURCE_ERROR. Although the framework code written to fallback to some invariant values at that time, but we had some wrong line of code which assumed we never fail and trying to access the returned value without checking. That cause the framework to throw NullReferenceException. The fix here is to make the framework resilient against such cases and continue to run nicely. I have contact ICU support members and I learned there is similar issue tracked in ICU repo https://unicode-org.atlassian.net/browse/ICU-20558

tarekgh · 2019-04-23T16:31:26Z

Thanks @ismail for reporting this issue. I have submitted a PR which I think the fix will show up in preview 6. meanwhile, there is a work around by setting LANG to some other locale than C.

ismail · 2019-04-23T19:51:39Z

Thanks a lot for tracking this down!

Fixes https://github.com/dotnet/corefx/issues/37098 .NET Core depends on ICU when running on Linux/OSX. Recently some people raised some failure on the framework stack. After investigation we found a regression in ICU which is the root cause of this failure. The regression is, when calling ICU to get some date patterns/properties, in some cases ICU return error code U_MISSING_RESOURCE_ERROR. Although the framework code written to fallback to some invariant values at that time, but we had some wrong line of code which assumed we never fail and trying to access the returned value without checking. That cause the framework to throw NullReferenceException. The fix here is to make the framework resilient against such cases and continue to run nicely. I have contact ICU support members and I learned there is similar issue tracked in ICU repo https://unicode-org.atlassian.net/browse/ICU-20558

Fixes https://github.com/dotnet/corefx/issues/37098 .NET Core depends on ICU when running on Linux/OSX. Recently some people raised some failure on the framework stack. After investigation we found a regression in ICU which is the root cause of this failure. The regression is, when calling ICU to get some date patterns/properties, in some cases ICU return error code U_MISSING_RESOURCE_ERROR. Although the framework code written to fallback to some invariant values at that time, but we had some wrong line of code which assumed we never fail and trying to access the returned value without checking. That cause the framework to throw NullReferenceException. The fix here is to make the framework resilient against such cases and continue to run nicely. I have contact ICU support members and I learned there is similar issue tracked in ICU repo https://unicode-org.atlassian.net/browse/ICU-20558 Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

tarekgh self-assigned this Apr 22, 2019

tarekgh closed this as completed in dotnet/coreclr#24190 Apr 23, 2019

msftgits transferred this issue from dotnet/corefx Feb 1, 2020

msftgits added this to the 3.0 milestone Feb 1, 2020

dotnet locked as resolved and limited conversation to collaborators Dec 13, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dotnet tool broken with 3.0-preview4 on openSUSE Tumbleweed #29344

dotnet tool broken with 3.0-preview4 on openSUSE Tumbleweed #29344

tarekgh commented Apr 22, 2019

tarekgh commented Apr 22, 2019

tarekgh commented Apr 23, 2019

ismail commented Apr 23, 2019

dagood commented Apr 23, 2019 •

edited

ismail commented Apr 23, 2019

dagood commented Apr 23, 2019

ismail commented Apr 23, 2019

tarekgh commented Apr 23, 2019

tarekgh commented Apr 23, 2019

tarekgh commented Apr 23, 2019 •

edited

ismail commented Apr 23, 2019

dotnet tool broken with 3.0-preview4 on openSUSE Tumbleweed #29344

dotnet tool broken with 3.0-preview4 on openSUSE Tumbleweed #29344

Comments

tarekgh commented Apr 22, 2019

tarekgh commented Apr 22, 2019

tarekgh commented Apr 23, 2019

ismail commented Apr 23, 2019

dagood commented Apr 23, 2019 • edited

ismail commented Apr 23, 2019

dagood commented Apr 23, 2019

ismail commented Apr 23, 2019

tarekgh commented Apr 23, 2019

tarekgh commented Apr 23, 2019

tarekgh commented Apr 23, 2019 • edited

ismail commented Apr 23, 2019

dagood commented Apr 23, 2019 •

edited

tarekgh commented Apr 23, 2019 •

edited