Hi!

----

[AFAIK this is an old issue which somehow reappeared...]

A while ago we found that libast's allocator creates a SIGSEGV handler
for each chunk of memory obtained from the system to protect itself
against getting wallpoed with a SIGSEGV if first tries to use a newly
obtained memory page in cases when the kernel no longer has any
physical memory left to actually map the page, e.g.
like this:
-- snip --
mmap(0x00000000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFFFFFFFF53800000
sigaction(SIGSEGV, 0xFFFFFFFF7FFFE320, 0xFFFFFFFF7FFFE428) = 0
<newly obtained memory page is accessed here. If memory is not
available the system will wallop the process with a SIGSEGV>
sigaction(SIGSEGV, 0xFFFFFFFF7FFFE320, 0xFFFFFFFF7FFFE428) = 0
-- snip --

This makes sense if an operating system allows such overcommitment of
memory but it doesn't make much sense if the OS doesn't allow this...
like in Solaris case (maybe AIX, too...).
The fix was to #ifdef-out the handler for Solaris but it seems the
wrong cpp symbol was used, e.g. |_SUNOS| instead of |__SunOS|.
The following patch will fix this issue:
-- snip --
diff --git a/src/lib/libast/vmalloc/vmbest.c b/src/lib/libast/vmalloc/vmbest.c
index c291409..ff75b0a 100644
--- a/src/lib/libast/vmalloc/vmbest.c
+++ b/src/lib/libast/vmalloc/vmbest.c
@@ -1111,7 +1111,7 @@ done:
 #endif
 #endif

-#if _SUNOS /* sunos guarantees that brk-addresses are valid */
+#if __SunOS /* sunos guarantees that brk-addresses are valid */
 #define        chkaddr(a,n)    (0)

 #else /* make sure that allocated memory are addressable */
@@ -1140,7 +1140,7 @@ static int chkaddr(Vmuchar_t* addr, size_t nsize)

        return rv;
 }
-#endif /*_SUNOS*/
+#endif /*__SunOS*/

 #if _mem_win32 /
-- snip --

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [email protected]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to