Generally, when a NA is received we check if the receiving interface
has the target address advertised and if it's the case we warn about
duplicate addresses and bail.
But in the case of a carp interface in BACKUP state it's different. In
this case we have a hack that sets the ifa to NULL and con
On Tue, 18 Feb 2014 18:49:21 -0700, Theo de Raadt wrote:
> The *.y file is the source code. the .c and .h files it generates are not
> the source code, but an intermediate language.
>
> To stetch this to the limit, we should be shipping cpp-processed files, for
> maximum portability.
>
> NO WAY
"gdb" (gdb 6.3) knows about threads but core dumps half the time
and is 10 years old.
"egdb" (gdb 7.6) does not work right with multithreaded programs. It
sees only one thread.
Neither supports "set scheduler-locking".
Is there any good option for debugging a multithreaded program?
I'm runnin
>It's basically impossible to support something when the actual code
>being compiled varies drastically from system to system.
It is socially irresponsible to provide something like sudo or ssh for
systems that old and fundamentally vulnerable, without any updates or
any security at all.
You are
On Wed, Feb 19, 2014 at 17:28, John Carr wrote:
>
> "gdb" (gdb 6.3) knows about threads but core dumps half the time
> and is 10 years old.
>
> "egdb" (gdb 7.6) does not work right with multithreaded programs. It
> sees only one thread.
>
> Neither supports "set scheduler-locking".
>
> Is ther
> From: "Todd C. Miller"
> Date: Tue, 18 Feb 2014 14:50:53 -0700
>
> On Tue, 18 Feb 2014 16:38:07 -0500, Ted Unangst wrote:
>
> > True, I phrased that poorly. What I'm assuming is that the code will
> > be built by a compiler that supports the const keyword. Or in other
> > words, if you're usin
> Date: Wed, 19 Feb 2014 17:28:24 -0500
> From: John Carr
>
> "gdb" (gdb 6.3) knows about threads but core dumps half the time
> and is 10 years old.
>
> "egdb" (gdb 7.6) does not work right with multithreaded programs. It
> sees only one thread.
I'm still planning to merge the changes for pro
> > Is there any good option for debugging a multithreaded program?
>
> By defenition there isn't. Anything you do will affect the timing of
> your program. If you want debugability, avoid threads.
Race-free parallel programming is an active area of research. I can't
accept your definition be
On Sun, Feb 9, 2014, at 13:56, Fabian Raetz wrote:
> On Sun, Feb 09, 2014 at 09:32:15PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 9 Feb 2014 14:23:18 +0100
> > > From: Fabian Raetz
> > > >
> > > > Hmm, my cleanup was based on the version you send out on December
> > > > 31st. Can you send me
