Bug 40862 - 4.4.0 Compression regression
Summary: 4.4.0 Compression regression
Status: RESOLVED DUPLICATE of bug 39237
Alias: None
Product: Class Libraries
Classification: Mono
Component: SharpZipLib ()
Version: 4.4.0 (C7)
Hardware: PC Linux
: --- normal
Target Milestone: (C7)
Assignee: Alexander Köplinger [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2016-05-04 14:55 UTC by henrik
Modified: 2016-05-10 15:26 UTC (History)
6 users (show)

Tags: c7regression
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 GitHub or Developer Community 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 DUPLICATE of bug 39237

Description henrik 2016-05-04 14:55:56 UTC
Compression regression

"Could not fix timestamps in /home/travis/build/Hopac/Hopac/packages/FsCheck/FsCheck.2.2.2.nupkg. Error: The type initializer for 'SharpCompress.Common.ArchiveEncoding' threw an exception."


See https://travis-ci.org/Hopac/Hopac/jobs/127813205#L1114 for a build log w/ details.

Mono 4.4.0.

Regards
Comment 1 Alexander Köplinger [MSFT] 2016-05-04 21:35:20 UTC
I can repro in the current beta channel Mono 4.4.0.142, but it seems to be fixed in the alpha channel Mono 4.4.0.148. Can you please try and see if that one works for you too?
Comment 2 henrik 2016-05-05 08:54:23 UTC
Sorry, I can't. No time; but if you want you can push a new beta.

I just reported this out of courtesy, but when it's in beta my CI build will pick it up.
Comment 3 Jason Imison 2016-05-05 13:41:30 UTC
I have 4.4.0.148 installed and the issue is still there. I am seeing the problem when restoring packages with Paket.
Comment 4 Jason Imison 2016-05-05 13:56:56 UTC
I've created a mono debug log here https://github.com/nosami/nosami.github.io/blob/master/paketrestore?raw=true . It's 32mb so too big to attach here

On one occasion yesterday, I got a native stacktrace

 mono() [0x4a728a] mono() [0x4fbb6e] mono() [0x426247] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f2f85c828d0] /lib/x86_64-linux-gnu/libz.so.1(inflate+0x5f) [0x7f2f60ab024f] /usr/lib/libMonoPosixHelper.so(ReadZStream+0x55) [0x7f2f60cd9b65] [0x40311efc]
Comment 5 Alexander Köplinger [MSFT] 2016-05-09 15:32:52 UTC
Jason: can you please add a repro sample and more details about your environment, I can't seem to repro with 4.4.0.148 on Ubuntu 14.04.
Comment 6 Jason Imison 2016-05-09 15:53:25 UTC
Try cloning the F# MonoDevelop addin from here https://github.com/fsharp/xamarin-monodevelop-fsharp-addin.git

Then run `mono ./paket/paket.bootstrapper.exe`. This downloads paket.exe.

Then run `mono ./paket/paket.exe restore` from the root folder

I hit this bug with Mono 4.4.0.1.48 on Debian 8.0, not sure if the OS is relevant.
Comment 7 henrik 2016-05-09 16:47:30 UTC
If you follow the link to the Hopac travis jobs, there's a repro there.
Comment 8 Alexander Köplinger [MSFT] 2016-05-09 17:12:56 UTC
Henrik: I did that in https://bugzilla.xamarin.com/show_bug.cgi?id=40862#c1 and it was fixed with 4.4.0.148 for me, so I was curious why Jason is still seeing it.

Jason: I tried your sample and it doesn't even repro in 4.4.0.142 on Ubuntu 14.04 for me. Can you please try deleting the packages/ folder and do `mono ./.paket/paket.exe clear-cache` to make sure there aren't any invalid .nupkg cached somewhere?
Comment 9 Jason Imison 2016-05-09 18:11:54 UTC
jason@debian:~/src/monodevelop/main/external/fsharpbinding$ mono .paket/paket.exe clear-cache
Paket version 2.63.3.0
0 seconds - ready.
jason@debian:~/src/monodevelop/main/external/fsharpbinding$ mono .paket/paket.exe restore
Paket version 2.63.3.0
Downloading ExtCore 0.8.45
Downloading FAKE 4.22.4
Downloading Fantomas 2.0.2
Downloading FSharp.Compiler.CodeDom 0.9.2
Downloading FSharp.Compiler.Service 2.0.0.6
Downloading FSharp.Core 4.0.0.1
Downloading Mono.Cecil 0.9.6.1
Downloading Newtonsoft.Json 8.0.3
Could not fix timestamps in /home/jason/src/monodevelop/main/external/fsharpbinding/packages/ExtCore/ExtCore.0.8.45.nupkg. Error: The type initializer for 'SharpCompress.Common.ArchiveEncoding' threw an exception.
Something went wrong while downloading ExtCore 0.8.45
Message: Error during extraction of /home/jason/src/monodevelop/main/external/fsharpbinding/packages/ExtCore/ExtCore.0.8.45.nupkg.
Message: The type initializer for 'SharpCompress.Common.ArchiveEncoding' threw an exception.
  ==> Trying again
