HockeyApp failing, and yet not #1196

kentcb · 2016-04-04T03:54:03Z

I'm using HockeyApp and it's successfully uploading the IPA/APK. However, it's failing the build:

Starting Target: deploy-android (==> build-android)
curl -sL -w "\n%{http_code}\n" -H "X-HockeyAppToken:XXX" -F "ipa=@Src/XXX.apk" -F "notes=" -F "notes_type=0" -F "release_type=0" -F "notify=1" -F "mandatory=0" -F "status=2" -F "private=false" -F "teams=" https://rink.hockeyapp.net/api/2/apps/upload
Running build failed.
Error:
System.Exception: Error while posting to HockeyApp.
Messages: ≻楴汴≥∺楌瑴敬敗摥≳∬畢摮敬楟敤瑮晩敩≲∺畡挮浯挮摯桥牥敯⹳楬瑴敬敷摥≳∬異汢捩楟敤瑮晩敩≲∺㔴戵㐱㍦㤴摦昴㝥㝡て㝣〴改てㄸ晣Ⱒ瀢慬晴牯≭∺湁牤楯≤∬敲敬獡彥祴数㨢ⰰ挢獵潴彭敲敬獡彥祴数㨢畮汬∬牣慥整彤瑡㨢㈢㄰ⴶ㐰〭吴㌰㐺㨶㤵≚∬灵慤整彤瑡㨢㈢㄰ⴶ㐰〭吴㌰㐺㨷㌰≚∬敦瑡牵摥㨢慦獬ⱥ爢汯≥〺∬摩㨢〳ㄷㄸ∬潣普杩畟汲㨢栢瑴獰⼺爯湩⹫潨正祥灡⹰敮⽴慭慮敧愯灰⽳〳ㄷㄸ愯灰癟牥楳湯⽳∱∬異汢捩畟汲㨢栢瑴獰⼺爯湩⹫潨正祥灡⹰敮⽴灡獰㐯㔵ㅢ昴㐳昹㑤敦愷昷挰㐷㤰晥㠰挱≦∬業楮畭彭獯癟牥楳湯㨢㐢ㄮⰢ搢癥捩彥慦業祬㨢畮汬∬瑳瑡獵㨢ⰲ瘢獩扩汩瑩≹∺異汢捩Ⱒ漢湷牥㨢䬢湥⁴潂杯慡瑲Ⱒ漢湷牥瑟歯湥㨢㐢㙢捣㥤昹㈴挰㝡ㄲ㈵搳ㅣ攴昸〸㤷㘹㜰换㑦∶੽〲਱
Errors: 

  at Fake.HockeyAppHelper.HockeyApp (Microsoft.FSharp.Core.FSharpFunc`2 setParams) <0x8893dd0 + 0x003df> in <filename unknown>:0 
  at FSI_0005.Build+clo@167-22.Invoke (Microsoft.FSharp.Core.Unit unitVar0) <0x8893da0 + 0x0001b> in <filename unknown>:0 
  at Fake.TargetHelper+targetFromTemplate@195[a].Invoke (Microsoft.FSharp.Core.Unit unitVar0) <0x81f7560 + 0x00020> in <filename unknown>:0 
  at Fake.TargetHelper.runSingleTarget (Fake.TargetTemplate`1 target) <0x81f1318 + 0x000bd> in <filename unknown>:0

I have no idea where the asian characters are coming from. Presumably there's some useful information in there about why this has been considered a failure.

I'm running on Mac/mono, in case it matters.

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

juergenhoetzel · 2016-04-10T12:27:33Z

Maybe this is related to fsprojects/ProjectScaffold#245 (comment)

juergenhoetzel · 2016-04-12T15:11:16Z

@bretkoppel I wonder why the external curl tool is used instead of .NET WebRequest?
Also curl might not be installed on Windows systems.

bretkoppel · 2016-04-12T15:39:19Z

Hmmmm, interesting. I actually started out using WebRequest and remember running into some bizarre issue and falling back to curl, which is what the TestFlightHelper was using(iirc). Could make for a good refactor, though.

FWIW, this is still working in our heavily used build system. Not sure what's going with the double-byte chars in the error message.

kentcb · 2016-04-18T02:38:28Z

@bretkoppel when you say it's working in your system, do you mean it uploads successfully without any exception being raised?

bretkoppel · 2016-04-24T18:41:44Z

