zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: mmap error
@ 2000-02-01 13:07 Sven Wischnowsky
  0 siblings, 0 replies; 4+ messages in thread
From: Sven Wischnowsky @ 2000-02-01 13:07 UTC (permalink / raw)
  To: zsh-workers


Clint Adams wrote:

> This is not an elegant solution.  Of course, I'm not even sure that it works.
> The point is to not segfault after mmap failure.

Hm, I think I prefer this one, it's the same as what we do in zalloc().

Bye
 Sven

diff -ru ../z.old/Src/mem.c Src/mem.c
--- ../z.old/Src/mem.c	Tue Feb  1 12:00:20 2000
+++ Src/mem.c	Tue Feb  1 14:06:53 2000
@@ -356,6 +356,10 @@
 	    n = (n + pgsz) & ~pgsz;
 	    h = (Heap) mmap(NULL, n, PROT_READ | PROT_WRITE,
 			    MMAP_FLAGS, -1, 0);
+	    if (h == ((Heap) -1)) {
+		zerr("fatal error: out of heap memory", NULL, 0);
+		exit(1);
+	    }
 	    h->size = n;
 	}
 #else

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: PATCH: mmap error
  2000-02-01 18:45 ` Peter Stephenson
@ 2000-02-01 20:53   ` Peter Stephenson
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Stephenson @ 2000-02-01 20:53 UTC (permalink / raw)
  To: ZSH-workers

Peter Stephenson wrote:
> The following is basically the same, but more consistent with the other
> allocation failures in mem.c

Sorry, I wrote this yesterday and sent it out without looking at the new
mail.  I've instead applied Sven's patch in 9505, which is the same but
tests for -1 (i.e. MAP_FAILED), which is correct.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: PATCH: mmap error
  2000-01-31 18:35 Clint Adams
@ 2000-02-01 18:45 ` Peter Stephenson
  2000-02-01 20:53   ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Stephenson @ 2000-02-01 18:45 UTC (permalink / raw)
  To: ZSH-workers

Clint Adams wrote:
> This is not an elegant solution.  Of course, I'm not even sure that it works.
> The point is to not segfault after mmap failure.

The following is basically the same, but more consistent with the other
allocation failures in mem.c

--- Src/mem.c.err	Mon Jan 31 20:09:54 2000
+++ Src/mem.c	Mon Jan 31 20:10:40 2000
@@ -356,6 +356,10 @@
 	    n = (n + pgsz) & ~pgsz;
 	    h = (Heap) mmap(NULL, n, PROT_READ | PROT_WRITE,
 			    MMAP_FLAGS, -1, 0);
+	    if (!h) {
+		zerr("fatal error: mmap failed", NULL, 0);
+		exit(1);
+	    }
 	    h->size = n;
 	}
 #else

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH: mmap error
@ 2000-01-31 18:35 Clint Adams
  2000-02-01 18:45 ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Clint Adams @ 2000-01-31 18:35 UTC (permalink / raw)
  To: ZSH-workers

This is not an elegant solution.  Of course, I'm not even sure that it works.
The point is to not segfault after mmap failure.

Index: Src/mem.c
===================================================================
RCS file: /cvs/zsh/zsh/Src/mem.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 mem.c
--- Src/mem.c	2000/01/20 09:01:44	1.1.1.14
+++ Src/mem.c	2000/01/31 18:21:46
@@ -356,6 +356,7 @@
 	    n = (n + pgsz) & ~pgsz;
 	    h = (Heap) mmap(NULL, n, PROT_READ | PROT_WRITE,
 			    MMAP_FLAGS, -1, 0);
+            if(h==-1) { perror("mmap error"); exit;}
 	    h->size = n;
 	}
 #else


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-02-01 20:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-01 13:07 PATCH: mmap error Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
2000-01-31 18:35 Clint Adams
2000-02-01 18:45 ` Peter Stephenson
2000-02-01 20:53   ` Peter Stephenson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).