Got a SIGABRT while executing native code - error when running xsp4 on AWS during Cloudformation

Question

I'm getting an error when starting the xsp4 server on an AWS Ubuntu AMI. The error is initialize: mono_thread_create_internal () failed, and then:

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.

The same command executes without errors on my own computer. Any idea what the error is - maybe a missing package, some configuration or something like that?

Edit: Huh, that's weird, it's working when I log in via ssh and manually run the command. I need to run it during CloudFormation however, and it fails there. Maybe something isn't fully setup yet during CloudFormation, or the user account is different? But on second thought, doesn't CloudFormation run as root?

Full log:

+ xsp4 --port 80
Cloud-init v. 0.7.9 running 'modules:final' at Sun, 22 Oct 2017 17:18:30 +0000. Up 12.78 seconds.
Cloud-init v. 0.7.9 finished at Sun, 22 Oct 2017 17:19:27 +0000. Datasource DataSourceEc2.  Up 69.50 seconds
xsp4
Listening on address: 0.0.0.0
Root directory: /var/www/HelloWebApi
Listening on port: 80 (non-secure)
Hit Return to stop the server.
The server is not started.
  at Mono.WebServer.ApplicationServer.Stop ()  in :0 
  at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer:Stop ()
  at Mono.WebServer.XSP.Server.DebugMain (System.String[] args, Boolean root, IApplicationHost ext_apphost, Boolean quiet)  in :0 
initialize: mono_thread_create_internal () failed
Stacktrace:

  at  
  at (wrapper managed-to-native) System.Net.Sockets.Socket.socket_pool_queue (System.Net.Sockets.SocketAsyncCallback,System.Net.Sockets.SocketAsyncResult) 
  at System.Net.Sockets.Socket.QueueSocketAsyncResult (System.Collections.Generic.Queue`1,System.Net.Sockets.SocketAsyncWorker,System.Net.Sockets.SocketAsyncResult) 
  at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs) 
  at Mono.WebServer.ApplicationServer.RunServer () 
  at System.Threading.ThreadHelper.ThreadStart_Context (object) 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) 
  at System.Threading.ThreadHelper.ThreadStart () 
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 

Native stacktrace:

        /usr/bin/mono() [0x49ff2f]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390) [0x7f39c549b390]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7f39c50f5428]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f39c50f702a]
        /usr/bin/mono() [0x630409]
        /usr/bin/mono() [0x63069c]
        /usr/bin/mono() [0x63076f]
        /usr/bin/mono() [0x58e6e5]
        [0x4044ec36]

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

I think this may have to do with a missing PTY/TTY in your case. — Tarun Lalwani, Oct 29 '17 at 11:47
Thanks! This gave me the idea to look at xsp4's args, and using `--nonstop` fixed the error - this arg prevents the server from waiting for the Enter key to exit, where it prints "Hit Return to stop the server.". Can you post that as answer, so I can award the bounty? — sashoalm, Oct 29 '17 at 12:05

score 1 · Accepted Answer · answered Oct 29 '17 at 12:14

If it works after SSH and not directly they most probably it is a TTY missing issue. If your server requires TTY then it won't start this way

As you mentioned in your response that xsp4 waits for enter key to exit and take --nonstop if you don't want the behavior, then you should use that arg. It will make sure the TTY is not required.

In case if a executable actually still requires TTY then you can look at the script command. Which does allocate a TTY and execute the command. See below for more details

http://man7.org/linux/man-pages/man1/script.1.html

Got a SIGABRT while executing native code - error when running xsp4 on AWS during Cloudformation

Full log:

1 Answers1