3

More or less the subject explains the question. I'm building a web application with C++ and Wt. Of course I'm trying to be particularly careful with things that can cause a segfault, but it might happen. Wt creates a separate thread for every user opening a session. My worst fear is, specifically, that a malicious user finds a bug, which for example produces a segfault, and manages to exploit it, making the whole application crash at whim.

The preferred behaviour instead would be that I can "catch" the signal (yes, I know segfault isn't an exception, this is why I've used the quotes), kill the thread which produced it, maybe, if possible, freeing the memory it allocated and then keep the application running for the other users.

Is it possibile?

Thanks.

DrHell
  • 461
  • 3
  • 17
  • This might help: http://stackoverflow.com/questions/2663456/how-to-write-a-signal-handler-to-catch-sigsegv – tkausl Jun 26 '16 at 13:45
  • Do not even try to keep a process alive after a critical (disastrous) failure, let it die early. However, you might be able to split your application into multiple processes, to keep critical failures local. –  Jun 26 '16 at 14:18
  • @DieterLücking: Thanks. I know, this is far away from being a perfect solution, but I'm trying to reach the same behaviour I see in php servers, where, if something goes bad, the user is kicked out, but the server goes on. It's true that in php servers this seems to happen with errors that in C++ are "compiler errors", but the idea that a single user can crash the whole server annoys me to no end. Should I move the application to Java while it is only built for 1/10? Would it help with this specifical problem? (It would be a pain to move to Java... but I might think about it, if it is worth). – DrHell Jun 26 '16 at 16:16
  • @tkausl: Thanks, it clarifies a bit what can be and cannot be done within a handler. But, as in the comment I wrote in reply to Shiro, I suspect that "signal" doesn't work at all in a multi-threaded program. – DrHell Jun 26 '16 at 16:20
  • `Thread`s share `Virtual Memory` of `Process`. So even if one `Thread` misbehaves then there is chance that `Virtual Memory` will get corrupted, etc. So better to use a `Process` for each `Session` if there is danger of program/application misbehaving. – sameerkn Jul 25 '16 at 08:55

2 Answers2

1

Yes it is possible to write a handler for SIGSEGV. That way you can specify what will happen.

signal(SIGSEGV, sighandler); 

void sighandler(int signum)

{
    printf("Process %d got signal %d\n", getpid(), signum);
    kill(getpid(), signum);
}
Shiro
  • 2,610
  • 2
  • 20
  • 36
  • Thanks for the idea. I tried both with raise(SIGSEGV) and dereferencing a null pointer. The handler is called only as long as the signal is generated withing the main process, for example in "main" function. If I try to do the same within a function called by a thread, the handler is ignored. Specifically, the raise has no effect at all, derefrencing a null pointer crashes the program without calling the handler. Maybe it is related to this: "Undefined: calling this function in a multi-threaded program causes undefined behavior." (source: http://www.cplusplus.com/reference/csignal/signal/) – DrHell Jun 26 '16 at 16:01
1

There's a possibility to side-step this issue, by specifying a session management configuration option. As such you can assign each session to a separate process, which would crash on segfault, but it would not impact other sessions.

Detail remark: Wt doesn't really create a thread for each session, it uses a pool of threads to schedule work on.

user52875
  • 3,020
  • 22
  • 21