Random Crashes on Ubuntu 13

I’ve recently readied my game for steam, every platform seems rock solid, with a stable memory footprint on the task manager of only 65 mb an low cpu consumption.

Monogame (3.3 and 2.X) Latest repository version and an old 1 year version i use as “stable” have the same behaviour.
Monodevelop version is 5.7.
Mono version is 3.12

Still the game randomly crashes (only on Ubuntu, pc and mac are rock solid) with amd cpu and graphic card.
The error provided is always outside of monogame, but changes in nature
-before updating to latest mono and monodevelop the problem was an unidentificable sig-segv

Debug info from gdb:

ptrace: Operation not permitted.
No threads.

-now it goes deep into the disassembler, crashing outside of monogame inside libgdiplus

00000000   ldarg.0 
00000001   ldarg.2 
00000002   newarr System.Byte
00000007   stfld Mono.Debugger.Soft.FieldInfoMirror
0000000c   ldarg.0 
0000000d   ldfld Mono.Debugger.Soft.FieldInfoMirror
00000012   ldarg.0 
00000013   ldfld Mono.Debugger.Soft.FieldInfoMirror
00000018   ldc.i4.0 
00000019   ldarg.2 
0000001a   callvirt Int32 System.IO.Stream:Read (Byte[], Int32, Int32)
0000001f   stloc.0 
00000020   leave 0000002d
00000025   pop 
00000026   ldc.i4.m1 
00000027   stloc.1 
00000028   leave 0000006d
0000002d   ldloc.0 
0000002e   ldc.i4.0 
0000002f   ble 0000005d
00000034   ldarg.1 
00000035   ldsfld Mono.Debugger.Soft.FieldInfoMirror
0000003a   call Boolean System.IntPtr:op_Inequality (IntPtr, IntPtr)
0000003f   brfalse 0000005d
00000044   ldarg.0 
00000045   ldfld Mono.Debugger.Soft.FieldInfoMirror
0000004a   ldc.i4.0 
0000004b   ldarga.s 1
0000004d   call Int64 System.IntPtr:ToInt64 ()
00000052   call IntPtr System.IntPtr:op_Explicit (Int64)
00000057   ldloc.0 
00000058   call Void System.Runtime.InteropServices.Marshal:Copy (Byte[], Int32, IntPtr, Int32)
0000005d   ldarg.0 
0000005e   ldc.i4.0 
0000005f   stfld Mono.Debugger.Soft.FieldInfoMirror
00000064   ldarg.0 
00000065   ldloc.0 
00000066   stfld Mono.Debugger.Soft.FieldInfoMirror
0000006b   ldloc.0 
0000006c   ret 
0000006d   ldloc.1 
0000006e   ret 

System.Drawing.GDIPlus.GdiPlusStreamHelper.StreamGetHeaderImpl (buf=0xa3d3158, bufsz=1) in 

Anyone has similar issues ?

And as always people don’t say the important things in questions…

What is your monogame version?
Are you using mono kickstart (software to launch mono apps on mac and linux)?

I tested this on both my local copy and on the latest develop on github.
No, i get this error consistently on my build machine on debug and on release, not even close to using the mono-kickstart.

It seems like some library crash, it happens between 3 to 15 minutes into the game and without any consistency, menu, gameplay of any kind, anywhere. It seems like it doesn’t happen without user interaction, but i’m still having heavy tests on this.

My first guess would be either some os-interaction at the wrong moment, or a garbagecollection problem…

cra0zy do you know where i can find some help on how to use the mono kickstart ?

The readme file provides the information you need, just read it. Also post the full error, not just that small part of it.

Even running the game via Kickstart issues a similar error, no useful stacktrace, only seems to happen less often. Last time died on the ending of a (looping) Song, but that could be completely random (and it’s not repeatible)

As I stated before, post the full error. Also from the little I’ve seen you are doing something bad with threads, and yes, it’s probably an error in your code, mono is less tolerant than .net when it comes to threading.

Native stacktrace:

/usr/bin/mono() [0x80fdd53]
/usr/bin/mono() [0x806f4c9]
[0xb776d40c]
[0xb00d3008]

Debug info from gdb:

ptrace: Operation not permitted.
No threads.

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

This is the error i get after an automatic mono update.

Darn, i finally found the culprit!
The cause was loading png instead of xnb…
There seems to be a bug in the gdiplus dll that causes havock if png loading is used.