Bug 33493 - Crashing with SIGABRT and error: "We don't know how many blocks we have?"
Summary: Crashing with SIGABRT and error: "We don't know how many blocks we have?"
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: 4.2.0 (C6)
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Vlad Brezae
URL:
: 33357 37731 37766 ()
Depends on:
Blocks:
 
Reported: 2015-08-30 03:22 UTC by Martin Booth
Modified: 2016-01-20 15:21 UTC (History)
6 users (show)

Tags:
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 FIXED

Description Martin Booth 2015-08-30 03:22:32 UTC
Looks like there is an issue with sgen.

Not sure what I can do with regards to a repro for this. My application is fairly simple. It just gets files using an HttpClient from one a webservice, and writes them into S3 using the AWS SDK. I'm not sure whether this is relevant or not though, given the issue seems to be with garbage collection and sgen.

Error is as follows:

We don't know how many blocks we have?
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Array.Clone (System.Array) <0xffffffff>
  at Mono.Security.ASN1.get_Value () <0x0002b>
  at Mono.Security.X509.X501.AppendEntry (System.Text.StringBuilder,Mono.Security.ASN1,bool) <0x0044f>
  at Mono.Security.X509.X501.ToString (Mono.Security.ASN1) <0x00062>
  at Mono.Security.X509.X509Certificate.Parse (byte[]) <0x00367>
  at Mono.Security.X509.X509Certificate..ctor (byte[]) <0x000b2>
  at System.Security.Cryptography.X509Certificates.X509Certificate.Import (byte[],string,System.Security.Cryptography.X509Certificates.X509KeyStorageFlags) <0x00092>
  at System.Security.Cryptography.X509Certificates.X509Certificate2.Import (byte[],string,System.Security.Cryptography.X509Certificates.X509KeyStorageFlags) <0x002c7>
  at System.Security.Cryptography.X509Certificates.X509Certificate2..ctor (byte[]) <0x00056>
  at System.Security.Cryptography.X509Certificates.X509Store.Open (System.Security.Cryptography.X509Certificates.OpenFlags) <0x001ce>
  at System.Security.Cryptography.X509Certificates.X509Chain.get_LMRootStore () <0x000ad>
  at System.Security.Cryptography.X509Certificates.X509Chain.get_Roots () <0x000d3>
  at System.Security.Cryptography.X509Certificates.X509Chain.get_CertificateCollection () <0x000a8>
  at System.Security.Cryptography.X509Certificates.X509Chain.FindParent (System.Security.Cryptography.X509Certificates.X509Certificate2) <0x0002e>
  at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom (System.Security.Cryptography.X509Certificates.X509Certificate2) <0x0004a>
  at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2) <0x00091>
  at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection) <0x00341>
  at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) <0x0002a>
  at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) <0x00018>
  at Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) <0x00019>
  at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.RemoteValidation (Mono.Security.Protocol.Tls.ClientContext,Mono.Security.Protocol.Tls.AlertDescription) <0x0003a>
  at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection) <0x0008c>
  at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () <0x001c8>
  at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0x00062>
  at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0xffffffff>
  at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream) <0x000bd>
  at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (System.IAsyncResult) <0x002d6>
  at System.Net.Sockets.SocketAsyncResult.<ExecuteWorkItem>m__1 (object) <0x000a5>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>
  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Runtime.Remoting.Messaging.AsyncResult.Invoke (System.Runtime.Remoting.Messaging.AsyncResult) <0xffffffff>
  at System.Runtime.Remoting.Messaging.AsyncResult.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0x0000c>
  at System.Threading.ThreadPoolWorkQueue.Dispatch () <0x001d6>
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0x00008>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        mono() [0x49cedc]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7f9e551348d0]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f9e54db1107]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f9e54db24e8]
        mono() [0x629ed9]
        mono() [0x62a0e7]
        mono() [0x62a192]
        mono() [0x5ecf16]
        mono() [0x5e59ff]
        mono() [0x5e8202]
        mono() [0x5db645]
        mono() [0x5ca2fe]
        mono(mono_array_new_full+0x1d2) [0x5a9d22]
        mono() [0x5aacc5]
        [0x416d9114]

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Comment 1 Mark Probst 2015-09-08 17:38:30 UTC
Could you check whether this still occurs with current master (commit 54ede58d34a91a299b5863664341bbb0a4e6a370, specifically)?
Comment 2 Martin Booth 2015-09-09 02:03:34 UTC
Thanks for getting back to me.

I tried the latest nightly build (today) from 

deb http://download.mono-project.com/repo/debian nightly main

and the application only ran for about 45 minutes however I received a different exception which seems to be related:

Why are we doing work while there's a nursery collection happening?

Native stacktrace:

        mono() [0x49c888]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0) [0x7f4b27b110a0]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f4b277a9165]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [0x7f4b277ac3e0]
        mono() [0x6289c9]
        mono() [0x628bd7]
        mono() [0x628c82]
        mono() [0x5f8225]
        mono() [0x5f7c30]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f4b27b08b50]
        /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f4b2785295d]

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Comment 3 Mark Probst 2015-09-09 19:00:54 UTC
Are you using `marksweep-conc`?
Comment 4 Martin Booth 2015-09-09 19:02:59 UTC
Yes, I am
Comment 5 Mark Probst 2015-09-09 20:22:31 UTC
Vlad, could you take a look at this, please?
Comment 6 Vlad Brezae 2015-09-14 14:40:35 UTC
Hey Martin,

      Are there any other non standard params used aside from `marksweep-conc` ?
 
      Could we get a repro for this, so I could run the code and catch the bug on my machine ?

Vlad
Comment 7 Martin Booth 2015-09-14 21:40:52 UTC
our full params are as follows:

MONO_GC_PARAMS=max-heap-size=2g,soft-heap-limit=128m,major=marksweep-conc

Will try and create a repro for this shortly
Comment 8 Vlad Brezae 2015-09-18 19:29:16 UTC
Before trying to create a repro you might want to check if the blocks assert still happens with your app with the latest nightly build as indicated by Mark in comment 1.

The nightly build that you've tried doesn't include the specified commit. We no longer have that assert on master. (`Why are we doing work while there's a nursery collection happening?`)
Comment 9 Martin Booth 2015-09-24 20:57:55 UTC
Thanks for your suggestion. I have tried the new build and it has resolved this issue. No more SIGABRT.

This may be an unrelated issue/question but do you know if the MONO_GC_PARAMS are still being correctly honoured? The amount of memory that my application consumes exceeds the maximum it's allowed to given the parameters I use.

Previously I used to see out of memory exceptions when it consumed too much memory, now it seems to just go over the limit and gets terminated by docker

Thanks
Comment 10 Mark Probst 2015-09-25 12:35:43 UTC
It should.  If it doesn't, please file it as a bug.
Comment 11 Peter Collins 2015-12-16 19:34:33 UTC
*** Bug 33357 has been marked as a duplicate of this bug. ***
Comment 12 Rolf Bjarne Kvinge [MSFT] 2016-01-18 16:04:53 UTC
*** Bug 37766 has been marked as a duplicate of this bug. ***
Comment 13 Peter Collins 2016-01-20 15:21:32 UTC
*** Bug 37731 has been marked as a duplicate of this bug. ***