Re: CVS commit: src/tests/lib/libc/sys

[Robert Elz]

Date:Mon, 1 Aug 2022 18:55:15 +0300
From:Valery Ushakov 
Message-ID:  

  | The test uses __clone(), not clone() and a followup fix made __clone()
  | visible under plain _NETBSD_SOURCE again - which is the right thing,
  | IMO.  So this change is not necessary (the test only uses __clone()).

Yes, I saw, but the test really should be using clone() - that"s
the thing which needs to work (for those odd apps which use it).

kre

Re: CVS commit: src/tests/lib/libc/sys

[Valery Ushakov]

On Mon, Aug 01, 2022 at 15:48:40 +, Robert Elz wrote:

> Module Name:  src
> Committed By: kre
> Date: Mon Aug  1 15:48:40 UTC 2022
> 
> Modified Files:
>   src/tests/lib/libc/sys: Makefile
> 
> Log Message:
> Provide _GNU_SOURCE for t_clone now that is required to make clone()
> visible.

The test uses __clone(), not clone() and a followup fix made __clone()
visible under plain _NETBSD_SOURCE again - which is the right thing,
IMO.  So this change is not necessary (the test only uses __clone()).

-uwe

Re: CVS commit: src/tests/lib/libc/sys

[Rin Okuyama]

Committed. Thank you for your comment!

rin

On 2020/06/22 20:09, Kamil Rytarowski wrote:

On 22.06.2020 04:51, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Mon Jun 22 02:51:07 UTC 2020

Modified Files:
src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_wait.h

Log Message:
Turn trigger_fpe() back to integer division by zero for a while
until QEMU bug #1668041 is fixed:

https://bugs.launchpad.net/qemu/+bug/1668041

by which floating-point division by zero is not trapped correctly
both on amd64 and i386.

Skip *_crash_fpe tests on powerpc, where integer division by zero
is never trapped.




The intention of this test is just detecting SIGFPE. If the si_code
value is various on different architectures (like one traps on integers
other one on floats), we shall just drop the asserts for si_code and
adapt the trigger_fpe() function to cover promptly more ports.

The qemu bug should be fixed nonetheless.

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 22.06.2020 04:51, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Mon Jun 22 02:51:07 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_wait.h
> 
> Log Message:
> Turn trigger_fpe() back to integer division by zero for a while
> until QEMU bug #1668041 is fixed:
> 
> https://bugs.launchpad.net/qemu/+bug/1668041
> 
> by which floating-point division by zero is not trapped correctly
> both on amd64 and i386.
> 
> Skip *_crash_fpe tests on powerpc, where integer division by zero
> is never trapped.
> 


The intention of this test is just detecting SIGFPE. If the si_code
value is various on different architectures (like one traps on integers
other one on floats), we shall just drop the asserts for si_code and
adapt the trigger_fpe() function to cover promptly more ports.

The qemu bug should be fixed nonetheless.




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Rin Okuyama]

On 2020/06/17 17:42, Rin Okuyama wrote:

Now, all *_crash_fpe tests pass for powerpc, and nothing changes for amd64
at least.


Here, powerpc means powerpc/oea, more specifically Mac mini G4.

At the moment, fenv.h doesn't work correctly on booke and ibm4xx, where FPU
is emulated in software. For some processors of oea, m[ft]msr instructions
used in fenv.h may be privileged, and need similar care as booke/ibm4xx.

Thanks,
rin

Re: CVS commit: src/tests/lib/libc/sys

[Andrew Doran]

On Sat, Jun 06, 2020 at 06:11:21PM +, Jason R Thorpe wrote:

> Module Name:  src
> Committed By: thorpej
> Date: Sat Jun  6 18:11:21 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_lwp_create.c
> 
> Log Message:
> Add a test case to ensure that _lwp_create() fails with the
> expected error code when a bad new-lwp-id pointer is passed.

Was thinking of just this yesterday - thanks!  It's a fragile bit of code
and has been fixed 3x already this year.

