Crash after/during Bayesian protein quant

[StSchulze]

Hi,

I'm trying to analyze a fairly large dataset with FlashLFQ but after quantification for all the file is done (including MBR and normalization), it prints the line "How did we get an object larger than the card table?" And then it crashes. I am using version 1.1.1 and am running on a linux (CentOS) system, so I'm using Mono, which isn't always perfectly stable, and the error prints aren't very clear to me. Have you seen this before or any idea what the cause could be? I can also send the full printouts or more about the files, if needed.

[...] Finished MBR for File100 Normalizing fractions Normalizing bioreps and conditions Normalizing techreps Running Bayesian protein quantification analysis How did we get an object larger than the card table?

Native Crash Reporting

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.

Native stacktrace:

0x4c15f3 - mono : (null) 0x4c18fc - mono : (null) 0x46d751 - mono : (null) 0x4c0bf8 - mono : (null) 0x2aaaab3005f0 - /lib64/libpthread.so.0 : (null) 0x2aaaabd63337 - /lib64/libc.so.6 : gsignal 0x2aaaabd64a28 - /lib64/libc.so.6 : abort 0x735794 - mono : (null) 0x71b1d1 - mono : (null) 0x73567b - mono : (null) 0x735aa3 - mono : monoeg_g_logv 0x735b5f - mono : monoeg_g_log 0x6d3e60 - mono : (null) 0x6d3f25 - mono : (null) 0x5d67b6 - mono : (null) 0x5e7b0b - mono : (null) 0x400269cf - Unknown

Telemetry Dumper:

• Assertion: should not be reached at threads.c:6254 Pkilling 0x2aaab4f67700 from 0x2aaaaaaef080 Entering thread summarizer pause from 0x2aaaaaaef080 Finished thread summarizer pause from 0x2aaaaaaef080.

Waiting for dumping threads to resume

Basic Fault Address Reporting

Memory around native instruction pointer (0x2aaaabd63337):0x2aaaabd63327 48 63 d7 48 63 f6 48 63 f9 b8 ea 00 00 00 0f 05 Hc.Hc.Hc........ 0x2aaaabd63337 48 3d 00 f0 ff ff 77 1e f3 c3 0f 1f 80 00 00 00 H=....w......... 0x2aaaabd63347 00 85 c9 7f db 89 c8 f7 d8 81 e1 ff ff ff 7f 0f ................ 0x2aaaabd63357 44 c6 89 c1 eb ca 48 8b 15 ec 0a 39 00 f7 d8 64 D.....H....9...d

Managed Stacktrace:

at <0xffffffff> at System.Array:FastCopy <0x0009e> at System.Array:Copy <0x000b5> at System.Collections.Generic.Dictionary2:Resize <0x000aa> at System.Collections.Generic.Dictionary2:Resize <0x0004a> at System.Collections.Generic.Dictionary2:TryInsert <0x007ba> at System.Collections.Generic.Dictionary2:Add <0x00062> at FlashLFQ.ProteinQuantificationEngine:Setup <0x0149a> at FlashLFQ.ProteinQuantificationEngine:Run <0x00027> at FlashLFQ.FlashLfqEngine:Run <0x0075b> at CMD.FlashLfqExecutable:Run <0x013d3> at <>c:

b__1_1 <0x00027> at CommandLine.ParserResultExtensions:WithParsed <0x0006a> at CMD.FlashLfqExecutable:Main <0x0022b> at :runtime_invoke_void_object <0x00085>

Thanks for any help, Stefan

PS: It didn't seem related to #87 so I open a new issue, but of course feel free to merge if it actually is related.

[trishorts]

ok. interesting error message. We'll see if we can get a message from rob

[trishorts]

google is not yielding much, but there are a couple hits for "How did we get an object larger than the card table" related to mono.

Is it possible for you to run in Linux with .NET Core? I think this version is rated for .NET core 2.1. But we've been pushing our other programs to 3.1. Rob has a note on the command line page https://github.com/smith-chem-wisc/FlashLFQ/wiki/Using-the-Command-Line

indicating RAM issues with mono.

Also, there is a docker. not sure if that's an option for you. Anyway. Let's hear what Rob says.

[rmillikin]

Hmm. Not sure what that error message means - I assume it's something to do with mono. I'll poke around the internet to see if I can find a solution.

As @trishorts suggests perhaps the best solution is to use the .NET Core version. The current version of FlashLFQ runs on .NET Core 2.1 and the next version of FlashFLQ will run on .NET Core 3.1.

[rmillikin]

As a side note, I found it rather difficult to install .NET Core 2.1 on my Linux box, but 3.1 was a snap. I'll try to get a new release out within the next few days.

[rmillikin]

http://docs.go-mono.com/?link=man%3Amono(1)

This does seem to have something to do with garbage collection in mono; this page references a "card table" that is used in 32-bit applications. FlashLFQ is 64-bit btw; that may have something to do with it...

[StSchulze]

Hi guys, thanks for the help. I don't have the option to run it with .NET Core since it's not available on the cluster that I'm working with right now, but I ran it on a different node of the cluster and it finished without the error. So, I think you're both right that it has something to do with Mono and might just be a RAM issue.

So, since it doesn't seem to be a FlashLFQ issue and in combination with the suggested solutions, I'll close this here - thanks again!