Correct. Our build server(mac mini / capitan) has no problems uploading to hockey. Nor have individual developers had problems.

Nickolas- · 2016-04-28T16:01:33Z

Still get this error! Any fixes ?

bretkoppel · 2016-04-28T20:53:26Z

I can repro this at a different part of our build process(totally unrelated to Hockey) now that I've moved to Xamarin's beta channel. I'm looking into that, but don't believe that this is related to Hockey specifically.

juergenhoetzel · 2016-04-28T22:29:00Z

Still get this error! Any fixes ?

With FAKE => 4.25.0 the encoding issue should be fixed

bretkoppel · 2016-04-29T15:13:58Z

@juergenhoetzel I was hoping that your fix in 4.25 would help, but I'm still seeing the unicode output. Digging into it.

bretkoppel · 2016-04-29T18:15:19Z

@juergenhoetzel Ah, I see. My code specifically is calling the Shell.exec entry point, which isn't redirecting to ExecProcessWithLambdas. So the unicode issue for the HockeyAppHelper should indeed be resolved in new versions.

rmunn · 2016-05-17T07:06:48Z

I looked at the Chinese characters, and it looks like they're UTF-8 that's being interpreted as UTF-16: ≻楴汴≥∺楌瑴敬敗摥 is the following sequence of characters:

U+227B SUCCEEDS
U+6974 CJK UNIFIED IDEOGRAPH-6974
U+6C74 CJK UNIFIED IDEOGRAPH-6C74
U+2265 GREATER-THAN OR EQUAL TO
U+223A GEOMETRIC PROPORTION
U+694C CJK UNIFIED IDEOGRAPH-694C
U+7474 CJK UNIFIED IDEOGRAPH-7474
U+656C CJK UNIFIED IDEOGRAPH-656C
U+6557 CJK UNIFIED IDEOGRAPH-6557
U+6465 CJK UNIFIED IDEOGRAPH-6465

Assuming the system is little-endian, that would be the following sequence of UTF-8 characters:

U+007B LEFT CURLY BRACKET
U+0022 QUOTATION MARK
U+0074 LATIN SMALL LETTER T
U+0069 LATIN SMALL LETTER I
U+0074 LATIN SMALL LETTER T
U+006C LATIN SMALL LETTER L
U+0065 LATIN SMALL LETTER E
U+0022 QUOTATION MARK
U+003A COLON
U+0022 QUOTATION MARK
U+004C LATIN CAPITAL LETTER L
U+0069 LATIN SMALL LETTER I
U+0074 LATIN SMALL LETTER T
U+0074 LATIN SMALL LETTER T
U+006C LATIN SMALL LETTER L
U+0065 LATIN SMALL LETTER E
U+0057 LATIN CAPITAL LETTER W
U+0065 LATIN SMALL LETTER E
U+0065 LATIN SMALL LETTER E
U+0064 LATIN SMALL LETTER D

