Date: Mon, 16 Dec 2024 14:43:45 +1030 From: Daniel O'Connor <darius@dons.net.au> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, freebsd-amd64@freebsd.org Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? Message-ID: <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> In-Reply-To: <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com>
index | next in thread | previous in thread | raw e-mail
Hi Mark, > On 16 Dec 2024, at 10:33, Mark Millard <marklmi@yahoo.com> wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash problem > someone has been having over more than 2 years. There are boot time crashes > involved. > > It appears that 0xFFFFF80000000007 is showing up in use and stored in data > structures as a pointer value in fields/arguments that are pointers, where such > a special value would not be expected. Later defrerencing does not go well, at > least when the dererefenced data is then in-turn put to use. > > The small offset from 0xFFFFF80000000000 suggests to me that the special value likely > is inappropriately left around and somehow picked up and used. 0xFFFFF80000000000 (or > near it) might be odd enough to have only a few known likely possible usages. Such > notes in the bugzilla report would be good if such is the case. Thus my question. That value (0xffffffff80000000) is kernbase (see sysctl kern.base_address). However it is hard to think of why that value (or a small offset to it) is getting put in places it shouldn't be.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaumhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6>