Re: Ctrl-C strangeness -> SEGFault

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> Moin!
>
> Whenever I stop monit with Ctrl-C in the console it throws a SEGF like
> this...
>
> (...)
> 'inetd' is running with pid 1343
> 'inetd' zombie check passed [status_flag=0000]
> 'inetd' check_process_state() passed.
> 'ssh' is running with pid 1608
> 'ssh' zombie check passed [status_flag=0000]
> 'ssh' check_process_state() passed.
> Stopping monit HTTP server
> monit daemon with pid [3740] killed
> Stopping monit HTTP server
> monit daemon with pid [3742] killed
> Segmentation fault
> Exit 139
> (address@hidden) ~/compile/monit/monit>
>
> When I send an SIG[INT|QUIT|TERM|KILL] to the first monit or all
> everything is fine an monit stops without any complaining.
>
> A second ago I played a bit... if you kill just the 1st and the 3rd
> process of monit with signal 2 (INT) then it does the behavior above.
> Efence doesn't even care about it (samebehavior with or without)!  I
> can not reproduce it in gdb.... gdb does of course signal handling.
>
> Any ideas...?

I think I may have a clue about what is going on. You see, I also got
SIGSEGV the first time I implemented catching SIGINT when I pushed
CTRL^C. This always occurred when the program control was in the
do_validate loop.

Signals are asynchronous and we also use threads to complicate matters
further. 

Upon receiving the SIGINT signal the signal handler, do_destroy,
starts cleaning up (freeing memory) and finally calls exit(), at the
same time the program control jumps back to do_validate and tries to
continue the work there before it realize the program was stopped and
it finds that the data structure it is working on has been freed and
thus has no option but to throw SIGSEGV. Gurgle! I solved this problem
by adding a SIGINT block at the start of the do_validate function,
after that, no more SIGSEGV.

There are a couple of other places this same phenomena may occur. It
will typically occure when a "thigh" loop is executed in the program.

The alert.c code has such a loop when sending mail. If you pressed
CTRL^C when the program was in the sendmail loop SIGSEGV may occur,
also the state.c function has a loop for reading or writing data to
the state file and if SIGINT was pressed in the middle of the
write/read loop SIGSEGV may also occur. These are the two places I can
think of that may result in the SIGSEGV you experience. 

Anyway, I have added a collective signal guard block in alert.c and in
state.c now, does this help?

Ps. I cannot reproduce this SIGSEGV on my Linux but that does not have
to mean anything since your monitrc file may run monit differently.

-- 
Jan-Henrik Haukeland