e...@thyrsus.com said:
> It's like a symbolic debugger that keeps an execution trace and lets you
> step backwards in time. Under rr you could induce the crash, then step back
> to the last syscall.
I don't think that's going to help. I'm in a signal handler from the current
attempted syscall.
Hal Murray :
> > Seems like a situation made for investigating with Mozilla rr.
>
> Could you please say a bit more? I don't know anything about Mozilla rr.
> Why is that likely to help me in this case?
It's like a symbolic debugger that keeps an execution trace and lets you
step backwards in
> Seems like a situation made for investigating with Mozilla rr.
Could you please say a bit more? I don't know anything about Mozilla rr.
Why is that likely to help me in this case?
I think I have tracked down the problem. It's trying to start a new thread.
The clone syscall wasn't on the
Hal Murray :
> I'm working on segcomp. I'm at the stage where things mostly work and I'm
> trying to find obscure code paths that use a syscall that isn't yet on the OK
> list.
>
> The SIGSYS means it tried to call something that wasn't on the list.
> Normally, a simple backtrace will let me
I'm working on segcomp. I'm at the stage where things mostly work and I'm
trying to find obscure code paths that use a syscall that isn't yet on the OK
list.
The SIGSYS means it tried to call something that wasn't on the list.
Normally, a simple backtrace will let me can figure out what it is
Hello Caeley and David and welcome to the discussion,
Truly some good stuff here! With a mature SDLC and leveraging highly skilled
volunteers, I think NTPsec is well on the way to its badge.
Being a Synopsys sales engineer (shill), I am pleased to see Coverity listed in
the CII Best
Hello Caeley and David,
Thank you for your offer to help the NTPsec Project improve our CII
Badge score.
Yes, we would appreciate your help.
As you may know, the NTPsec Project's website is at http://ntpsec.org/
and contains links to the project documentation, and links to our GitLab
org acco
