You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Scott Zhong <Sc...@roguewave.com> on 2008/01/29 21:22:11 UTC
[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
}
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
Scott Zhong wrote:
> cat t.cpp && aCC -V +DD32 t.cpp && file a.out && ./a.out
> #include <stdio.h>
>
> int main()
> {
> printf("%s", (char*)(void*)(0x0 - 1));
FYI: a SIGSEGV on this code doesn't necessarily tell us that (0x0 - 1)
isn't a valid address. It might be valid and there might be a non-NUL
byte there but 0x0 or 0x1 might be the invalid one.
But it does look like (0x0 - 1) is invalid and gives a SIGSEGV on all
HP-UX platforms (at least the four we tested), including the 32-bit
MPAS model.
Thanks
Martin
>
> return 0;
> }
> aCC: HP ANSI C++ B3910B A.03.63
> 92453-07 linker command s800.sgs ld PA64 B.11.45 REL 050725
> /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.45 050725
> a.out: PA-RISC1.1 shared executable dynamically linked -not
> stripped dynamically linked
> Segmentation fault (core dumped)
>
> aCC -V +DD64 t.cpp && file a.out && ./a.out
>
> aCC: HP ANSI C++ B3910B A.03.63
> 92453-07 linker command s800.sgs ld PA64 B.11.45 REL 050725
> a.out: ELF-64 executable object file - PA-RISC 2.0 (LP64)
> Segmentation fault (core dumped)
>
> cat t.cpp && aCC +DD32 t.cpp && file a.out && ./a.out
> #include <stdio.h>
>
> int main()
> {
> printf ("%s", (char*)(void*)(0x0 - 1));
>
> return 0;
> }
> a.out: ELF-32 executable object file - IA64
> Segmentation fault (core dumped)
>
> cat t.cpp && aCC +DD64 t.cpp && file a.out && ./a.out
> #include <stdio.h>
>
> int main()
> {
> printf ("%s", (char*)(void*)(0x0 - 1));
>
> return 0;
> }
> a.out: ELF-64 executable object file - IA64
> Segmentation fault (core dumped)
>
>
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, January 29, 2008 3:07 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [PATCH] STDCXX-705
>
> Scott Zhong wrote:
>> I tried to access the red zone and a seg fault didn't occur
>
> Odd.
>
>> but when
>> trying to access the kernel address space it does cause a seg fault.
>
> What about the 32-bit address spaces, especially in the MPAS
> model where the stack (supposedly) starts at 0xffffffff? And
> what about HP-UX on PA-RISC?
>
> Martin
>
>> 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;
>>
>
RE: [PATCH] STDCXX-705
Posted by Scott Zhong <Sc...@roguewave.com>.
cat t.cpp && aCC -V +DD32 t.cpp && file a.out && ./a.out
#include <stdio.h>
int main()
{
printf("%s", (char*)(void*)(0x0 - 1));
return 0;
}
aCC: HP ANSI C++ B3910B A.03.63
92453-07 linker command s800.sgs ld PA64 B.11.45 REL 050725
/usr/ccs/bin/ld: 92453-07 linker linker ld B.11.45 050725
a.out: PA-RISC1.1 shared executable dynamically linked -not
stripped dynamically linked
Segmentation fault (core dumped)
aCC -V +DD64 t.cpp && file a.out && ./a.out
aCC: HP ANSI C++ B3910B A.03.63
92453-07 linker command s800.sgs ld PA64 B.11.45 REL 050725
a.out: ELF-64 executable object file - PA-RISC 2.0 (LP64)
Segmentation fault (core dumped)
cat t.cpp && aCC +DD32 t.cpp && file a.out && ./a.out
#include <stdio.h>
int main()
{
printf ("%s", (char*)(void*)(0x0 - 1));
return 0;
}
a.out: ELF-32 executable object file - IA64
Segmentation fault (core dumped)
cat t.cpp && aCC +DD64 t.cpp && file a.out && ./a.out
#include <stdio.h>
int main()
{
printf ("%s", (char*)(void*)(0x0 - 1));
return 0;
}
a.out: ELF-64 executable object file - IA64
Segmentation fault (core dumped)
-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]
Sent: Tuesday, January 29, 2008 3:07 PM
To: dev@stdcxx.apache.org
Subject: Re: [PATCH] STDCXX-705
Scott Zhong wrote:
> I tried to access the red zone and a seg fault didn't occur
Odd.
> but when
> trying to access the kernel address space it does cause a seg fault.
What about the 32-bit address spaces, especially in the MPAS
model where the stack (supposedly) starts at 0xffffffff? And
what about HP-UX on PA-RISC?
Martin
> 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;
>
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
Scott Zhong wrote:
> I tried to access the red zone and a seg fault didn't occur
Odd.
> but when
> trying to access the kernel address space it does cause a seg fault.
What about the 32-bit address spaces, especially in the MPAS
model where the stack (supposedly) starts at 0xffffffff? And
what about HP-UX on PA-RISC?
Martin
> 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:sebor@roguewave.com]
> 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:Scott.Zhong@roguewave.com]
>> Sent: Tuesday, January 29, 2008 1:22 PM
>> To: stdcxx-dev@incubator.apache.org
>> 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
>>
>> }
>
RE: [PATCH] STDCXX-705
Posted by Scott Zhong <Sc...@roguewave.com>.
Actually ( 0x0 - 1 ) is going to give a misalign address, so we would
want 0x0 - sizeof(size_t) instead
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 - sizeof(size_t));
}
return addr;
-----Original Message-----
From: Scott Zhong [mailto:Scott.Zhong@roguewave.com]
Sent: Tuesday, January 29, 2008 2:49 PM
To: dev@stdcxx.apache.org
Subject: RE: [PATCH] STDCXX-705
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:sebor@roguewave.com]
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:Scott.Zhong@roguewave.com]
> Sent: Tuesday, January 29, 2008 1:22 PM
> To: stdcxx-dev@incubator.apache.org
> 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
>
> }
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
Scott Zhong wrote:
> Actually ( 0x0 - 1 ) is going to give a misalign address, so we would
> want 0x0 - sizeof(size_t) instead
Okay, I've committed a modified version of your patch:
http://svn.apache.org/viewvc?view=rev&revision=616976
Thanks
Martin
>
> 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 - sizeof(size_t));
> }
>
> return addr;
>
> -----Original Message-----
> From: Scott Zhong [mailto:Scott.Zhong@roguewave.com]
> Sent: Tuesday, January 29, 2008 2:49 PM
> To: dev@stdcxx.apache.org
> Subject: RE: [PATCH] STDCXX-705
>
> 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:sebor@roguewave.com]
> 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:Scott.Zhong@roguewave.com]
>> Sent: Tuesday, January 29, 2008 1:22 PM
>> To: stdcxx-dev@incubator.apache.org
>> 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
>>
>> }
>
RE: [PATCH] STDCXX-705
Posted by Scott Zhong <Sc...@roguewave.com>.
Actually ( 0x0 - 1 ) is going to give a misalign address, so we would
want 0x0 - sizeof(size_t) instead
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 - sizeof(size_t));
}
return addr;
-----Original Message-----
From: Scott Zhong [mailto:Scott.Zhong@roguewave.com]
Sent: Tuesday, January 29, 2008 2:49 PM
To: dev@stdcxx.apache.org
Subject: RE: [PATCH] STDCXX-705
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:sebor@roguewave.com]
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:Scott.Zhong@roguewave.com]
> Sent: Tuesday, January 29, 2008 1:22 PM
> To: stdcxx-dev@incubator.apache.org
> 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
>
> }
RE: [PATCH] STDCXX-705
Posted by Scott Zhong <Sc...@roguewave.com>.
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:sebor@roguewave.com]
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:Scott.Zhong@roguewave.com]
> Sent: Tuesday, January 29, 2008 1:22 PM
> To: stdcxx-dev@incubator.apache.org
> 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
>
> }
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
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:Scott.Zhong@roguewave.com]
> Sent: Tuesday, January 29, 2008 1:22 PM
> To: stdcxx-dev@incubator.apache.org
> 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
>
> }
RE: [PATCH] STDCXX-705
Posted by Scott Zhong <Sc...@roguewave.com>.
Could
addr = (char*)(void*)size_t(-1);
Be a better choice for a bad address?
-----Original Message-----
From: Scott Zhong [mailto:Scott.Zhong@roguewave.com]
Sent: Tuesday, January 29, 2008 1:22 PM
To: stdcxx-dev@incubator.apache.org
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
}
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Martin Sebor wrote:
>> Travis Vitek wrote:
>>>
>>>> It looks like th original code was stepping 16MB (1024 * 1024 bytes)
>>>> past bad_address. That should be well more than one page away. BTW, you
>>>> can determine the kernel page size on most *nix platforms with sysconf
>>>> (_SC_PAGESIZE).
>>>>
>>>> Travis
>>>>
>>> Of course the kernel memory page size from sysconf() isn't the same as
>>> the virtual memory page size that you are talking about. :)
>> It's not? I thought both sysconf(_SC_PAGESIZE) and getpagesize()
>> returned the size of the virtual page. I.e., whatever smallest
>> unit mmap() allocates.
>>
>> Martin
>>
>
> I think I may have worded my response poorly. The page size, as returned by
> sysconf(), is does not appear to be the same as the page size that is set by
> chatr.
>
> $ cat u.cpp && aCC u.cpp
> #include <stdio.h>
> #include <unistd.h>
>
> int main ()
> {
> printf ("%ld\n", sysconf (_SC_PAGE_SIZE));
> return 0;
> }
>
> $ chatr +pd 1M +pi 1M a.out > /dev/null && ./a.out
> 4096
>
> $ chatr +pd 4M +pi 4M a.out > /dev/null && ./a.out
> 4096
>
> A quick glance at the documentation for chatr says that +pd and +pi are only
> hints for the virtual memory page size, so that may explain the difference
> I'm seeing. Interestingly, you can set values for up to 4GB.
Yes, on Itanium 2 it can be up to 4GB.
I've re-read section 8.2.1 Variable Page Sizes of HP-UX 11i Tuning
and Performance to better understand how this works. Apparently,
the chatr command above just raises the ceiling for the text and
data page sizes for the executable. When the program allocates
memory (e.g., by calling mmap()) the OS will attempt to allocate
it in multiples of pages of at most that size. The smallest page
the HP-UX kernel can allocate is still 4KB, and that's the value
returned by the sysconf call.
Interesting stuff!
Martin
>
> Travis
Re: [PATCH] STDCXX-705
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> Travis Vitek wrote:
>>
>>>
>>> It looks like th original code was stepping 16MB (1024 * 1024 bytes)
>>> past bad_address. That should be well more than one page away. BTW, you
>>> can determine the kernel page size on most *nix platforms with sysconf
>>> (_SC_PAGESIZE).
>>>
>>> Travis
>>>
>>
>> Of course the kernel memory page size from sysconf() isn't the same as
>> the virtual memory page size that you are talking about. :)
>
> It's not? I thought both sysconf(_SC_PAGESIZE) and getpagesize()
> returned the size of the virtual page. I.e., whatever smallest
> unit mmap() allocates.
>
> Martin
>
I think I may have worded my response poorly. The page size, as returned by
sysconf(), is does not appear to be the same as the page size that is set by
chatr.
$ cat u.cpp && aCC u.cpp
#include <stdio.h>
#include <unistd.h>
int main ()
{
printf ("%ld\n", sysconf (_SC_PAGE_SIZE));
return 0;
}
$ chatr +pd 1M +pi 1M a.out > /dev/null && ./a.out
4096
$ chatr +pd 4M +pi 4M a.out > /dev/null && ./a.out
4096
A quick glance at the documentation for chatr says that +pd and +pi are only
hints for the virtual memory page size, so that may explain the difference
I'm seeing. Interestingly, you can set values for up to 4GB.
Travis
--
View this message in context: http://www.nabble.com/-PATCH--STDCXX-705-tp15168662p15171629.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: [PATCH] STDCXX-705
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Travis Vitek wrote:
>>
>>
>>> Scott Zhong wrote:
>>>
>>> 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
>>>
>>> }
>>>
>> It looks like th original code was stepping 16MB (1024 * 1024 bytes)
>> past bad_address. That should be well more than one page away. BTW, you
>> can determine the kernel page size on most *nix platforms with sysconf
>> (_SC_PAGESIZE).
>>
>> Travis
>>
>
> Of course the kernel memory page size from sysconf() isn't the same as
> the virtual memory page size that you are talking about. :)
It's not? I thought both sysconf(_SC_PAGESIZE) and getpagesize()
returned the size of the virtual page. I.e., whatever smallest
unit mmap() allocates.
Martin
RE: [PATCH] STDCXX-705
Posted by Travis Vitek <Tr...@roguewave.com>.
>Travis Vitek wrote:
>
>
>>Scott Zhong wrote:
>>
>>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
>>
>> }
>>
>
>It looks like th original code was stepping 16MB (1024 * 1024 bytes)
>past bad_address. That should be well more than one page away. BTW, you
>can determine the kernel page size on most *nix platforms with sysconf
>(_SC_PAGESIZE).
>
>Travis
>
Of course the kernel memory page size from sysconf() isn't the same as
the virtual memory page size that you are talking about. :)
RE: [PATCH] STDCXX-705
Posted by Travis Vitek <Tr...@roguewave.com>.
>Scott Zhong wrote:
>
>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
>
> }
>
It looks like th original code was stepping 16MB (1024 * 1024 bytes)
past bad_address. That should be well more than one page away. BTW, you
can determine the kernel page size on most *nix platforms with sysconf
(_SC_PAGESIZE).
Travis