Process killed on ccgi

[#1]

I have a binary of a CGI I would like to run however when run on ccgi it dies by receiving a SIGKILL straight after starting.  Are there some odd rules applied to kill off processes for safety?
On my machine at home, a bit of the strace looks like this:
close(4)                                = 0
munmap(0xb7fc8000, 4096)                = 0
time([1205715818])                      = 1205715818
gettimeofday({1205715818, 70243}, {0, 0}) = 0
gettimeofday({1205715818, 96445}, {0, 0}) = 0
On ccgi, the same bit is:
close(4)                                = 0
munmap(0x57413000, 4096)                = 0
+++ killed by SIGKILL +++
Ie there isn't any memory allocated or much odd going on at that time.  Ideas anyone?
Thanks,
epitrope.

[#2]

Hmm I'm not certain of this one,
I've had similar SIG_IOT Traps on Linux Running Games ... and games randomly ending for this same reason.
I assume its sume kind of limitation or some condition triggering it.
It depends if this needs to output into your Console. If it's something you intend running in the background...

#!/bin/sh
screen -dmS username /path/to/bin

Although, it probbably wont help... 😕
Jim,

[#3]

Is this cgi script run via the web server (i.e. in creates a web page or does something related to your website) or is it something you want to be running all the time i.e. a background service. If the latter then this is not allowed

[#4]

It's a process that runs as part of a CGI script and completes in usually less than 1 second (ie it's not a background process).  It didn't work when running as a cgi so I've just been running it interactively on ccgi to try and work out why! 
Thanks in advance for any help you can offer,
epitrope.

[#5]

I would be inclined to check it Source code.
(I am assuming it's compiled either by yourself or pre-compiled for a certain architecture).
Although it is still possibly restrictions set down on the CCGI Servers...
If you have Source or the Name of the program (if precompiled) for it,
we might be able to find a similar solution that will work on the CCGI Server.
Jim,

[#6]

Thanks for the offer but to complicate matters, it's a Modula-3 program so it's non-trivial to compile.  Is there a list of the ccgi restrictions somewhere that I can check against (or simulate on my home machine)?
Thanks,
epitrope.

[#7]

I've done a bit more debugging and discovered that ccgi seems to convert SIGSEGV signals into SIGKILL.  SIGSEGV is used to drive the Modula-3 garbage collector and hence it may not be easy to run Modula-3 programs on ccgi. 
Is there anyway of changing ccgi's behaviour on this front?
Thanks,
epitrope.

[#8]

SIGSEGV is generated when the program crashes (often due to accessing illegal memory location) so if you are getting that then there is a problem with the program. When a SIGSEGV is generated the normal action by Unix is to terminate the program as it is unable to continue (hence why you think it is the same as a SIGKILL).
So there is a problem with that binary running on the ccgi and is probably a library (shared object) or static library conflict or a coding error in the original program.
You cannot change this behaviour as it is core to a Unix environment.
I'm surprised that Modula-3 uses that signal as it is often fatal to an application when it occurs.

[#9]

My understanding of Modula-3 is that it sets memory protection flags so that the runtime (garbage collector) can receive information about memory use via SIGSEGV.  It traps this signal and then carries on running.  This is perfectly normal behaviour for Modula-3.
However unfortunately rather than getting the trappable signal SIGSEGV it is instead getting the non-trappable SIGKILL.  Another possibility, is there something on ccgi to stop processes fiddling with VM page attributes?
The binary I'm using is a static binary so there should be no library conflicts going on.  I've also used the binary on a variety of vanilla Linux kernels so I'm not imagining a problem there.
Thanks,
epitrope.

[#10]

I believe the ccgi servers run Debian AND run applications within a protected VM environment so the Modula-3 code may well be doing something with memory that is not allowed this being forced to kill it.

[#11]

I'm not sure if it's related, but after a quick google it seems to be caused by a problem with the vserver software we use on the CGI platform to separate the vISPs.
e.g. http://www.paul.sladen.org/vserver/archives/200710/0040.html
Unfortunately with the way the platform is at the moment it would be a massive piece of work fixing this (assuming vserver has released a fix for this which I'm not even sure of) so it is unlikely to be done on the current platform. As Mike Grice has said in another post in this forum a while back, we've not been giving much love to CGI at the moment but it is something we are keen to get sorted out.