Yo Hal!
> Check out commit 99df9ac91a01a254ca19bbf72d1c2f0fe297d522
>
> It has code to print out the failed syscall #. At least on some OS.
> I'll see which fail and then blacklist them. So far it seems to work
> on all the buildbot workers. I can't believe that is right...
Have you looked at
Yo Hal!
Check out commit 99df9ac91a01a254ca19bbf72d1c2f0fe297d522
It has code to print out the failed syscall #. At least on some OS.
I'll see which fail and then blacklist them. So far it seems to work on
all the buildbot workers. I can't believe that is right...
Notice no need for backtrace(
Yo Hal!
On Wed, 31 May 2017 14:01:48 -0700
Hal Murray wrote:
> >> Can you try something like
> >> gdb
> >> print /a
>
> > Nope. We have LTO, ASR, and a bunch of other things making the
> > addresses not repeatable. Every time I intentionally crash ntpd at
> > the same spot the sta
>> Can you try something like
>> gdb
>> print /a
> Nope. We have LTO, ASR, and a bunch of other things making the addresses
> not repeatable. Every time I intentionally crash ntpd at the same spot the
> stack IPs are unique.
Can we do something like print out the address of main duri
Yo Hal!
On Wed, 31 May 2017 01:02:13 -0700
Hal Murray wrote:
> > I'm pretty sure we are not talking about the same thing.
>
> OK. Let me try again.
>
> Your hex numbers are useless unless we can turn them into some
> reference to the code.
Yup, that was my point.
> Can you try something l
> I'm pretty sure we are not talking about the same thing.
OK. Let me try again.
Your hex numbers are useless unless we can turn them into some reference to
the code.
Can you try something like
gdb
print /a
If that prints something useful, then we are on the right track.
-
Yo Hal!
On Wed, 31 May 2017 00:12:21 -0700
Hal Murray wrote:
> >> Is there a way to get gdb to turn them into symbols?
> > Nope, not with gdb.
>
> google says that print /a should do what I want.
>
> It seems to work for me, but my PCs are way smaller than your hex
> numbers.
I'm pretty
>> Is there a way to get gdb to turn them into symbols?
> Nope, not with gdb.
google says that print /a should do what I want.
It seems to work for me, but my PCs are way smaller than your hex numbers.
Please poke around a bit and see if you can get it to print anything sensible.
(gdb) print
Yo Hal!
On Tue, 30 May 2017 23:12:40 -0700
Hal Murray wrote:
> Gary said:
> > There was never a way to decode the addresses beyond that. Is that
> > any use? Any way to improve it so it has value?
>
> > #5 0x556b8bed9299 in ??
>
> I assume those are PCs.
Yes.
> Is there a way to get gd
Gary said:
> There was never a way to decode the addresses beyond that. Is that any use?
> Any way to improve it so it has value?
Thanks.
> #0 0x556b8bf1d76f in ??
> #1 0x556b8bf1d65a in ??
> #2 0x556b8beecf8f in ??
> #3 0x556b8beed060 in ??
> #4 0x7f81ca395720 in ??
> #5 0x556b8bed9299 in ??
Yo Hal!
By jamming a number of #defines the hard way, I get libisc backtrace
to do what it is supposed to do:
../../ntpd/ntpd.c:930: REQUIRE(1 == 2) failed, back trace
#0 0x556b8bf1d76f in ??
#1 0x556b8bf1d65a in ??
#2 0x556b8beecf8f in ??
#3 0x556b8beed060 in ??
#4 0x7f81ca395720 in ??
#5 0x556b
Yo Hal!
On Tue, 30 May 2017 16:44:48 -0700
Hal Murray wrote:
> gdb doesn't work when ntpd is started automatically at boot time.
OK.
> strace solved that one.
Yes, we keep coming back to strace.
> There is another problem in this area. That's translating a stack
> trace in the middle of lib
> I'll be seeing if even that works, and if it works, how it compares to gdb
> backtrace.
gdb doesn't work when ntpd is started automatically at boot time. That's
interesting because, at least on my laptop, wifi doesn't get started until
after ntpd is running. That tested a code path I never
Yo Mark!
On Tue, 30 May 2017 21:31:59 +
Mark Atwood wrote:
> I remain a fan of ripping out unused and useless code.
Good. First I'll be sure it is truly useless. So far iI see it
only tries to work on x86 and i386 cpus, with a srtong preference
for gcc.
I'll be seeing if even that works,
I remain a fan of ripping out unused and useless code.
As you remove stuff, do please keep each conceptual chunk of removal in
it's own well defined git commit.
..m
On Fri, May 26, 2017 at 9:12 PM Gary E. Miller via devel
wrote:
> Yo All!
>
> I see a lot of libisc code that I'm not sure NTPsec
> So, you want me to save a tool you have never used? I guess next week I'll
> see if it even works. Or has any use.
It's not so much that I want to save it, but please don't throw it out until
somebody has taken time to see if it is useful and/or find a better way.
--
These are my opinion
Yo Hal!
On Sat, 27 May 2017 18:18:50 -0700
Hal Murray wrote:
> > Have you ever enabled, and used ISC_PLATFORM_USEBACKTRACE?
>
> No. That never got to the top of my list.
So, you want me to save a tool you have never used? I guess next week
I'll see if it even works. Or has any use.
RGDS
> Have you ever enabled, and used ISC_PLATFORM_USEBACKTRACE?
No. That never got to the top of my list.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Yo Hal!
On Sat, 27 May 2017 13:39:09 -0700
Hal Murray wrote:
> > Do all you need is a good way to debug the never ending seccomp
> > issues?
>
> Correct.
OK, I agree that is a problem that needs work.. I do not how
ISC_PLATFORM_USEBACKTRACE applies to that problem at all.
Have you ever en
> Do all you need is a good way to debug the never ending seccomp issues?
Correct.
The case I worry about is a once-a-week bug on a busy server.
seccomp is Linux-only so whatever solution(s) we come up with doesn't need to
be POSIX. Cross platform would be nice, but I'll take whatever I can
Yo Hal!
On Fri, 26 May 2017 21:23:35 -0700
Hal Murray wrote:
> > Anyone care?
>
> Yes.
Have you ever used it? Have you used it recentlly? Does it even work?
> If we are serious about seccomp, we need something like that in order
> to debug the false positives.
How would ISC_PLATFORM_USEB
> Anyone care?
Yes.
If we are serious about seccomp, we need something like that in order to
debug the false positives.
Please don't rip it out until we have a good alternative.
--
These are my opinions. I hate spam.
___
devel mailing list
deve
22 matches
Mail list logo