I tried to access the red zone and a seg fault didn't occur but when
trying to access the kernel address space it does cause a seg fault. I
propose to change 0.printf.cpp to the following:
Index: 0.printf.cpp
===================================================================
--- 0.printf.cpp (revision 616446)
+++ 0.printf.cpp (working copy)
@@ -165,15 +165,7 @@
++addr;
}
else {
-
-#ifndef _RWSTD_OS_HP_UX
- // the first page is usually unmapped
- addr = (char*)32;
-#else
- // the first page on HP-UX is readable, this might work
- addr = (char*)(void*)bad_address + 1024 * 1024 * 16;
-#endif // _RWSTD_OS_HP_UX
-
+ addr = (char*)(void*)(0x0 - 1);
}
return addr;
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 29, 2008 2:14 PM
To: dev@stdcxx.apache.org
Subject: Re: [PATCH] STDCXX-705
Scott Zhong wrote:
> Could
>
> addr = (char*)(void*)size_t(-1);
>
> Be a better choice for a bad address?
I'm not sure.
The weird looking expression in the function tries to compute
an address that's beyond the last text segment page, or 16MB
past the address of the bad_address function. It was just
a wild guess that this address wouldn't be mapped. To get a
more reliable value we'll need to take a loot at the address
space layout of an HP-UX process. On IPF, it looks like there
are (at least) four possible layouts:
http://h21007.www2.hp.com/portal/download/files/unprot/Itanium/aas_white
_paper.pdf
From the white paper it looks like (void*)-1 might be a valid
address in the 32-bit SHARE-MAGIC address space where the top
of the address space is used for shared data. I suspect it
would be an invalid (inaccessible) address in the 64-bit MGAS
and MPAS models where the top is reserved for the kernel. In
the 32-bit MPAS model the address is part of the stack so it
would be valid if the stack grows down from it.
But I think the safest bet on 64-bit HP-UX/IPF is to use the
beginning of one of the two Red Zones for a bad address, or
0xa000 0000 0000 0000.
On 32-bit HP-UX where the Red Zone isn't at any fixed location
we might need to compute a bad address, e.g., as the next page
after the top of the heap. Calling sbrk(0) should return the
top of the process heap, so assuming the process doesn't
allocate any private maps (0.printf shouldn't) any address
pointing into the next page should be invalid.
Do you want to verify that? :)
Martin
>
> -----Original Message-----
> From: Scott Zhong [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 29, 2008 1:22 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] STDCXX-705
>
> the default page size can vary depending on the OS and can be changed
> with chatr. Currently the test assumes the page size is 16kb which is
> not the case on this platform thus causes the assertions to occur.
For
> the short term, we can adjust the multiplier to 64 instead of 16. For
> the long term, we need a better method to create a bad address.
>
>
> Index: 0.printf.cpp
> ===================================================================
> --- 0.printf.cpp (revision 616446)
> +++ 0.printf.cpp (working copy)
> @@ -171,7 +171,7 @@
> addr = (char*)32;
> #else
> // the first page on HP-UX is readable, this might work
> - addr = (char*)(void*)bad_address + 1024 * 1024 * 16;
> + addr = (char*)(void*)bad_address + 1024 * 1024 * 64;
> #endif // _RWSTD_OS_HP_UX
>
> }