Comment 10 Jason Imison 2016-05-09 18:17:16 UTC
fwiw, I've looked at the downloaded packages and they are all valid zip archives.
Comment 11 Jason Imison 2016-05-09 18:21:07 UTC
I just tried this again, and got a further log message. Don't know if it's useful.

_wapi_connect: error looking up socket handle 0xf
_wapi_connect: error looking up socket handle 0x10
_wapi_connect: error looking up socket handle 0x10
Comment 12 Alexander Köplinger [MSFT] 2016-05-09 20:04:27 UTC
I can repro in a Debian Jessie docker container with the repro Jason posted with Mono 4.4.0.148. I'm taking a look now.
Comment 13 Alexander Köplinger [MSFT] 2016-05-09 21:27:04 UTC
Ok, so it seems like it boils down to this line in SharpCompress: https://github.com/mono/mono/blob/mono-4.4.0-branch/mcs/class/System.IO.Compression/SharpCompress/Common/ArchiveEncoding.cs#L24

If I run this in the csharp repl, I get the following exception:

> csharp> System.Text.Encoding.GetEncoding(System.Globalization.CultureInfo.CurrentCulture.TextInfo.OEMCodePage) 
> System.NotSupportedException: No data is available for encoding 437.
>   at System.Text.Encoding.GetEncoding (Int32 codepage) [0x0024f] in /tmp/buildd/mono-4.4.0.148/external/referencesource/mscorlib/system/text/encoding.cs:554 
>   at <InteractiveExpressionClass>.Host (System.Object& $retval) <0x405706e0 + 0x0002f> in <filename unknown>:0 
>   at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object& result, System.Boolean& result_set) [0x0003e] in /tmp/buildd/mono-4.4.0.148/mcs/mcs/eval.cs:374 
>   at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in /tmp/buildd/mono-4.4.0.148/mcs/tools/csharp/repl.cs:385

It is indeed a regression from the current stable Mono 4.2.3.4, which prints "I18N.West.CP437" when I run the above code.
Comment 14 henrik 2016-05-10 06:52:01 UTC
Alexander: I mean that I added alpha versions to the build of Hopac and it's still crashing.
Comment 15 Marek Safar 2016-05-10 09:37:50 UTC
There was some packaging redesign (or regression) which means some packages are no longer installed by default. You need to install additional languages support to have I18N.West.dll available.

Similar issue is here https://bugzilla.xamarin.com/show_bug.cgi?id=39237
Comment 16 Jason Imison 2016-05-10 11:08:01 UTC
I installed libmono-i18n4.0-cil and the problem is fixed for me.
Comment 17 henrik 2016-05-10 11:45:31 UTC
Marek: where are the docs for these new packages? I don't want to play whack-a-mole with them, you see.
Comment 18 Jason Imison 2016-05-10 11:48:45 UTC
@Alexander - Should this package be installed by default on Travis?
Comment 19 Alexander Köplinger [MSFT] 2016-05-10 12:00:37 UTC
I did have the I18N.West.dll, but I was missing I18N.dll.

I can confirm that it works if I install the dll via the libmono-i18n4.0-cil packag. This looks like a packaging bug or unwanted behavior to me though because if I install mono-devel from the stable channel it works, but if I install it from the alpha channeel it's broken.

Marek: I18N.dll is required by the locale system right? So it should be pulled in as a dependency of the other packages?
Comment 20 Marek Safar 2016-05-10 12:09:12 UTC
@Alexander: Correct. Any I18N.<region>.dll has I18N.dll dependency.
Comment 21 Jo Shields 2016-05-10 15:26:39 UTC

*** This bug has been marked as a duplicate of bug 39237 ***