NetBSD Problem Report #57708
From he@smistad.uninett.no Sun Nov 19 20:29:48 2023
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 04DBF1A9238
for <gnats-bugs@gnats.NetBSD.org>; Sun, 19 Nov 2023 20:29:47 +0000 (UTC)
Message-Id: <20231119202941.B679A43ED14@smistad.uninett.no>
Date: Sun, 19 Nov 2023 21:29:41 +0100 (CET)
From: he@NetBSD.org
Reply-To: he@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: rust problem when building firefox
X-Send-Pr-Version: 3.95
>Number: 57708
>Category: pkg
>Synopsis: rust problem when building firefox
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: pkg-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Nov 19 20:30:00 +0000 2023
>Last-Modified: Sat Dec 09 13:15:04 +0000 2023
>Originator: Havard Eidnes
>Release: NetBSD 10.0_BETA
>Organization:
I try...
>Environment:
System: NetBSD smistad.uninett.no 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Fri Aug 18 12:52:31 UTC 2023 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
Ref. the mail thread at tech-pkg, under the subject "rust
problem when building firefox", starting at
https://mail-index.netbsd.org/tech-pkg/2023/11/16/msg028449.html
Thomas Klausner is reporting that rust *somtetimes* (not fully
reproducible) fails when building firefox as part of a bulk
build, and when it fails, it dumps a rust stack trace, like
so:
0: 0x19147a8 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc7af7c8c491f235f
1: 0x195895c - core::fmt::write::h6704aa23384ebf6d
2: 0x191770e - std::io::Write::write_fmt::h1ec88ed87f1a548f
3: 0x1914536 - std::sys_common::backtrace::print::h439fad3f83fbc4b5
4: 0x19346e3 - std::panicking::default_hook::{{closure}}::h1c39ed34efd31c8a
5: 0x1934368 - std::panicking::default_hook::h4ee60615d1c92b96
6: 0x193596c - std::panicking::rust_panic_with_hook::hec2f115bd3abe8a5
7: 0x1914fb7 - std::panicking::begin_panic_handler::{{closure}}::h92a702d96e469894
8: 0x1914c46 - std::sys_common::backtrace::__rust_end_short_backtrace::h4f5ab40c7a48f822
9: 0x19354d2 - rust_begin_unwind
10: 0xc71343 - core::panicking::panic_fmt::h0a6a30a68313052a
11: 0x193d620 - std::sys::unix::thread::guard::init::h5287555ac329da10
12: 0x190a3b9 - std::rt::init::h6e67e26812f912e8
13: 0x190a52b - std::rt::lang_start_internal::h927544304a5690c7
14: 0xcf2cd5 - main
15: 0xbf637d - ___start
at /usr/src/lib/csu/common/crt0-common.c:350:2
fatal runtime error: initialization or cleanup bug
Reportedly, this does not happen every time, but with a
certain regularity.
The panick points to this function:
https://doc.rust-lang.org/src/std/sys/unix/thread.rs.html#835-914
This code has conditionals for FreeBSD and OpenBSD, but NetBSD is not
described / implemented. The "Guard" Option is apparently used
elsewhere, such as in
https://github.com/rust-lang/rust/blob/master/library/std/src/sys_common/thread_info.rs
though grep'ing for "Guard" in the rust source code reveals several
other matches.
>How-To-Repeat:
Repeatedly build firefox, and watch it fail with some
regularity.
>Fix:
Implement the init part for NetBSD. Hopefully all our ports
have the same behaviour in this aspect(?)
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: he@NetBSD.org
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57708: rust problem when building firefox
Date: Sun, 19 Nov 2023 20:52:17 +0000
The attached program should print the regions of the program's stack
and guard pages using various pthread(3) functions (demonstrated both
for the main thread and for a pthread it spawns). This might help you
to draft the relevant code for Rust.
However, it is not exactly accurate, because the kernel will
automatically grow the stack of the main thread if its stack usage
increases, subject to the stack soft rlimit, which the process can
change itself (subject to the stack hard rlimit, it can't change).
So the results might be stale as soon as you use them. Which raises
the question -- what is Rust trying to do with this information and
why?
From: Taylor R Campbell <riastradh@NetBSD.org>
To: he@NetBSD.org
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57708: rust problem when building firefox
Date: Sun, 19 Nov 2023 20:54:57 +0000
This is a multi-part message in MIME format.
--=_k+R2A0jPCfl/fFvU84G4E4n02s6AxFtx
> Date: Sun, 19 Nov 2023 20:52:17 +0000
> From: Taylor R Campbell <riastradh@NetBSD.org>
>
> The attached program [...]
actually attached now.
--=_k+R2A0jPCfl/fFvU84G4E4n02s6AxFtx
Content-Type: text/plain; charset="ISO-8859-1"; name="guard"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="guard.c"
#include <err.h>
#include <pthread.h>
#include <stdio.h>
static void
showstack(const char *who)
{
pthread_attr_t attr;
void *stackaddr, *guardaddr;
size_t stacksize, guardsize;
int error;
error =3D pthread_getattr_np(pthread_self(), &attr);
if (error)
errc(1, error, "pthread_getattr_np");
error =3D pthread_attr_getstack(&attr, &stackaddr, &stacksize);
if (error)
errc(1, error, "pthread_attr_getstack");
error =3D pthread_attr_getguardsize(&attr, &guardsize);
if (error)
errc(1, error, "pthread_attr_getguardsize");
error =3D pthread_attr_destroy(&attr);
if (error)
errc(1, error, "pthread_attr_destroy");
#ifdef __MACHINE_STACK_GROWS_UP
guardaddr =3D (char *)stackaddr + stacksize - guardsize;
#else
guardaddr =3D stackaddr;
#endif
printf("%s: stack %zu/0x%zx bytes @ [%p, %p)\n",
who, stacksize, stacksize,
stackaddr, (char *)stackaddr + stacksize);
printf("%s: guard %zu/0x%zx bytes @ [%p, %p)\n",
who, guardsize, guardsize,
guardaddr, (char *)guardaddr + guardsize);
}
static void *
start(void *cookie)
{
showstack("pthread_create");
return cookie;
}
int
main(void)
{
pthread_t t;
int error;
showstack("main thread");
fflush(stdout);
error =3D pthread_create(&t, NULL, &start, NULL);
if (error)
errc(1, error, "pthread_create");
error =3D pthread_join(t, NULL);
if (error)
errc(1, error, "pthread_join");
fflush(stdout);
return ferror(stdout);
}
--=_k+R2A0jPCfl/fFvU84G4E4n02s6AxFtx--
From: Robert Elz <kre@munnari.OZ.AU>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: he@NetBSD.org, gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57708: rust problem when building firefox
Date: Mon, 20 Nov 2023 13:12:48 +0700
Date: Sun, 19 Nov 2023 20:52:17 +0000
From: Taylor R Campbell <riastradh@NetBSD.org>
Message-ID: <20231119205217.CE5EE6083E@jupiter.mumble.net>
| Which raises the question -- what is Rust trying to do with this
| information and why?
Purely from my reading of (not all of) the messages on this thread,
my guess, and it is certainly no more than that, is that rust wants
a guaranteed "dead" spot between the stack and other data ranges,
guaranteed to cause an address fault if it is referenced (so there
is no likely possibility that a process overflowing its stack might just
hit some mapped data page and succeed) - and is willing to mmap() and
mprotect() a region of memory itself to make that happen (if needed),
but for that, needs to know where to put that in the address space.
And second, when an address fault happens (SIGSEGV or whatever) it
wants to be able to tell whether the fault happened in this dead space,
and so was probably caused by a stack overflow (this might be just so
it can print a different error message than it would for other address
faults, before terminating the program).
The other BSD implementations seem to know that a guard space is already
placed at the bottom of the (max possible) stack growth area, so rust
doesn't need to do anything to make one appear, and simply return the
addresses that occupies (so rust can check if a faulting addr is in that
space, I assume).
There's just no NetBSD equiv code to the FreeBSD & OpenBSD versions (which
differ).
To me, for someone who knows how NetBSD address mapping for the stack is
done, and how to access that from user space (via getrlimit() or sysctl()
somehow) this should be simple ... and I think that one can assume that if
rust provides a mechanism to allow a process to alter its max stack size,
it will take care of learning about (or installing) a new guard region
after that happens.
kre
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 23 Nov 2023 21:16:13 +0000
Module Name: src
Committed By: riastradh
Date: Thu Nov 23 21:16:13 UTC 2023
Modified Files:
src/share/man/man7: Makefile
Log Message:
share/man/man7/Makefile: Split MAN on separate lines, and sort.
Makes sorting and merging changes easier.
No functional change intended.
Preparing for a new stack(7) in the service of PR pkg/57708.
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/share/man/man7/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src
Date: Thu, 23 Nov 2023 21:20:50 +0000
Module Name: src
Committed By: riastradh
Date: Thu Nov 23 21:20:50 UTC 2023
Modified Files:
src/distrib/sets/lists/man: mi
Added Files:
src/share/man/man7: stack.7
Log Message:
stack(7): New man page.
Should help with PR pkg/57708.
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.1766 -r1.1767 src/distrib/sets/lists/man/mi
cvs rdiff -u -r0 -r1.1 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 23 Nov 2023 21:27:08 +0000
Module Name: src
Committed By: riastradh
Date: Thu Nov 23 21:27:08 UTC 2023
Modified Files:
src/share/man/man7: stack.7
Log Message:
stack(7): Clarify thread stack guard vs program stack guard.
Just in case this confuses anyone dealing with PR pkg/57708.
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 23 Nov 2023 21:30:03 +0000
Module Name: src
Committed By: riastradh
Date: Thu Nov 23 21:30:03 UTC 2023
Modified Files:
src/share/man/man7: stack.7
Log Message:
stack(7): Clarify some wording and diagrams.
PR pkg/57708
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 23 Nov 2023 21:44:55 +0000
Module Name: src
Committed By: riastradh
Date: Thu Nov 23 21:44:55 UTC 2023
Modified Files:
src/share/man/man7: stack.7
Log Message:
stack(7): Consistently say `(in)accessible pages', not `... stack'.
PR pkg/57708
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: he@NetBSD.org
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57708: rust problem when building firefox
Date: Thu, 30 Nov 2023 14:38:25 +0000
This is a multi-part message in MIME format.
--=_tVq9BOFzAnpXS9N5Qy8XBZQoi+hFOgDk
The attached Rust program prints the parameters for both the main
thread and non-main threads. It should be relatively easy to adapt to
the code in Rust std/sys/thread.rs, I expect.
Plop it in src/main.rs next to a Cargo.toml file with the following
content, and run with `cargo run':
[package]
name = "stackguard"
version = "0.1.0"
edition = "2021"
[dependencies]
libc = "^0.2.150"
--=_tVq9BOFzAnpXS9N5Qy8XBZQoi+hFOgDk
Content-Type: text/plain; charset="ISO-8859-1"; name="main"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="main.rs"
//
// __MACHINE_STACK_GROWS_UP (hppa):
//
// +---------------+
// | |
// | guard pages | guardsize
// | |
// +---------------+ guardaddr =3D stackbase + stacksize
// | |
// | stack pages | stacksize
// | |
// +---------------+ stackaddr =3D stackbase
//
// !__MACHINE_STACK_GROWS_UP (i.e., stack grows down -- most
// architectures):
//
// +---------------+ stackbase
// | |
// | stack pages | stacksize
// | |
// +---------------+ stackaddr =3D stackbase - stacksize
// | |
// | guard pages | guardsize
// | |
// +---------------+ guardaddr =3D stackbase - stacksize - guardsize
//
use libc;
use std::io;
use std::mem;
use std::os::raw::c_int;
use std::os::raw::c_uint;
use std::os::raw::c_ulong;
use std::os::raw::c_void;
use std::ptr;
const __MACHINE_STACK_GROWS_UP: bool =3D false; // XXX
#[repr(C)]
struct AuxInfo {
a_type: u32, // Elf32_Word, Elf64_Word
a_v: c_ulong, // Elf32_Word, Elf64_Xword
}
const AT_NULL: u32 =3D 0;
const AT_STACKBASE: u32 =3D 13;
extern { fn _dlauxinfo() -> *const AuxInfo; }
const VM_GUARD_SIZE: c_int =3D 17;
fn pth(error: c_int) -> io::Result<()> {
if error =3D=3D 0 {
Ok(())
} else {
Err(io::Error::from_raw_os_error(error))
}
}
fn getmainstack() -> io::Result<(*mut c_void, usize, *mut c_void, usize)> {
// Get the stack guard size by reading the unsigned int
// vm.guard_size sysctl.
//
// XXX In principle, this is racy because there is a window between
// when the kernel reads the sysctl to determine the guard page
// allocation and when we read the sysctl to find what that was,
// during which time a privileged process could change the sysctl
// without affecting the guard page allocation, but
//
// (a) it's unlikely that this will happen, and
//
// (b) NetBSD doesn't currently provide a non-racy way to do this,
// like maybe an AT_NETBSD_GUARDSIZE auxinfo entry.
//
let mut mib =3D [libc::CTL_VM, VM_GUARD_SIZE];
let mut guardsize: c_uint =3D 0;
let mut len: usize =3D mem::size_of::<c_uint>();
if unsafe { libc::sysctl(
mib.as_mut_ptr(), // name
mib.len() as c_uint, // namelen
&mut guardsize as *mut _ as *mut _, // oldp
&mut len, // oldlenp
ptr::null_mut(), // newp
0, // newlenp
) } =3D=3D -1 {
return Err(io::Error::last_os_error());
}
// Get the stack base by reading the AT_STACKBASE _dlauxinfo item.
// Note: This is the initial stack pointer -- not the numerically
// lowest address; it grows up or down depending on
// __MACHINE_STACK_GROWS_UP.
//
let mut auxinfo =3D unsafe { _dlauxinfo() };
let mut stackbase: *mut c_void =3D ptr::null_mut();
while unsafe { (*auxinfo).a_type } !=3D AT_NULL {
let (a_type, a_v) =3D unsafe { ((*auxinfo).a_type, (*auxinfo).a_v) =
};
println!("a_type=3D{} a_v=3D0x{:x}", a_type, a_v);
if a_type =3D=3D AT_STACKBASE {
stackbase =3D unsafe { mem::transmute((*auxinfo).a_v) };
break
}
auxinfo =3D unsafe { auxinfo.offset(1) };
}
// Get the stack size by reading the hard stack rlimit, which the
// kernel used to determine the maximum stack allocation (not
// including the guard pages).
//
// XXX In principle, this is racy because there is a window between
// when the kernel reads the rlimit to determine the maximum stack
// allocation and when we read the rlimit to find what that was,
// during which time a privileged process could change the rlimit
// without affecting the stack allocation, but
//
// (a) it's unlikely that this will happen, and
//
// (b) NetBSD doesn't currently provide a non-racy way to do this,
// like maybe an AT_NETBSD_STACKSIZE auxinfo entry.
//
let mut rlim =3D unsafe { mem::zeroed() };
if unsafe { libc::getrlimit(libc::RLIMIT_STACK, &mut rlim) } =3D=3D -1 {
return Err(io::Error::last_os_error());
}
let stacksize =3D rlim.rlim_max as usize;
let istacksize =3D stacksize as isize;
let iguardsize =3D guardsize as isize;
// Determine the numerically least addresses of the stack and
// guard. See diagram at top about stacks that grow up vs stacks
// that grow down.
//
let stackaddr =3D if __MACHINE_STACK_GROWS_UP {
stackbase
} else {
unsafe { stackbase.offset(-istacksize) }
};
let guardaddr =3D if __MACHINE_STACK_GROWS_UP {
unsafe { stackbase.offset(istacksize) }
} else {
unsafe { stackbase.offset(-istacksize - iguardsize) }
};
Ok((stackaddr, stacksize, guardaddr, guardsize as usize))
}
fn getthreadattrstack(attr: *mut libc::pthread_attr_t)
-> io::Result<(*mut c_void, usize, *mut c_void, usize)> {
let mut stackaddr =3D ptr::null_mut();
let mut stacksize: usize =3D 0;
let mut guardsize: usize =3D 0;
pth(unsafe {
libc::pthread_attr_getstack(attr, &mut stackaddr, &mut stacksize)
})?;
pth(unsafe { libc::pthread_attr_getguardsize(attr, &mut guardsize) })?;
let guardaddr =3D if __MACHINE_STACK_GROWS_UP {
unsafe { stackaddr.offset(stacksize as isize) }
} else {
unsafe { stackaddr.offset(-(guardsize as isize)) }
};
Ok((stackaddr, stacksize, guardaddr, guardsize))
}
fn getthreadstack() -> io::Result<(*mut c_void, usize, *mut c_void, usize)>=
{
let t =3D unsafe { libc::pthread_self() };
let mut attr: libc::pthread_attr_t =3D unsafe { mem::zeroed() };
pth(unsafe { libc::pthread_getattr_np(t, &mut attr) })?;
let r =3D getthreadattrstack(&mut attr);
pth(unsafe { libc::pthread_attr_destroy(&mut attr) })
.expect("pthread_attr_destroy should never fail");
r
}
fn showstack(name: &str, stack: (*mut c_void, usize, *mut c_void, usize)) {
let (stackaddr, stacksize, guardaddr, guardsize) =3D stack;
println!("{} stack @ [{:p}, {:p})",
name,
stackaddr, unsafe { stackaddr.offset(stacksize as isize) });
println!("{} guard @ [{:p}, {:p})",
name,
guardaddr, unsafe { guardaddr.offset(guardsize as isize) });
}
fn main() {
match getmainstack() {
Ok(stack) =3D> showstack("main", stack),
Err(e) =3D> println!("getmainstack: {}", e),
}
match getthreadstack() {
Ok(stack) =3D> showstack("thread", stack),
Err(e) =3D> println!("getthreadstack: {}", e),
}
}
--=_tVq9BOFzAnpXS9N5Qy8XBZQoi+hFOgDk--
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 7 Dec 2023 17:15:49 +0000
Module Name: src
Committed By: riastradh
Date: Thu Dec 7 17:15:48 UTC 2023
Modified Files:
src/share/man/man7: stack.7
Log Message:
stack(7): Minor clarifications and wording tweaks.
Suggested by pgoyette@ and uwe@.
PR pkg/57708
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: src/share/man/man7
Date: Thu, 7 Dec 2023 17:24:22 +0000
Module Name: src
Committed By: riastradh
Date: Thu Dec 7 17:24:22 UTC 2023
Modified Files:
src/share/man/man7: stack.7
Log Message:
stack(7): Fix diagram of non-main thread stacks.
Had stackaddr (pthread_attr_setstack parameter, lowest-numbered
virtual address of stack region) confused with stack base (where the
stack grows from, which is the highest-numbered virtual address on
machines where stack grows down).
PR pkg/57708
XXX pullup-10
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57708 CVS commit: [netbsd-10] src
Date: Sat, 9 Dec 2023 13:13:49 +0000
Module Name: src
Committed By: martin
Date: Sat Dec 9 13:13:49 UTC 2023
Modified Files:
src/distrib/sets/lists/man [netbsd-10]: mi
src/share/man/man7 [netbsd-10]: Makefile
Added Files:
src/share/man/man7 [netbsd-10]: stack.7
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #486):
distrib/sets/lists/man/mi: revision 1.1767
share/man/man7/Makefile: revision 1.38
share/man/man7/Makefile: revision 1.39
share/man/man7/stack.7: revision 1.1
share/man/man7/stack.7: revision 1.2
share/man/man7/stack.7: revision 1.3
share/man/man7/stack.7: revision 1.4
share/man/man7/stack.7: revision 1.5
share/man/man7/stack.7: revision 1.6
share/man/man7/Makefile: Split MAN on separate lines, and sort.
Makes sorting and merging changes easier.
No functional change intended.
Preparing for a new stack(7) in the service of PR pkg/57708.
stack(7): New man page.
Should help with PR pkg/57708.
stack(7): Clarify thread stack guard vs program stack guard.
Just in case this confuses anyone dealing with PR pkg/57708.
stack(7): Clarify some wording and diagrams.
PR pkg/57708
stack(7): Consistently say `(in)accessible pages', not `... stack'.
PR pkg/57708
share/man/man7/Makefile: Hook stack.7
stack(7): Minor clarifications and wording tweaks.
Suggested by pgoyette@ and uwe@.
PR pkg/57708
stack(7): Fix diagram of non-main thread stacks.
Had stackaddr (pthread_attr_setstack parameter, lowest-numbered
virtual address of stack region) confused with stack base (where the
stack grows from, which is the highest-numbered virtual address on
machines where stack grows down).
PR pkg/57708
To generate a diff of this commit:
cvs rdiff -u -r1.1757.2.5 -r1.1757.2.6 src/distrib/sets/lists/man/mi
cvs rdiff -u -r1.36 -r1.36.6.1 src/share/man/man7/Makefile
cvs rdiff -u -r0 -r1.6.2.2 src/share/man/man7/stack.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home