Andrew

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 15.05.2020 00:43, Taylor R Campbell wrote:
>> Date: Thu, 14 May 2020 23:36:28 +0200
>> From: Kamil Rytarowski 
>>
>> If a signal would not reach the child process (as it is ignored or
>> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
>> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
>> Race free signals could be maybe possible, but with some design rethinking.
> 
> I don't understand -- are you saying that if I mask SIGCHLD, e.g. with
> sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE
> set, any SIGCHLD signals will be discarded while I have it masked?
> 

That's it. But it will be discarded only when there is no SIGCHLD signal
handler installed. That's the case in the test.

A debugger catches regular signals only (except crash related ones) when
they reach the debuggee,

> This can't be right, so either I misunderstood what you're saying, or
> something else is afoot with the test that is making it flaky, or
> there's a bug in the kernel.
> 

It's a design.

If we install a signal handler for SIGCHLD in the traced the test is
very stable and we note SIGCHLD always, so there is no bug.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Taylor R Campbell]

> Date: Thu, 14 May 2020 23:36:28 +0200
> From: Kamil Rytarowski 
> 
> If a signal would not reach the child process (as it is ignored or
> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
> Race free signals could be maybe possible, but with some design rethinking.

I don't understand -- are you saying that if I mask SIGCHLD, e.g. with
sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE
set, any SIGCHLD signals will be discarded while I have it masked?

This can't be right, so either I misunderstood what you're saying, or
something else is afoot with the test that is making it flaky, or
there's a bug in the kernel.

Re: CVS commit: src/tests/lib/libc/sys

[Joerg Sonnenberger]

On Thu, May 14, 2020 at 11:36:28PM +0200, Kamil Rytarowski wrote:
> On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> >> Module Name:   src
> >> Committed By:  kamil
> >> Date:  Thu May 14 19:21:35 UTC 2020
> >>
> >> Modified Files:
> >>src/tests/lib/libc/sys: t_ptrace_fork_wait.h
> >>
> >> Log Message:
> >> Ignore interception of the SIGCHLD signals.
> >>
> >> SIGCHLD once blocked is discarded by the kernel as it has the
> >> SA_IGNORE property. During the fork(2) operation all signals can be
> >> shortly blocked and missed (unless there is a registered signal
> >> handler in the traced child). This leads to a race in this test if
> >> there would be an intention to catch SIGCHLD.
> > 
> > This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
> > affect whether the signal handler is called, only when. Temporarily
> > masking a signal is different from setting it to SIG_IGN.
> > 
> > Joerg
> > 
> 
> I was looking into it and as there is no signal handler for SIGCHLD, the
> signal is discarded.

Sure, but that doesn't really have anything to do with signal blocking.
That's the part that is confusing.

Joerg

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu May 14 19:21:35 UTC 2020
>>
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>>
>> Log Message:
>> Ignore interception of the SIGCHLD signals.
>>
>> SIGCHLD once blocked is discarded by the kernel as it has the
>> SA_IGNORE property. During the fork(2) operation all signals can be
>> shortly blocked and missed (unless there is a registered signal
>> handler in the traced child). This leads to a race in this test if
>> there would be an intention to catch SIGCHLD.
> 
> This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
> affect whether the signal handler is called, only when. Temporarily
> masking a signal is different from setting it to SIG_IGN.
> 
> Joerg
> 

I was looking into it and as there is no signal handler for SIGCHLD, the
signal is discarded.

Another approach to fix the race would be to:

1. Add SIGCHLD signal handler in the traced child.
2. Explicitly masking SIGCHLD in the traced child.

If a signal would not reach the child process (as it is ignored or
masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
Race free signals could be maybe possible, but with some design rethinking.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Joerg Sonnenberger]

On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> Module Name:  src
> Committed By: kamil
> Date: Thu May 14 19:21:35 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_fork_wait.h
> 
> Log Message:
> Ignore interception of the SIGCHLD signals.
> 
> SIGCHLD once blocked is discarded by the kernel as it has the
> SA_IGNORE property. During the fork(2) operation all signals can be
> shortly blocked and missed (unless there is a registered signal
> handler in the traced child). This leads to a race in this test if
> there would be an intention to catch SIGCHLD.

This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
affect whether the signal handler is called, only when. Temporarily
masking a signal is different from setting it to SIG_IGN.

Joerg

Re: CVS commit: src/tests/lib/libc/sys

[Robert Elz]

Date:Mon, 11 May 2020 13:47:45 +0200
From:Kamil Rytarowski 
Message-ID:  <54178983-82d1-df3d-fd54-549a6c73f...@gmx.com>

  | The only purpose of the test is to check whether misaligned program
  | counter can crash the kernel (it can for NetBSD/sparc). Later, if a
  | process dies or runs is not important, thus it is being killed.

That's all fine.

  | A process can disappear after dying and before reappearing as a zombie.

There's a state between running and dead (zombie), that's correct - but
it really doesn't matter, once the process ceases to be alive, it is beyond
killing any more.

  | This is not a bug, but a predicted race.

Yes, that's what I said, and that's fine too.

  | Doing the kill once (and missing the process) is still possibly enough,
  | but correcting it with SIGKILL does not cost.

No, there is no problem with doing the SIGKILL, but if fails for the
above reason, there's absolutely no point trying again.  The process is
gone, it isn't coming back.   It doesn't need killing.

But even if there was a reason to try again (there isn't), one more
attempt would do - inserting an infinite loop is folly.

But I see that you have fixed it, that's good, what's there now looks
much better.   Thanks.

kre

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 11.05.2020 13:35, Robert Elz wrote:
> Date:Mon, 11 May 2020 11:03:15 +
> From:"Kamil Rytarowski" 
> Message-ID:  <2020050315.54b13f...@cvs.netbsd.org>
> 
>   | Do not fail when trying to kill a dying process
>   |
>   | A dying process can disappear for a while. Rather than aborting, retry
>   | sending SIGKILL to it.
> 
> I don't understand this ... a process should never be able to
> disappear and then reappear (not in any way).   If a SIGKILL (or
> ptrace(PT_KILL) fails with a "no such process" error, then repeating
> it won't (or shouldn't) help - if it does, there's a kernel bug that
> needs fixing (and it is OK for the test to fail until that happens.)
> 
> Further, if the reason for this failure is that the process is
> dying, you probably never needed the kill in the first place (and
> no, I don't mean it should be deleted - the parent is unlikely to
> know the state of the child, so killing it, if that is what is needed
> is the right thing to do ... just that if the kill fails because you
> were too late issuing it, it isn't an error, just a race that you lost,
> and certainly shouldn't be repeated).
> 
> But more than that, adding an infinite loop to the test, where you keep
> doing the kill forever until it succeeds, or errno somehow stops being
> ESRCH looks like a recipe for disaster.
> 
> Just do the kill once, ignore the error if it is ESRCH (and probably
> also ECHILD) report other errors as failures.
> 
> kre
> 

The only purpose of the test is to check whether misaligned program
counter can crash the kernel (it can for NetBSD/sparc). Later, if a
process dies or runs is not important, thus it is being killed.

A process can disappear after dying and before reappearing as a zombie.
This is not a bug, but a predicted race. We already discussed it in the
past, whether to return the same process multiple times or overlook it
for a while during the transition dying->zombie. Once an entity died it
disappeared so the same is true for a process.

Doing the kill once (and missing the process) is still possibly enough,
but correcting it with SIGKILL does not cost.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Robert Elz]

Date:Mon, 11 May 2020 11:03:15 +
From:"Kamil Rytarowski" 
Message-ID:  <2020050315.54b13f...@cvs.netbsd.org>

  | Do not fail when trying to kill a dying process
  |
  | A dying process can disappear for a while. Rather than aborting, retry
  | sending SIGKILL to it.

I don't understand this ... a process should never be able to
disappear and then reappear (not in any way).   If a SIGKILL (or
ptrace(PT_KILL) fails with a "no such process" error, then repeating
it won't (or shouldn't) help - if it does, there's a kernel bug that
needs fixing (and it is OK for the test to fail until that happens.)

Further, if the reason for this failure is that the process is
dying, you probably never needed the kill in the first place (and
no, I don't mean it should be deleted - the parent is unlikely to
know the state of the child, so killing it, if that is what is needed
is the right thing to do ... just that if the kill fails because you
were too late issuing it, it isn't an error, just a race that you lost,
and certainly shouldn't be repeated).

But more than that, adding an infinite loop to the test, where you keep
doing the kill forever until it succeeds, or errno somehow stops being
ESRCH looks like a recipe for disaster.

Just do the kill once, ignore the error if it is ESRCH (and probably
also ECHILD) report other errors as failures.

kre

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 24.04.2020 05:25, Jason R Thorpe wrote:
> Module Name:  src
> Committed By: thorpej
> Date: Fri Apr 24 03:25:20 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_x86_wait.h
> 
> Log Message:
> Update for new LWP behavior -- as of 9.99.59, the LWP ID of a single-LWP
> process is the PID, not 1.
> 

Thanks. These tests shall not rely on specific LWP numbers and I will
remove the asserts.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Christos Zoulas]

In article <5e528f7a-147a-23e7-46da-6b02d76e5...@gmx.com>,
Kamil Rytarowski   wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07.03.2020 15:53, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Mar  7 14:53:14 UTC 2020
>> 
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
>> 
>> Log Message:
>> Try to fix the build. This is why all those inlines should really be in a
>> separate file as regular function. The code is too large and hard to manage
>> this way, and only increases in complexity as time goes by.
>> 
>> 
>
>What build configuration was broken?

All of the evbarm ones since t_ptrace_sigchld.c was not including ieefp.h
http://releng.netbsd.org/builds/HEAD/202003070040Z/evbarm-earmhfeb.build.failed

christos

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 07.03.2020 15:53, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sat Mar  7 14:53:14 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
> 
> Log Message:
> Try to fix the build. This is why all those inlines should really be in a
> separate file as regular function. The code is too large and hard to manage
> this way, and only increases in complexity as time goes by.
> 
> 

What build configuration was broken?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 18.02.2020 16:57, Christos Zoulas wrote:
> In article <20200213152742.081a9f...@cvs.netbsd.org>,
> MichaŠ Górny   wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:mgorny
>> Date:Thu Feb 13 15:27:41 UTC 2020
>>
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_wait.c
>>
>> Log Message:
>> Enable combined breakpoint, watchpoint and signal tests
> 
> Let's split this file up. The name does not reflect anymore what this
> is testing and it has become more than 9000 lines long. Because of the
> complexity it keeps breaking the build and because of the size it makes
> fixing it awkward. Kamil/Michal, can you please work on this?
> [ for example the llvm builds are currently broken ]
> 
> Thanks,
> 
> christos
> 

I will do it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Christos Zoulas]

In article <20200213152742.081a9f...@cvs.netbsd.org>,
MichaŠ Górny   wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  mgorny
>Date:  Thu Feb 13 15:27:41 UTC 2020
>
>Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.c
>
>Log Message:
>Enable combined breakpoint, watchpoint and signal tests

Let's split this file up. The name does not reflect anymore what this
is testing and it has become more than 9000 lines long. Because of the
complexity it keeps breaking the build and because of the size it makes
fixing it awkward. Kamil/Michal, can you please work on this?
[ for example the llvm builds are currently broken ]

Thanks,

christos

Re: CVS commit: src/tests/lib/libc/sys

[Christos Zoulas]

In article <20200213114904.ga30...@bec.de>,
Joerg Sonnenberger   wrote:
>On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote:
>> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> > Module Name:   src
>> > Committed By:  christos
>> > Date:  Thu Feb 13 02:53:46 UTC 2020
>> > 
>> > Modified Files:
>> >src/tests/lib/libc/sys: t_ptrace_x86_wait.h
>> > 
>> > Log Message:
>> > Turn off optimization on a function which contains constant labels.
>> > The optimizer splits it and we end up with 2 copies and duplicate symbols.
>> 
>> Why not just turn them into local labels instead?
>
>Alternatively, suffixing them with %= would create unique labels.

I was looking for that :-)