Or, in other words: {"title":"LittleWeed, which is clearly the start of some JSON.

So the thing to look for is why this UTF-8 string is being read as UTF-16.

bretkoppel · 2016-05-24T12:57:22Z

@juergenhoetzel Have you had any luck with this? Reading changes, this should be resolved by upgrading to FAKE >=4.25.0 and ensuring that you're not specifically calling any of the Shell.Exec methods, which resolve to the non-UTF-8 forcing asyncShellExec. Anecdotally, this has resolved any double-byte output in our build scripts. I'll make time to do a deeper dive, though, if you're still having issues after following those steps.

juergenhoetzel · 2016-05-24T21:03:13Z

Works for me> @juergenhoetzel Have you had any luck with this? Reading changes, this should be resolved by upgrading to FAKE >=4.25.0 and ensuring that you're not specifically calling any of the Shell.Exec methods, which resolve to the non-UTF-8 forcing asyncShellExec. Anecdotally, this has resolved any double-byte output in our build scripts. I'll make time to do a deeper dive, though, if you're still having issues after following those steps.

Works for me with FAKE >= 4.25.0 (Setting HockeyAppApiToken to invalid number intentionally):

The resulting target order is:
 - android-deploy
Starting Target: android-deploy 
curl -sL -w "\n%{http_code}\n" -H "X-HockeyAppToken:123" -F "ipa=@test.apk" -F "notes=** Continuous integration build" -F "notes_type=0" -F "release_type=0" -F "notify=1" -F "mandatory=0" -F "status=2" -F "private=false" -F "teams=" -F "owner_id=blub.id" https://rink.hockeyapp.net/api/2/apps/upload
Running build failed.
Error:
System.Exception: Error while posting to HockeyApp.
Messages: {"errors":{"credentials":["api token invalid"]}}; 400
Errors: 

  at Fake.HockeyAppHelper.HockeyApp (Microsoft.FSharp.Core.FSharpFunc`2 setParams) <0x40dc69a0 + 0x003db> in <filename unknown>:0 
  at FSI_0005.Build+clo@376-33.Invoke (Microsoft.FSharp.Core.Unit unitVar0) <0x40dc68d0 + 0x00023> in <filename unknown>:0 
  at Fake.TargetHelper+targetFromTemplate@195[a].Invoke (Microsoft.FSharp.Core.Unit unitVar0) <0x40dc68a0 + 0x00023> in <filename unknown>:0 
  at Fake.TargetHelper.runSingleTarget (Fake.TargetTemplate`1 target) <0x40dbb8d0 + 0x000ca> in <filename unknown>:0

Nickolas- · 2016-06-07T14:52:17Z

FAKE 4.28.0 still getting raised disposing exception when publishing on hockey app.

Time Elapsed 00:00:45.8459450
慪⁲楳湧摥ਮ圊牡楮杮›上⁯琭慳漠⁲琭慳散瑲椠⁳牰癯摩摥愠摮琠楨⁳慪⁲獩渠瑯琠浩獥慴灭摥‮楗桴畯⁴⁡楴敭瑳浡Ɒ甠敳獲洠祡渠瑯戠⁥扡敬琠⁯慶楬慤整琠楨⁳慪⁲晡整⁲桴⁥楳湧牥挠牥楴楦慣整猧攠灸物瑡潩⁮慤整⠠〲㌴〭ⴹ㐱 牯愠瑦牥愠祮映瑵牵⁥敲潶慣楴湯搠瑡⹥
Finished Target: android-package
Starting Target: android-hockey (==> android-package)

Unhandled Exception:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Stream has been closed'.

kentcb · 2016-06-09T03:49:31Z

FWIW, I've found that shelling to curl is somehow (and not predictably) causing the switch to asian characters. I found this when debugging a problem uploading symbols to Raygun. My target was only shelling to curl. Sometimes the output is perfect, but other times (when the progress counter starts) it switches to asian characters.

Here is sample output that is good:

Starting build 0.2.0.1
Building project with version: LocalBuild
Shortened DependencyGraph for Target foo:
<== foo

The resulting target order is:
 - foo
Starting Target: foo 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0 17627    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
100 17677  100    50  100 17627     17   6257  0:00:02  0:00:02 --:--:--  6257
100 17677  100    50  100 17627     17   6257  0:00:02  0:00:02 --:--:--  6257
Finished Target: foo

---------------------------------------------------------------------
Build Time Report
---------------------------------------------------------------------
Target     Duration
------     --------
foo        00:00:02.8647345
Total:     00:00:02.9104028
Status:    Ok
---------------------------------------------------------------------

Example of bad output:

Starting build 0.2.0.1
Building project with version: LocalBuild
Shortened DependencyGraph for Target foo:
<== foo

The resulting target order is:
 - foo
Starting Target: foo 
≻瑓瑡獵㨢䘢楡畬敲Ⱒ䴢獥慳敧㨢䤢癮污摩搠奓⁍楦敬索
†‥潔慴⁬†┠删捥楥敶⁤‥晘牥⁤䄠敶慲敧匠数摥†吠浩⁥†吠浩⁥††楔敭†畃牲湥ੴ††††††††††††††††䐠潬摡†灕潬摡†吠瑯污†匠数瑮††敌瑦†灓敥੤‍〠††〠††‰††‰†〠††〠†††‰††〠ⴠ㨭ⴭⴺ‭ⴭⴺ㨭ⴭⴠ㨭ⴭⴺ‭††ര†‰††‰†〠††〠††‰††‰††〠†††‰ⴭⴺ㨭ⴭⴠ㨭ⴭⴺ‭ⴭⴺ㨭ⴭ††〠‍〠ㄠ㘷㜲††‰††‰†〠††〠†††‰††〠ⴠ㨭ⴭⴺ‭〠〺㨰㄰ⴠ㨭ⴭⴺ‭††ര〱‰㜱㜶‷ㄠ〰††〵†〱‰㜱㈶‷††㜱†㘠㤲″〠〺㨰㈰†㨰〰〺′ⴭⴺ㨭ⴭ†㈶㌹ㄍ〰ㄠ㘷㜷†〱‰†㔠‰ㄠ〰ㄠ㘷㜲††ㄠ‷†㈶㌹†㨰〰〺′〠〺㨰㈰ⴠ㨭ⴭⴺ‭㘠㤲ਲ਼
Finished Target: foo

---------------------------------------------------------------------
Build Time Report
---------------------------------------------------------------------
Target     Duration
------     --------
foo        00:00:02.8436720
Total:     00:00:02.8753681
Status:    Ok
---------------------------------------------------------------------

alexsorokoletov · 2016-06-17T07:12:58Z

I see same problem without any curl references. But I have android packaging also, I believe it is somehow related.

rmunn · 2016-06-27T09:54:18Z

I just had this happen when running the build.sh script from a brand-new project, created from Project Scaffold with no changes (yet). The relevant part of the compilation messages was as follows:

Starting Target: GenerateHelp (==> CleanDocs)
/home/rmunn/code/fsharp/parsetoml/docs/content/release-notes.md does not exist.
/home/rmunn/code/fsharp/parsetoml/docs/content/license.md does not exist.
Building documentation (Default), this could take some time, please wait...
mono "/home/rmunn/code/fsharp/parsetoml/packages/build/FAKE/tools/FAKE.exe" --fsiargs -d:FAKE --define:RELEASE --define:HELP "generate.fsx"
FSharp.Formatting Information: 0 : FSharp.Formatting Logging setup!
Yaaf.FSharp.Scriping Information: 0 : Yaaf.FSharp.Scripting Logging setup!
Copying file: /home/rmunn/code/fsharp/parsetoml/docs/output/img/logo-template.pdn
Copying file: /home/rmunn/code/fsharp/parsetoml/docs/output/img/logo.png
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style.css
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style.css.bak
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style_light.css
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/tips.js
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/img/github-blue.png
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/img/github.png
Generating '/home/rmunn/code/fsharp/parsetoml/docs/tools/../content/index.html'
FSharp.Formatting Critical: 0 :
Processing the file 'docpage' failed
Source written to: '/tmp/tmp1474d38e.tmp.cs'
Compilation errors:

error: (0, 0) 慷湲湩千㜱㄰›獁畳業杮愠獳浥汢⁹敲敦敲据⁥䙠桓牡⹰潃敲敖獲潩㵮⸴⸳⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡洠瑡档獥愠獳浥汢⁹䙠桓牡⹰潃敲敖獲潩㵮⸴⸴⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡‮潙⁵慭⁹敮摥琠畳灰祬爠湵楴敭瀠汯捩੹慷湲湩千㜱㄰›獁畳業杮愠獳浥汢⁹敲敦敲据⁥䙠桓牡⹰潃敲敖獲潩㵮⸴⸳⸱ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡洠瑡档獥愠獳浥汢⁹䙠桓牡⹰潃敲敖獲潩㵮⸴⸴⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡‮潙⁵慭⁹敮摥琠畳灰祬爠湵楴敭瀠汯捩੹

If I interpret that string of mostly-Chinese characters as "UTF-8 wrongly parsed as UTF-16", it decodes into the following text:

warninCS1701: Assuming assembly reference FSharp.CoreVersion=4.3.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a' matches assembly FSharp.CoreVersion=4.4.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a'. You may need tsupply runtime policy
warninCS1701: Assuming assembly reference FSharp.CoreVersion=4.3.1.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a' matches assembly FSharp.CoreVersion=4.4.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a'. You may need tsupply runtime policy

The file '/tmp/tmp1474d38e.tmp.cs' referenced in the error message looks like it had no problems, but here are its contents just in case it's relevant:

// ------------------------------------------------------------------------------
//  <autogenerated>
//      This code was generated by a tool.
//      Mono Runtime Version: 4.0.30319.42000
// 
//      Changes to this file may cause incorrect behavior and will be lost if 
//      the code is regenerated.
//  </autogenerated>
// ------------------------------------------------------------------------------

namespace CompiledRazorTemplates.Dynamic {
    using System;
    using System.Collections.Generic;
    using System.Linq;


    [RazorEngine.Compilation.HasDynamicModelAttribute()]
    public class RazorEngine_90e9c2872af44e3b82bc904286790a59 : FSharp.Literate.DocPageTemplateBase<dynamic> {

#line hidden

        public RazorEngine_90e9c2872af44e3b82bc904286790a59() {
        }

        public override void Execute() {

            #line 1 "/home/rmunn/code/fsharp/parsetoml/packages/build/FSharp.Formatting/templates/docpage.cshtml"

  Layout = "template";
  Title = Properties["page-title"];
  Description = Properties["project-summary"];


            #line default
            #line hidden
WriteLiteral("\r\n");


            #line 6 "/home/rmunn/code/fsharp/parsetoml/packages/build/FSharp.Formatting/templates/docpage.cshtml"
Write(Properties["document"]);


            #line default
            #line hidden
WriteLiteral("\r\n");


            #line 7 "/home/rmunn/code/fsharp/parsetoml/packages/build/FSharp.Formatting/templates/docpage.cshtml"
Write(Properties["tooltips"]);


            #line default
            #line hidden
        }
    }
}

rmunn · 2016-06-27T10:00:47Z

Note that I was not able to reproduce this problem a second time, as the second time I ran build.sh I got a different error:

Starting Target: GenerateHelp (==> CleanDocs)
Deleting /home/rmunn/code/fsharp/parsetoml/docs/content/release-notes.md
Deleting /home/rmunn/code/fsharp/parsetoml/docs/content/license.md
Building documentation (Default), this could take some time, please wait...
mono "/home/rmunn/code/fsharp/parsetoml/packages/build/FAKE/tools/FAKE.exe" --fsiargs -d:FAKE --define:RELEASE --define:HELP "generate.fsx"
FSharp.Formatting Information: 0 : FSharp.Formatting Logging setup!
Yaaf.FSharp.Scriping Information: 0 : Yaaf.FSharp.Scripting Logging setup!
Copying file: /home/rmunn/code/fsharp/parsetoml/docs/output/img/logo-template.pdn
Copying file: /home/rmunn/code/fsharp/parsetoml/docs/output/img/logo.png
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style.css
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style.css.bak
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/style_light.css
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/tips.js
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/img/github-blue.png
Copying styles and scripts: /home/rmunn/code/fsharp/parsetoml/docs/output/content/img/github.png
Generating '/home/rmunn/code/fsharp/parsetoml/docs/tools/../content/index.html'
Redirect assembly from 'FSharp.Compiler.Service, Version=2.0.0.3, Culture=neutral, PublicKeyToken=null' to 'FSharp.Compiler.Service, Version=2.0.0.6, Culture=neutral, PublicKeyToken=null'
FSharp.Formatting Critical: 0 :
Processing the file 'docpage' failed
Source written to: '/tmp/tmp44a9a9d0.tmp.cs'
Compilation errors:

error: (0, 0) Unhandled Exception:

error: (0, 0) Mono.CSharp.InternalErrorException: Failed to import assembly `Argu, Version=2.1.0.0, Culture=neutral, PublicKeyToken=null' ---> System.ArgumentException: Value does not fall within the expected range.

(Rest of error message snipped for brevity).

I believe this one to be a different problem -- I've been able to reproduce it consistently by running build.sh GenerateHelp in a brand-new copy of the ProjectScaffold repo (after running build.sh once to give the project a name). The first run of the GenerateHelp target succeeds (and does NOT include the Redirect assembly line, BTW), then the second one fails (and every subsequent build fails). That's probably a different problem, which I'll report as a separate issue. I'm mentioning it here, though, simply because it is causing me to be unable to reproduce the UTF-8-as-UTF-16 error.

rmunn · 2016-06-27T10:01:54Z

That's with FAKE 4.29.2 on Ubuntu 14.04 (Trusty).

alexsorokoletov · 2016-06-27T15:50:18Z

@rmunn can you please provide source/link to the GenerateHelp task?

rmunn · 2016-06-28T16:45:15Z

@alexsorokoletov It's the default build.fsx file from ProjectScaffold. You can either clone https://github.com/fsprojects/ProjectScaffold and run build.sh (or build.cmd) once to get the build.fsx file (I think you have to supply a project name, but I know the other questions are all optional); or you can look at the source for that GenerateHelp task in the following template file from Project Scaffold:

https://github.com/fsprojects/ProjectScaffold/blob/master/build.template#L229

rmunn · 2016-06-29T03:32:08Z

Steps to reproduce on Linux (on Windows, it seems to work):

git clone https://github.com/fsprojects/ProjectScaffold ReproBuildFail
cd ReproBuildFail
git checkout 1f31b59 since that's a commit I can always reproduce this with.
./build.sh or ./build.cmd
Name project ReproBuildFail, skip all other questions by hitting Enter

Result: the same pseudo-Chinese compilation error I reported above:

Compilation errors:

error: (0, 0) 慷湲湩千㜱㄰›獁畳業杮愠獳浥汢⁹敲敦敲据⁥䙠桓牡⹰潃敲敖獲潩㵮⸴⸳⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡洠瑡档獥愠獳浥汢⁹䙠桓牡⹰潃敲敖獲潩㵮⸴⸴⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡‮潙⁵慭⁹敮摥琠畳灰祬爠湵楴敭瀠汯捩੹慷湲湩千㜱㄰›獁畳業杮愠獳浥汢⁹敲敦敲据⁥䙠桓牡⹰潃敲敖獲潩㵮⸴⸳⸱ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡洠瑡档獥愠獳浥汢⁹䙠桓牡⹰潃敲敖獲潩㵮⸴⸴⸰ⰰ䌠汵畴敲渽略牴污畐汢捩敋呹歯湥戽㌰㕦㝦ㅦ搱〵㍡❡‮潙⁵慭⁹敮摥琠畳灰祬爠湵楴敭瀠汯捩੹

Running iconv -f utf8 -t utf16le on that error gives:

error: (0, 0) warninCS1701: Assuming assembly reference FSharp.CoreVersion=4.3.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a' matches assembly FSharp.CoreVersion=4.4.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a'. You may need tsupply runtime policy
warninCS1701: Assuming assembly reference FSharp.CoreVersion=4.3.1.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a' matches assembly FSharp.CoreVersion=4.4.0.0, Culture=neutralPublicKeyToken=b03f5f7f11d50a3a'. You may need tsupply runtime policy

On Windows, I don't encounter this error, presumably because on Windows, UTF-8 isn't being used and so there's no encoding mismatch to trigger the problem. I can reproduce this consistently on Linux, though.

To reproduce a second time after triggering the error once:

git reset --hard HEAD to bring the original build.sh and init.fsx back.
git clean -dxf to remove untracked files and directories.
Re-run ./build.sh and give it the ReproBuildFail name again, pressing Enter to skip all other questions.

If you skip the git reset or git clean, you'll trigger a different error, but not the wrong-encoding one.

Hopefully the above reproduction steps will help someone narrow down the source of this bug.

rmunn · 2016-06-29T04:23:56Z

Note that I have NOT been able to reproduce this on Linux Mint 18 (based on Ubuntu 16.04). But I can reproduce it consistently on my Ubuntu Trusty (14.04) machine.

rmunn · 2016-06-29T05:58:40Z

Note that, as you can see in fsprojects/FSharp.Formatting#412, I've also been able to reproduce this wrong-encoding bug by compiling a clean copy of the FSharp.Formatting repo (check out the repo, run ./build.sh, pseudo-Chinese error message shows up after about five minutes of building).

rmunn · 2016-06-29T10:02:57Z

One note: by running on Mono 4.2 instead of 4.4 (following these instructions), I was able to stop this bug from triggering in the ProjectScaffold code base. So this might be caused by a Mono bug, and downgrading Mono to 4.2 might be enough to temporarily work around this bug.

alexsorokoletov · 2016-06-29T11:03:41Z

I also started seeing this with mono 4.4

Alex

On Jun 29, 2016, at 06:02, Robin Munn notifications@github.com wrote:

One note: by running on Mono 4.2 instead of 4.4 (following these instructions), I was able to stop this bug from triggering in the ProjectScaffold code base. So this might be caused by a Mono bug, and downgrading Mono to 4.2 might be enough to temporarily work around this bug.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

akoeplinger · 2016-06-30T00:59:08Z

@rmunn this is indeed a regression in Mono 4.4 (https://bugzilla.xamarin.com/show_bug.cgi?id=41979). It was fixed with mono/mono@2748244 and I've scheduled a backport of the fix to a future 4.4 service release.

I tried a local build with the fix applied and your repro doesn't show the problem anymore :)
I was also able to run build.sh a second time and it worked as well now. Thanks for the nice repro!

@forki

See fsprojects/FAKE#1196, fsprojects/FAKE#1212, fsprojects/FAKE#1213 & fsprojects/FAKE#1194 Not sure of the ramifications of this change, but this fixes the encoding issues in FAKE for me. l.Head.Encoding was `System.IO.StringWriter(new System.Text.StringBuilder()).Encoding` which evaluates to utf-16 /cc:@forki

matthid · 2017-05-06T17:37:10Z

I guess this is fixed.

kentcb mentioned this issue Apr 4, 2016

Object Disposed Exception #1194

Closed

rmunn mentioned this issue Jun 29, 2016

Can't generate documentation on Linux: "Failed to import assembly 'Argu, Version=2.1.0.0, Culture=neutral, PublicKeyToken=null' fsprojects/FSharp.Formatting#412

Closed

rmunn mentioned this issue Jul 5, 2016

NUnit failures on list-ops test exercism/fsharp#155

Closed

matthid mentioned this issue Jul 14, 2016

Documentation generation failed on mono fsprojects/FSharp.Formatting#414

Closed

nosami mentioned this issue Oct 7, 2016

Fix FAKE Chinese text bug matthid/Yaaf.FSharp.Scripting#8

Merged

matthid closed this as completed May 6, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HockeyApp failing, and yet not #1196

HockeyApp failing, and yet not #1196

kentcb commented Apr 4, 2016

juergenhoetzel commented Apr 10, 2016

juergenhoetzel commented Apr 12, 2016

bretkoppel commented Apr 12, 2016

kentcb commented Apr 18, 2016

bretkoppel commented Apr 24, 2016

Nickolas- commented Apr 28, 2016

bretkoppel commented Apr 28, 2016 •

edited

Loading

juergenhoetzel commented Apr 28, 2016

bretkoppel commented Apr 29, 2016

bretkoppel commented Apr 29, 2016

rmunn commented May 17, 2016

bretkoppel commented May 24, 2016

juergenhoetzel commented May 24, 2016

Nickolas- commented Jun 7, 2016 •

edited

Loading

kentcb commented Jun 9, 2016 •

edited

Loading

alexsorokoletov commented Jun 17, 2016

rmunn commented Jun 27, 2016

rmunn commented Jun 27, 2016

rmunn commented Jun 27, 2016

alexsorokoletov commented Jun 27, 2016

rmunn commented Jun 28, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

alexsorokoletov commented Jun 29, 2016

akoeplinger commented Jun 30, 2016 •

edited

Loading

matthid commented May 6, 2017

HockeyApp failing, and yet not #1196

HockeyApp failing, and yet not #1196

Comments

kentcb commented Apr 4, 2016

juergenhoetzel commented Apr 10, 2016

juergenhoetzel commented Apr 12, 2016

bretkoppel commented Apr 12, 2016

kentcb commented Apr 18, 2016

bretkoppel commented Apr 24, 2016

Nickolas- commented Apr 28, 2016

bretkoppel commented Apr 28, 2016 • edited Loading

juergenhoetzel commented Apr 28, 2016

bretkoppel commented Apr 29, 2016

bretkoppel commented Apr 29, 2016

rmunn commented May 17, 2016

bretkoppel commented May 24, 2016

juergenhoetzel commented May 24, 2016

Nickolas- commented Jun 7, 2016 • edited Loading

kentcb commented Jun 9, 2016 • edited Loading

alexsorokoletov commented Jun 17, 2016

rmunn commented Jun 27, 2016

rmunn commented Jun 27, 2016

rmunn commented Jun 27, 2016

alexsorokoletov commented Jun 27, 2016

rmunn commented Jun 28, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

rmunn commented Jun 29, 2016

alexsorokoletov commented Jun 29, 2016

akoeplinger commented Jun 30, 2016 • edited Loading

matthid commented May 6, 2017

bretkoppel commented Apr 28, 2016 •

edited

Loading

Nickolas- commented Jun 7, 2016 •

edited

Loading

kentcb commented Jun 9, 2016 •

edited

Loading

akoeplinger commented Jun 30, 2016 •

edited

Loading