Re: SIGSEGV problem

[Jan-Henrik Haukeland]

I will try to look into it tomorrow and see if I can reproduce it.
This seems like a standard memory bug, probably from using freed
memory. It's typical hard to locate and SIGSEGV may occur on different
places or not at all.

Anyway, I really recommend these two tools to track down this kind of
bugs:

ftp://ftp.perens.com/pub/ElectricFence/
http://developer.kde.org/~sewardj/

Electric Fence is particularly good for finding the exact place in the
code where the memory fault is located.

Martin Pala <address@hidden> writes:

> Hi,
>
> during tests occasionaly one of monit threads receives SIGSEGV. It
> happens in the case, that the monitored process is not running.
>
> the path to the SIGSEGV is as follows:
>
> 1.) we're waiting for process to start in main thread after spawning
> process start method:
> ...
> thread is status= pthread_create(&thread, NULL, wait_start, s);
> ...
>
> 2.) in new thread (in wait_start) we detach and looking for process to
> start or timeout:
> ...
> if(is_process_running(s))
> break;
> ...
>
> 3.) the thread crashed rigth after first call of is_process_running(s)
> -> get_pid(s->path) -> exist_file(char *file) -> stat(file, &buf) -
> see strace output for complete trace:
> ...
> 3788 stat64("XE^^G^H/run/slapd.pid", <unfinished ...>
> ...
>
>
> As you can see, it seems that the pidfile path pointer points to
> strange place.
>
> This problem happens very occasionaly (cca 5% of test attempts failed
> on this error - others were OK).
>
> I tried to include some debug tags to trace it - something like
> fprintf(stderr, "mark1"); etc., but as soon as i did it, i was not
> able to replicate the problem at all. I tied it many times again with
> and without these tags and the result was the same - with tags it
> worked well, without tags it failed => probably there is some race
> condition, maybe outside monit (in libs).
>
> Any ideas?
>
> Martin

-- 
Jan-Henrik Haukeland