christos

Re: CVS commit: src/tests/lib/libc/sys

[Christos Zoulas]

In article <20200213095019.ga28...@bec.de>,
Joerg Sonnenberger   wrote:
>On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Feb 13 02:53:46 UTC 2020
>> 
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_x86_wait.h
>> 
>> Log Message:
>> Turn off optimization on a function which contains constant labels.
>> The optimizer splits it and we end up with 2 copies and duplicate symbols.
>
>Why not just turn them into local labels instead?

You mean 1f etc? I was not sure if that would work in the symbol defined case.

christos

Re: CVS commit: src/tests/lib/libc/sys

[Joerg Sonnenberger]

On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote:
> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
> > Module Name:src
> > Committed By:   christos
> > Date:   Thu Feb 13 02:53:46 UTC 2020
> > 
> > Modified Files:
> > src/tests/lib/libc/sys: t_ptrace_x86_wait.h
> > 
> > Log Message:
> > Turn off optimization on a function which contains constant labels.
> > The optimizer splits it and we end up with 2 copies and duplicate symbols.
> 
> Why not just turn them into local labels instead?

Alternatively, suffixing them with %= would create unique labels.

Joerg

Re: CVS commit: src/tests/lib/libc/sys

[Joerg Sonnenberger]

On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Thu Feb 13 02:53:46 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_x86_wait.h
> 
> Log Message:
> Turn off optimization on a function which contains constant labels.
> The optimizer splits it and we end up with 2 copies and duplicate symbols.

