Reputation: 434
I have a problem that the current mono does not work with current nuget for one of my packages. It hangs indefinately sitting on the CPU. It seems like a bug in mono runtime, but I'm not sure.
I'd like to debug it, but i'm lost on how to do that. I already produced a debug version of nuget.exe with a pdb, but what to do now? I tried xamarin studio (on windows), it won't allow me to start the mono process and the break into it.
Any ideas what tools to use and what to do?
EDIT: detailed info
The problem occures on windows, on linux/x64 and linux/arm, windows on mono 4.0.1, linux on 4.0.2.4 (which I built myself).
my command is this:
mono --debug nuget.exe install LC3xx.Frontend -ConfigFile nuget.config -ExcludeVersion -Verbosity detailed
The process hangs, using 1 CPU core and on windows I can see that it is reading data (process explorer showing I/O read bytes increasing (gigabytes and gigabytes) though my nuget package is just 5 MB.
When I press ctrl-C sometimes it'll show this:
Unhandled Exception:
System.ObjectDisposedException: The object was used after being disposed.
at System.IO.FileStream.Flush () [0x00020] in /root/mono-3.12.1/mcs/class/corlib/System.IO/FileStream.cs:826
at zipsharp.ZipStream.Dispose (bool) [0x00007] in /root/mono-3.12.1/mcs/class/WindowsBase/ZipSharp/ZipStream.cs:89
at System.IO.Stream.Close () [0x00000] in /root/mono-3.12.1/mcs/class/corlib/System.IO/Stream.cs:113
at zipsharp.ZipStream.CloseFile_Native (intptr,intptr) [0x00000] in /root/mono-3.12.1/mcs/class/WindowsBase/ZipSharp/ZipStream.cs:123
at (wrapper native-to-managed) zipsharp.ZipStream.CloseFile_Native (intptr,intptr) <IL 0x00025, 0x000af>
at (wrapper managed-to-native) zipsharp.NativeUnzip.unzClose (zipsharp.UnzipHandle) <0x0003b>
at zipsharp.NativeUnzip.CloseArchive (zipsharp.UnzipHandle) [0x00000] in /root/mono-3.12.1/mcs/class/WindowsBase/ZipSharp/NativeUnzip.cs:27
at zipsharp.UnzipHandle.ReleaseHandle () <0x00013>
at System.Runtime.InteropServices.SafeHandle.Finalize () [0x00016] in /root/mono-3.12.1/mcs/class/corlib/System.Runtime.InteropServices/SafeHandle.cs:237
Since on Linux I built mono myself I went to ZipStream.cs and commented the Flush() out in Dispose(). This changed the message to this:
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
at zipsharp.ZipStream.CloseFile_Native (IntPtr opaque, IntPtr stream) [0x00000] in /home/user/mono-4.0.2/mcs/class/WindowsBase/ZipSharp/ZipStream.cs:123
at (wrapper managed-to-native) zipsharp.NativeUnzip:unzClose (zipsharp.UnzipHandle)
at zipsharp.NativeUnzip.CloseArchive (zipsharp.UnzipHandle handle) [0x00000] in /home/user/mono-4.0.2/mcs/class/WindowsBase/ZipSharp/NativeUnzip.cs:27
at zipsharp.UnzipHandle.ReleaseHandle () [0x00000] in /home/user/mono-4.0.2/mcs/class/WindowsBase/ZipSharp/UnzipHandle.cs:28
at System.Runtime.InteropServices.SafeHandle.Dispose (Boolean disposing) [0x00045] in /home/user/mono-4.0.2/mcs/class/corlib/System.Runtime.InteropServices/SafeHandle.cs:175
at System.Runtime.InteropServices.SafeHandle.Finalize () [0x00000] in /home/user/mono-4.0.2/mcs/class/corlib/System.Runtime.InteropServices/SafeHandle.cs:233
Which is even weirder, because CloseFile_Native() just calls this.Close(), so it must be a called on an anready destructed object!?
Weirdly, today, on windows, the installation of my nuget package actually completed, takign ages (120sec+) and somehow reading 50gigs of data in the process.
Debugging: when I attach the VS debugger to the process, I just see this in the main thread:
ntdll.dll!770c2315() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
monosgen-2.0.dll!1015afde() Unknown
00510a80() Unknown
MonoPosixHelper.dll!68a4f549() Unknown
MonoPosixHelper.dll!68a4f6af() Unknown
MonoPosixHelper.dll!68a4f99b() Unknown
MonoPosixHelper.dll!68a5027e() Unknown
MonoPosixHelper.dll!68a5039b() Unknown
05116730() Unknown
051165c8() Unknown
051153b4() Unknown
051207fc() Unknown
05114958() Unknown
05114744() Unknown
051146f0() Unknown
0511458e() Unknown
05114550() Unknown
05113d87() Unknown
05113c9c() Unknown
05113ba4() Unknown
05111700() Unknown
05111634() Unknown
05111560() Unknown
05110fb4() Unknown
05110459() Unknown
051102f4() Unknown
037f546a() Unknown
0381ad6e() Unknown
037f54d2() Unknown
03805460() Unknown
038052e0() Unknown
05102f34() Unknown
05102b84() Unknown
05102827() Unknown
051053c8() Unknown
05110234() Unknown
0510fde0() Unknown
0510fc74() Unknown
0510fc2c() Unknown
0510fbcc() Unknown
0510f61a() Unknown
0510f448() Unknown
05108e94() Unknown
051082ec() Unknown
051081e0() Unknown
051020d7() Unknown
03846cf1() Unknown
03845c74() Unknown
0381ffb0() Unknown
037b3429() Unknown
037b383f() Unknown
monosgen-2.0.dll!10025f64() Unknown
monosgen-2.0.dll!100f7c70() Unknown
monosgen-2.0.dll!100f7afd() Unknown
monosgen-2.0.dll!100f8626() Unknown
monosgen-2.0.dll!100865f2() Unknown
monosgen-2.0.dll!10085c56() Unknown
monosgen-2.0.dll!10087d02() Unknown
mono-sgen.exe!mono_main_with_options(int argc, char * * argv) Line 91 C
mono-sgen.exe!main() Line 112 C
mono-sgen.exe!__tmainCRTStartup() Line 626 C
kernel32.dll!74d3337a() Unknown
ntdll.dll!770d92e2() Unknown
ntdll.dll!770d92b5() Unknown`
What I don't see is what call nuget is sitting in. So I don't really know if this is a nuget bug or a mono bug (though it does look very much like mono bug)
When I don't interrupt the process with ctrl-C, I get no error messages, just sitting there and eating CPU while reading data.
EDIT FOUND: well seems I found the problem. Mono's System.IO.Packaging.Package is asking for compression level of each file inside the package, which in turn reads and uncompresses the whole archive - for each file inside. I have a nuget package with over 1000 files, so it's taking that long.
Upvotes: 0
Views: 307
Reputation: 47907
On Linux or Mac it is usually easier to debug a .NET application that is running under Mono by debugging it with MonoDevelop or Xamarin Studio.
Open the NuGet.sln in MonoDevelop, configure the command line you want to use in the project options, Run, General for the CommandLine project, then debug the CommandLine project. The CommandLine project will run NuGet.exe under the debugger.
Upvotes: 1