So your program has Obj * p; in it, and you stop in dbx and say print p** Dbx comes back and says the memory is illegal or unmapped. But then you continue your program, and your program reads from **p just fine. What’s going on?

This gotcha showed up again on a Sun alias. It’s been known to happen with a large database application whose initials are O. It’s not really a bug in dbx or a bug in the program, it’s just a slightly confusing “feature” in the Solaris.

Solaris allows you to call mmap to allocate memory in the address space, and it supports an option called MAP_NORESERVE. When you supply this option, the kernel will create a range of virtual memory that can be accessed by the program, but this memory will be filled with zeros on demand. Swap space is not reserved for the memory until it’s used, which makes it great for very large arrays that are only sparsely filled in.

Unfortunately, this creates memory which is perfectly valid from the program’s pont of view, but which Solaris (and the /proc interface) doesn’t admit is really there, when dbx asks about it.

In theory this bug could be “fixed” by modifying the /proc interface in Solaris so that it allows reading from all NORESERVE addresses and returns a value of 0. I suppose the kernel should prevent /proc from writing to any of these locations unless the user made some explicit statement that they wanted to modify the memory map of the target process.

It’s usually not a big deal to work around, you just have to be aware that dbx will tell you something is unmapped, even though the program might correctly be able to read/write to that location.