Why not just turn them into local labels instead?

Joerg

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 01.07.2019 14:59, Robert Elz wrote:
> Date:Mon, 1 Jul 2019 11:55:57 +0200
> From:Joerg Sonnenberger 
> Message-ID:  <20190701095557.ga55...@bec.de>
> 
>   | On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:
> 
>   | > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential
>   | > signedness bit shifts.
>   |
>   | This change makes no sense.
> 
> Certainly the size_t cast is pointless ... and I have no idea what
> the comment in the commit message about bit shifts is about, this is
> (was) a simple comparison of an unsigned with a signed, which the
> cast to ssize_t turns into a signed comparison, which is as it should be.
> There are no bit shifts.
> 
> kre
> 
> 

OK, it was cast of 32bit value to ssize_t that can be 64bit.

The original type is uint32_t, not int32_t, so intermediate cast is not
needed.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/tests/lib/libc/sys

[Robert Elz]

Date:Mon, 1 Jul 2019 11:55:57 +0200
From:Joerg Sonnenberger 
Message-ID:  <20190701095557.ga55...@bec.de>

  | On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:

  | > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential
  | > signedness bit shifts.
  |
  | This change makes no sense.

Certainly the size_t cast is pointless ... and I have no idea what
the comment in the commit message about bit shifts is about, this is
(was) a simple comparison of an unsigned with a signed, which the
cast to ssize_t turns into a signed comparison, which is as it should be.
There are no bit shifts.

