Repetier crashes after 2 minutes

Hi,

Everyone knows that the MONO problem in Ubuntu is resolvable?

This bug will be fix in next RH version??

Comments

  • All we know is that it appeared with the latest mono update. So chances are high that it could be also a mono problem. Always hard to work around all bugs, but we will at least test it and see if we find a solution.
  • It's been a couple of weeks now - did you guys get a chance to look at it?
  • No, still developing the next release. Then we can check linux, but it's not save we have the same libraries and can rebuild the errors. After all it came with updated mono/ubuntu stuff and hasn't been there before. But let's hope the best.
  • I'm having the same issue- crashes soon after starting a print job. 

    Ubuntu 14.04
    RepetierHost 1.0.6
  • Is there a way to downgrade or remove the mono update to get it working again?

    I just set up ubuntu 14.04 on an old pc just to use repetier-host and am a bit new to linux.

    Any help would be appreciated 
  • Anyone tried a fresh install of Repetier-Host to see if that solves the issue?
  • A fresh host installation will not help. The guess is that some dependent libraries have changed causing the problem in combination.

    If you start it from command line, are there any hints on where the crash occurs in backtrace?
  • Captured this earlier today as part or the crash. More info (the full crashlog) is available if desired. Potentially the stack size needs to be increased.
    ProblemType: Crash
    Architecture: amd64
    CrashCounter: 1
    CurrentDesktop: Unity
    Date: Sat Apr 18 10:55:20 2015
    DistroRelease: Ubuntu 14.04
    ExecutablePath: /usr/bin/mono-sgen
    ExecutableTimestamp: 1426882905
    ProcCmdline: mono RepetierHost.exe -home
    7fa811988000-7fa8119c4000 r-xp 00000000 08:07 426310                     /usr/lib/libMonoPosixHelper.so
     7fa8119c4000-7fa811bc3000 ---p 0003c000 08:07 426310                     /usr/lib/libMonoPosixHelper.so
     7fa811bc3000-7fa811bc4000 r--p 0003b000 08:07 426310                     /usr/lib/libMonoPosixHelper.so
     7fa811bc4000-7fa811bc5000 rw-p 0003c000 08:07 426310                     /usr/lib/libMonoPosixHelper.so
    InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
    Package: mono-runtime-sgen 3.2.8+dfsg-4ubuntu1.1
    PackageArchitecture: amd64
    ProcVersionSignature: Ubuntu 3.13.0-49.83-generic 3.13.11-ckt17
    SegvAnalysis:
     Segfault happened at: 0x7fa834cf8688:    cmpb   $0x48,(%rdx)
     PC (0x7fa834cf8688) ok
     source "$0x48" ok
     destination "(%rdx)" (0x7fa8368e23) not located in a known VMA region (needed writable region)!
     Stack memory exhausted (SP below stack segment)
    SegvReason: writing unknown VMA
    SourcePackage: mono
    Stacktrace:
     #0  0x00007fa834cf8688 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
     No symbol table info available.
     #1  0x00007fa834cf96f8 in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1
     No symbol table info available.
     #2  0x00007fa84877de26 in __GI___backtrace (array=array@entry=0x7fa8494841a0, size=size@entry=256) at ../sysdeps/x86_64/backtrace.c:109
             arg = {array = 0x7fa8494841a0, cfa = 140360760707776, cnt = 4, size = 256}
             once = 2
     #3  0x00000000004b73d8 in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0x7fa849484ac0) at mini-exceptions.c:2268
             array = {0x4b73d8 <mono_handle_native_sigsegv+200>, 0x50f13b <mono_arch_handle_altstack_exception+187>, 0x423d22 <mono_sigsegv_signal_handler+242>, 0x7fa848a48340 <__restore_rt>, 0x0 <repeats 227 times>, 0x5a6fb3 <jit_info_table_chunk_index+83>, 0x0, 0x7fa84950d048, 0x7fa8368e23, 0x149, 0x5ab0a00, 0x1, 0x7fa84738bc48, 0x5a7070 <jit_info_table_find+112>, 0x0, 0x15800000000, 0x0, 0x7fa84950d048, 0x27872d0, 0x7fa8368e23, 0x27872d0, 0x1, 0x7fa84738bc48, 0x5a7da0 <mono_jit_info_table_find_internal+64>, 0x0, 0x27872d0, 0x0, 0x7fa8368e23, 0x7fa845fd02e0, 0x4b45e5 <mini_jit_info_table_find+101>}
             names = <optimized out>
             i = <optimized out>
             size = <optimized out>
             sa = {__sigaction_handler = {sa_handler = 0x4b73d8 <mono_handle_native_sigsegv+200>, sa_sigaction = 0x4b73d8 <mono_handle_native_sigsegv+200>}, sa_mask = {__val = {5304635, 4341026, 140360749974336, 0 <repeats 13 times>}}, sa_flags = 0, sa_restorer = 0x0}
             jit_tls = 0x7fa82c0021f0
             signal_str = 0x655436 "SIGSEGV"
     #4  0x000000000050f13b in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7fa849484ac0, fault_addr=<optimized out>, stack_ovf=stack_ovf@entry=0) at exceptions-amd64.c:908
             exc = <optimized out>
             ctx = 0x7fa849484ac0
             ji = 0x0
             sp = <optimized out>
             frame_size = <optimized out>
             copied_ctx = <optimized out>
     #5  0x0000000000423d22 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fa849484bf0, context=0x7fa849484ac0) at mini.c:6769
             ji = 0x0
             jit_tls = 0x7fa82c0021f0
             fault_addr = <optimized out>
             ctx = 0x7fa849484ac0
     #6  <signal handler called>
     No locals.
     #7  0x0000007fa8368e23 in ?? ()
     No symbol table info available.
     #8  0x0000000041295113 in ?? ()
     No symbol table info available.
     #9  0x0000000000000000 in ?? ()
     No symbol table info available.
  • That is a crash of mono itself caused by out of memory state. Can you see ram usage in top before it crashes. Especially of interest is if ram usage starts growing fast while printing. A slow increase is ok as it draws more and more triangles hold in memory. I'm not sure how mono memory management works in detail. In host you can send @memory in command line and you get real memory usage in log window. @memory does a garbage collection and then reports the free memory.

    What we need to know is if your Model/print is simply too large for the PC or if there is a memory leak using more and more memory (which should be prevented by monos mark and sweep garbage collection).
  • Tried it again. Unfortunately, no evidence of a memory leak. From top, mono started at 4.7 while idle and increased to 5.1 while printing. From @memory, it started at 27568424 (27.5M) while idle, then to 29M at the beginning of printing. It increased to a high of 29.5M and then dropped to 29.3M at the beginning of layer 4. It crashed right after that, leaving no files that I could find. The print is just a 10-20-40mm test structure that I have printed many times on the printer.

  • Given all the reports it seems safe to assume we're having the same issue, and I'm crashing printing a 1cm test cube, so don't think model size is the issue.  ;-p
  • Been running Win 8 to get prints done :( , but checked in Ubuntu this morning, Numerous kernel updates. Installed all and tried again. go about 80% of the way through a 10mmx10mmx10mm cube and the application crashed. No logs, but here is the terminal output:
    ~/Documents/RepetierHost$ Rebuild object False
    Stacktrace:


    Native stacktrace:

        mono() [0x4b73d8]
        mono() [0x50f13b]
        mono() [0x423d22]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f66067d8340]
        mono() [0x5aef5a]
        [0x41407189]

    Debug info from gdb:

    Could not attach to process.  If your uid matches the uid of the target
    process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
    again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
    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.
    =================================================================

    Tried running as root, and it went down right away:
     Rebuild object False
    Opening serial failed on second try:System.IO.IOException: No such file or directory
      at System.IO.Ports.SerialPortStream.ThrowIOException () [0x00000] in <filename unknown>:0
      at System.IO.Ports.SerialPortStream..ctor (System.String portName, Int32 baudRate, Int32 dataBits, Parity parity, StopBits stopBits, Boolean dtrEnable, Boolean rtsEnable, Handshake handshake, Int32 readTimeout, Int32 writeTimeout, Int32 readBufferSize, Int32 writeBufferSize) [0x00000] in <filename unknown>:0
      at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPortStream:.ctor (string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
      at System.IO.Ports.SerialPort.Open () [0x00000] in <filename unknown>:0
      at RepetierHost.model.ProtectedSerialPort.Open () [0x00000] in <filename unknown>:0
      at (wrapper remoting-invoke-with-check) RepetierHost.model.ProtectedSerialPort:Open ()
      at RepetierHost.connector.SerialConnector.Connect () [0x00000] in <filename unknown>:0

    Unhandled Exception:
    System.IO.IOException: Bad file descriptor
      at System.IO.Ports.SerialPortStream.ThrowIOException () [0x00000] in <filename unknown>:0
      at System.IO.Ports.SerialPortStream.Dispose (Boolean disposing) [0x00000] in <filename unknown>:0
      at System.IO.Ports.SerialPortStream.Finalize () [0x00000] in <filename unknown>:0

  • In this thread http://forum.repetier.com/discussion/397/rh-started-crashing-after-10-minutes#latest a user found resources showing that you need kernel 3.13.046 to work. Some googling showed that after that some kernal changes seem to have side effects. I do not understand this kernel stuff so can not say what might be all possible crash reasons.

    What you show is more a failed connection as it looks like the serial device could not be found during connection.
  • Bonjour,
    I have the same troubleschouting when i tried to load a gcode file to the sd card.
    After only changing by linux 3.13.046 in place of 3.13.052 no problem to download the same gcode file.

    A suivre ! to folow! merci Alain

Sign In or Register to comment.