Mark Scott wrote:
> Seems I spoke too soon. While the segfault was prevented in test mode
> by applying Paul's patch, one occurred at a different place when not
> running in test mode. The backtrace doesn't look that helpful -
> presumably the ?? in non-radioclkd code indicates library calls for
On Mon, 2007-10-29 at 00:24 +, Paul Martin wrote:
> On Sun, Oct 28, 2007 at 10:07:59PM +, Mark Scott wrote:
> > I have a home-built radio clock receiver for the DCF77 time signal
> > that has been working fine for a year while attached to an i386
> > machine. I moved it to an amd64 machine
Paul Martin wrote:
> On Sun, Oct 28, 2007 at 10:07:59PM +, Mark Scott wrote:
>> I have a home-built radio clock receiver for the DCF77 time signal
>> that has been working fine for a year while attached to an i386
>> machine. I moved it to an amd64 machine and find that radioclkd
>> segfaults
[EMAIL PROTECTED] said:
> The problem is that the KILL(2) call is used to check to see if a process
> exists at the specified PID. The default action for SIGUSR1 is to kill the
> targeted process. Thus the original process dies, and the new process exits.
>
> The propper thing to do is to use kill
[EMAIL PROTECTED] said:
> It is obvious that the way the program is behaving the bug report is they it
> is programmed to behave. I would like to know if there is a better way to
> handle this.
It is a bogus bug report, and probably stems from a lack of understanding
of exactly what hotkey does
5 matches
Mail list logo