kre

Re: CVS commit: src/tests/lib/libc/sys

[Joerg Sonnenberger]

On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:
> Module Name:  src
> Committed By: kamil
> Date: Mon Jul  1 02:04:38 UTC 2019
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.c
> 
> Log Message:
> Avoid GCC warning on NetBSD/i386
> 
> Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential
> signedness bit shifts.

This change makes no sense.

Joerg

Re: CVS commit: src/tests/lib/libc/sys

[Jason Thorpe]

> On May 24, 2018, at 10:45 PM, Kamil Rytarowski  wrote:
> 
> Fixed!

Confirmed!  Thanks!

-- thorpej

Re: CVS commit: src/tests/lib/libc/sys

[Jason Thorpe]

This change seems to have broken building on 32-bit platforms (certainly at 
least for 32-bit ARM):

#   compile  sys/t_ptrace_wait.o
/nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2   -std=gnu99-Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare  
-Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings  -Wreturn-type 
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter 
-Wno-sign-compare -Wsign-compare -Wformat=2  -Wno-format-zero-length  -Werror 
-Wno-missing-noreturn   -fPIE--sysroot=/nbsd/destdir/rpi 
-I/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/../../..  -c   
-D_KERNTYPES 
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c
In file included from 
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.c:59:0:
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h: In 
function 'trigger_bus':
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:20: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL);
^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vx = (x);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:561:35: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)fp, (uintmax_t)NULL);
   ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vy = (y);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:20: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED);
