Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ?
Date: Mon, 16 Dec 2024 06:35:55 UTC
> On 16 Dec 2024, at 16:18, Mark Millard <marklmi@yahoo.com> wrote: >>> 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). > > On an amd64 system that I have access to: > > # sysctl -x kern.base_address > kern.base_address: 0xffffffff80000000 > > But, while looking similar, it is not the same base number: > > 0xfffff80000000007 (copied and pasted from the kgdb session on the vmcore.*) > 0xffffffff80000000 Oops, my mistake! > However, kern.base_address might be something that varies from > system to system in some way. Your value is the same as mine on this amd64 system - I don't think it varies (for a given architecture anyway) > The closest examples I see in sysctl -ax output, start with > 0xfffff801. . ., such as shown by: > > kern.geom.confdot: digraph geom { > z0xfffff80105633a00 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#4"]; I assume these addresses are pointers to the internal GEOM objects (because they must be unique) - ie they are actual memory location. Hmm, perhaps 0xfffff80000000000 is where kernel RAM starts? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum