fragpipe's docker container on mac-os 14.6.1; problem with mono?

[vspiceruofm]

- Upload your log file (If a log file hasn't been generated, go to the 'Run' tab in FragPipe, click 'Export Log', zip the resulting "log_[date_time].txt" file to avoid truncation, then attach the zipped file by drag & drop here.)

root@2aebbf800dcc:/fragpipe_bin# mono /data/CODE/MSFragger-4.1/ext/thermo/BatmassIoThermoServer.exe TYPE: 6 V: mono_helper_ldstr

• Assertion at ../../mono/arch/amd64/../x86/x86-codegen.h:410, condition `offset == (gint32)offset' not met

================================================================= 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:

0x55555561404b - mono : 
0x5555556143dd - mono : 
0x5555555c1087 - mono : 
0x5555556135cc - mono : 
0x7fffff275520 - /lib/x86_64-linux-gnu/libc.so.6 : 
0x7fffff2c99fc - /lib/x86_64-linux-gnu/libc.so.6 : pthread_kill
0x7fffff275476 - /lib/x86_64-linux-gnu/libc.so.6 : raise
0x7fffff25b7f3 - /lib/x86_64-linux-gnu/libc.so.6 : abort
0x5555555833c4 - mono : 
0x555555868135 - mono : 
0x5555558855be - mono : 
0x555555885c73 - mono : monoeg_assertion_message
0x555555885cb0 - mono : mono_assertion_message_disabled
0x5555555e9bb8 - mono : 
0x55555561729b - mono : 
0x55555561a83b - mono : 
0x55555561ab96 - mono : 
0x55555558c1e2 - mono : 
0x5555555c49c6 - mono : 
0x5555555c5792 - mono : 
0x7fffff220513 - Unknown

================================================================= Telemetry Dumper:

Pkilling 0x140737430300224x from 0x140737473878976x Entering thread summarizer pause from 0x140737473878976x Finished thread summarizer pause from 0x140737473878976x. Failed to create breadcrumb file (null)/crash_hash_0x5a3fa54aa

Waiting for dumping threads to resume

================================================================= External Debugger Dump:

mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb

================================================================= Basic Fault Address Reporting

Memory around native instruction pointer (0x7fffff2c99fc):0x7fffff2c99ec 05 00 44 89 e2 89 ee 89 c7 b8 ea 00 00 00 0f 05 ..D............. 0x7fffff2c99fc 41 89 c5 41 f7 dd 3d 00 f0 ff ff b8 00 00 00 00 A..A..=......... 0x7fffff2c9a0c 44 0f 46 e8 e9 6d ff ff ff 0f 1f 00 48 89 ef e8 D.F..m......H... 0x7fffff2c9a1c 10 a8 ff ff e9 29 ff ff ff 0f 1f 00 48 89 ef e8 .....)......H...

================================================================= Managed Stacktrace:

  at <unknown> <0xffffffff>
  at System.Configuration.InternalConfigurationSystem:InitForConfiguration <0x0006e>
  at System.Configuration.Configuration:.ctor <0x000f7>
  at System.Configuration.InternalConfigurationFactory:Create <0x000a7>
  at System.Configuration.ConfigurationManager:OpenExeConfigurationInternal <0x003fe>
  at System.Configuration.ClientConfigurationSystem:get_Configuration <0x0006b>
  at System.Configuration.ClientConfigurationSystem:System.Configuration.Internal.IInternalConfigSystem.GetSection <0x0003f>
  at System.Configuration.ConfigurationManager:GetSection <0x00055>
  at NLog.Config.XmlLoggingConfiguration:get_AppConfig <0x00043>
  at NLog.Config.LoggingConfigurationWatchableFileLoader:TryLoadFromAppConfig <0x00037>
  at NLog.Config.LoggingConfigurationWatchableFileLoader:Load <0x00077>
  at NLog.LogFactory:get_Configuration <0x00119>
  at NLog.LogFactory:GetLoggerThreadSafe <0x002c7>
  at NLog.LogFactory:GetLogger <0x00137>
  at NLog.LogManager:GetCurrentClassLogger <0x0004f>
  at DmtAvt.BatmassIo.Thermo.BatmassIoThermoServer:.cctor <0x00027>
  at System.Object:runtime_invoke_void <0x0009d>

================================================================= Aborted root@2aebbf800dcc:/fragpipe_bin#

--- mono running batmassiothermoserver natively in OS-X 14.6.1

Last login: Thu Aug 22 10:20:35 on ttys002 (base) vspicer@vspiceracStudio ~ % cd ~/RESEARCH/DOCKER2024/CODE/MSFragger-4.1/ext/thermo
(base) vspicer@vspiceracStudio thermo % mono BatmassIoThermoServer.exe Batmass-IO Thermo stdio (1.4.0.0) By Nesvizhskii Lab, University of Michigan

Usage: BatmassIoThermoServer[.exe] stdinout [options] Options: parseIndex parseRange2 getInstrumentInfo

(base) vspicer@vspiceracStudio thermo %

- Describe the issue or question:

the container itself works fine when i run it on a ubuntu box, but it looks like the container's mono and the current docker desktop version for mac (4.33.0) don't like each other. when i am out in mac-os i can also run the batmass server without issue, and can run the msfragger java without issues.

any suggestions on a work around, maybe re-installing something inside the container once it's launched?

thanks! vic

[fcyu]

Thank you for the issue report. I need more time to debug because my Mac is not in the lab but at home. Will keep you updated.

Best,

Fengchao

[fcyu]

Hi @vspiceruofm , it seems that Mono in Ubuntu does not work will with Mac ARM CPU as host. For now, I think the easiest approach is converting the raw files to mzML format: https://fragpipe.nesvilab.org/docs/tutorial_convert.html

Best,

Fengchao

[vspiceruofm]

this saves me a lot of messing around, and it's good to know this is something fundamental. we also have a timsTOF; does the direct read that raw format also use mono?

thanks again, vic

[fcyu]

For timsTOF, the library does not use mono. It should work (let me know if it doesn't).

Just in case, it is not recommended to convert the timsTOF data to mzML format because it will loose some information and time consuming.

Best,

Fengchao

[vspiceruofm]

ok, i just tried a single ".d" folder on human with default.workflow-- i'm getting an error 137 from msfragger right after it does the initial index build, even though i have 64GB of RAM and pass "--ram 48" in the fragpipe arguments within the container run. i've tried the same on my linux box and msfragger doesn't fail this way, despite it having less physical ram (32 GB).

there is an mzBIN file it created; when i try the same command again, msfragger uses this then fails with an error 137 again.

am i missing something more obvious?

thanks again...

[fcyu]

Thanks for testing. Could you share the log file?

Thanks,

Fengchao

[vspiceruofm]

sure thing-- to get some more detail, running the msfragger element of the run sequence on its own (enclosed), it's reporting "killed" rather than "error 137". but it's managed to properly load the timstof file on the first pass...

thanks again, vic

fragger.params.txt tims-macm2-docker-fail-aug272024.txt

[fcyu]

Thanks for sharing the file. Could you get the return code by running echo $? right after MSFragger was killed?

Thanks,

Fengchao

[vspiceruofm]

ok yes, it's an error 137 again.

[fcyu]

I have a feeling that it was due to not enough memory. Could you try with the following

1. Set --ram 32gb or even smaller until it is killed not by the OS but by JVM (with a different error message) or runs successfully
2. Use a small .d
3. Set no variable modifications or missed cleavages in MSFragger params

Thanks,

Fengchao

[vspiceruofm]

ram down to 32G then 16G; variable ptms off; missed cleavages off: still error 137. haven't tried a smaller ".d" yet.

if rosetta2 and docker current versions just behave in this context, maybe i should shift to using the docker under linux?

thanks, vic

[fcyu]

Can you check the memory available to the docker contain by running lsmem or top?

Thanks,

Fengchao

[vspiceruofm]

aah--- now i see what's going on. despite passing "--memory=48g" on the "docker run" command, ps within the container shows it's only getting 8GB. when i look under the "resources" on docker desktop, it's controlling things-- and was limited to 8GB. this is different behaviour than its linux version...

and now msfragger is churning along.

thanks again! vic

[fcyu]

Thanks for the updates. It explains everything. Let me know if you have any other questions.

Best,

Fengchao