^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:158:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vx = (x);  \
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:565:34: 
error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  FORKEE_ASSERT_NEQ((uintmax_t)p, (uintmax_t)MAP_FAILED);
  ^
/Users/thorpej/NetBSD/current/src/tests/lib/libc/sys/t_ptrace_wait.h:159:18: 
note: in definition of macro 'FORKEE_ASSERT_NEQ'
  uintmax_t vy = (y);  \
  ^
cc1: all warnings being treated as errors

*** Failed target:  t_ptrace_wait.o


Maybe uintptr_t is a better type to cast to?


> On May 23, 2018, at 6:18 AM, Kamil Rytarowski  wrote:
> 
> Module Name:  src
> Committed By: kamil
> Date: Wed May 23 13:18:09 UTC 2018
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_wait.h
> 
> Log Message:
> Add new auxiliary functions in ATF ptrace(2) tests
> 
> Introduce:
> - trigger_trap()
> - trigger_segv()
> - trigger_ill()
> - trigger_fpe()
> - trigger_bus()
> 
> These functions generate appropriate signals caused by crashes.
> 
> A debugger is required to collect the crashes regardless of signal masking,
> catching or ignoring rules.
> 
> While there, append __used argument to can_we_set_dbregs().
> 
> Sponsored by 
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/sys/t_ptrace_wait.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

-- thorpej

Re: CVS commit: src/tests/lib/libc/sys

[Valery Ushakov]

On Tue, Feb 27, 2018 at 11:15:53 +, Kamil Rytarowski wrote:

> Module Name:  src
> Committed By: kamil
> Date: Tue Feb 27 11:15:53 UTC 2018
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ucontext.c
> 
> Log Message:
> Make the t_ucontext.c test more portable
> 
> Cast _UC_MACHINE_*() to (register_t).
> This allows to print the returned values with PRIxREGISTER.
> 
> This corrects build failures on MIPS and HPPA.
> sizeof(int) == sizeof(long) on these 32-bit systems.

Why does this code use  instead of ?

Note, that PRIxREGISTER and other kernel PRIx* macros are, for better
or worse, not coming from inttypes headers, but from
.  But they can be deined in terms of standard PRIx*
macros and for the userland code those are officially defined by
.

-uwe

Re: CVS commit: src/tests/lib/libc/sys

[Alexander Mihalicyn]

help

On Tue, May 23, 2017 at 7:01 PM, Christos Zoulas 
wrote:

> Module Name:src
> Committed By:   christos
> Date:   Tue May 23 16:01:46 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/sys: t_mincore.c
>
> Log Message:
> Add the error in syscall failure.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.10 -r1.11 src/tests/lib/libc/sys/t_mincore.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>

Re: CVS commit: src/tests/lib/libc/sys

[Paul Goyette]

Module Name:src
Committed By:   martin
Date:   Fri Mar 24 08:18:27 UTC 2017

Modified Files:
src/tests/lib/libc/sys: t_mprotect.c

Log Message:
Do not toggle global security.pax.mprotect state in an attempt to
activate it for the current process. It does not work and tests should
not change global system state anyway.
Instead: skip the test is pax.mprotect is not globally enabled. We
could use a better check for this (querying the current processes pax 
flags), but unfortunately we don't have one.


I'll be committing a new sysctl variable proc.curproc.paxflags which 
will provide the ability to quest the current process's pax flags (or, 
indeed, the pax flags for any process which the caller is "allowed to 
see").



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: CVS commit: src/tests/lib/libc/sys

[Paul Goyette]

Should address PR bin/51869

On Sat, 14 Jan 2017, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Sat Jan 14 03:59:58 UTC 2017

Modified Files:
src/tests/lib/libc/sys: Makefile

Log Message:
Set FILESBUILD=yes to actually run the creation script for the file.

Should fix the build by creating a file which install can then find.


To generate a diff of this commit:
cvs rdiff -u -r1.46 -r1.47 src/tests/lib/libc/sys/Makefile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


!DSPAM:5879a267143851834045299!




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: CVS commit: src/tests/lib/libc/sys

[Robert Elz]

Date:Tue, 9 Aug 2016 12:02:44 +
From:"Robert Elz" 
Message-ID:  <20160809120244.9f9d0f...@cvs.netbsd.org>

Ignore this part ...

  | Note that NetBSD mlock(2) talks about EINVAL for cases where the length
  | parameter is negative ... but that is a size_t - good luck having that
  | ever occur (the man page will soon be corrected as well.)

I was reading the man page on a NetBSD-7 system ... didn't notice that
the man page was already corrected in current until I went to fix it!

kre

Re: CVS commit: src/tests/lib/libc/sys

[David Laight]

On Sat, Mar 09, 2013 at 12:19:08AM +0100, Martin Husemann wrote:
 On Fri, Mar 08, 2013 at 11:03:23PM +, David Laight wrote:
  Should the 'no timeout' case (try to) check that the elapsed time is
  less than one tick?
 
 I gave the (partly virtual) test platforms a bit more slope and made it  1s
 instead of 1 tick, but otherwise: yes.

If the test did:
poll(0, 0, 1);
gettimeofday();
run_test();
gettimeofday();
It should be able to distinguish between the 'no sleep' and 'sleep
for one tick' cases.

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: src/tests/lib/libc/sys

[David Laight]

On Fri, Mar 08, 2013 at 05:01:54PM +, Martin Husemann wrote:
 Module Name:  src
 Committed By: martin
 Date: Fri Mar  8 17:01:54 UTC 2013
 
 Modified Files:
   src/tests/lib/libc/sys: Makefile
 Added Files:
   src/tests/lib/libc/sys: t_sigtimedwait.c
 Removed Files:
   src/tests/lib/libc/sys: t_sigtimedwait_pr_47625.c
 
 Log Message:
 Rename testprogram and make it more general by adding other testcases.
 One commented out, I didn't manage to get all signal handling correct
 for now.

Should the 'no timeout' case (try to) check that the elapsed time is
less than one tick?

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: src/tests/lib/libc/sys

[Martin Husemann]

On Fri, Mar 08, 2013 at 11:03:23PM +, David Laight wrote:
 Should the 'no timeout' case (try to) check that the elapsed time is
 less than one tick?

I gave the (partly virtual) test platforms a bit more slope and made it  1s
instead of 1 tick, but otherwise: yes.

Martin

Re: CVS commit: src/tests/lib/libc/sys

[Martin Husemann]

On Sat, Sep 08, 2012 at 02:28:53PM +, Christos Zoulas wrote:
 Why not add a test for == VM_MIN_ADDRESS too?

If this is != NULL, we can not rely on it not to be mapped, so I don't
see any additional value in that case. The brk+1 page test should be good
enough.

Martin

Re: CVS commit: src/tests/lib/libc/sys

[Christos Zoulas]

On Sep 8,  4:32pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/sys

| On Sat, Sep 08, 2012 at 02:28:53PM +, Christos Zoulas wrote:
|  Why not add a test for == VM_MIN_ADDRESS too?
| 
| If this is != NULL, we can not rely on it not to be mapped, so I don't
| see any additional value in that case. The brk+1 page test should be good
| enough.

Thanks for explaining.

christos