Memory errors with Fedora 9 x86_64

Memory errors with Fedora 9 x86_64

[Peter Stephenson]

Having just upgraded to Fedora 9 x86_64 with kernel 2.6.25.3-18.fc9.x86_64
and gcc 4.3.0, I'm getting occasional memory errors when running the
tests with --enable-zsh-mem (which may or may not cause the test to
fail, and are apparently random).  I added the following debugging and the
memory requested doesn't seem out of the ordinary.  Is anyone else
seeing anything similar?

It's possible --enable-zsh-mem has simply had it's day.  I'm not seeing
any errors without that, but it's also possible this is a genuine system
problem.

Index: Src/mem.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/mem.c,v
retrieving revision 1.15
diff -u -r1.15 mem.c
--- Src/mem.c	30 Apr 2007 09:27:23 -0000	1.15
+++ Src/mem.c	17 May 2008 16:22:27 -0000
@@ -958,7 +958,7 @@
 	n = (size + M_HSIZE + M_ALLOC + m_pgsz - 1) & ~(m_pgsz - 1);
 
 	if (((char *)(m = (struct m_hdr *)sbrk(n))) == ((char *)-1)) {
-	    DPUTS(1, "MEM: allocation error at sbrk.");
+	    DPUTS1(1, "MEM: allocation error at sbrk, size %L.", n);
 	    unqueue_signals();
 	    return NULL;
 	}
Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.191
diff -u -r1.191 utils.c
--- Src/utils.c	15 May 2008 15:51:01 -0000	1.191
+++ Src/utils.c	17 May 2008 16:22:30 -0000
@@ -255,6 +255,7 @@
 {
     const char *str;
     int num;
+    long lnum;
 #ifdef HAVE_STRERROR_R
 #define ERRBUFSIZE (80)
     int olderrno;
@@ -286,6 +287,12 @@
 		nicezputs(s, file);
 		break;
 	    }
+#ifdef DEBUG
+	    case 'L':
+		lnum = va_arg(ap, long);
+		fprintf(file, "%ld", lnum);
+		break;
+#endif
 	    case 'd':
 		num = va_arg(ap, int);
 		fprintf(file, "%d", num);


-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Memory errors with Fedora 9 x86_64

[Bart Schaefer]

On May 17,  5:26pm, Peter Stephenson wrote:
}
} It's possible --enable-zsh-mem has simply had it's day.

The only major problem I'd *expect* with zsh-mem is one of getting
the alignment right.  But if that were failing I'd expect the errors
you see to be less random.  Unless you seem to be hitting them most
often in cases where the allocated blocks could be getting entirely
filled up?  Maybe reading/writing part way into the header of the
next (or an unallocated) block?

Although I'd think writing like that would cause a crash in pretty
short order ...

Re: Memory errors with Fedora 9 x86_64

[Phil Pennock]

On 2008-05-17 at 17:26 +0100, Peter Stephenson wrote:
> Having just upgraded to Fedora 9 x86_64 with kernel 2.6.25.3-18.fc9.x86_64
> and gcc 4.3.0, I'm getting occasional memory errors when running the
> tests with --enable-zsh-mem (which may or may not cause the test to
> fail, and are apparently random).  I added the following debugging and the
> memory requested doesn't seem out of the ordinary.  Is anyone else
> seeing anything similar?

Not here, although I am 64-bit.  I'm using FreeBSD 6.2/amd64 and do not
see this; the (IMO) relevant options I set for build are:
  --enable-zsh-mem --enable-zsh-secure-free
  --enable-zsh-debug --enable-zsh-mem-debug
  --enable-multibyte
and gcc is 3.4.6.  If I build with gcc 4.2.4 then the results are
identical.  Tests run eight times (5x gcc3, 3x gcc4) -- are the errors
more occasional than this?

I get one solidly repeatable test failure, working from a fresh CVS
checkout; including it below instead of starting a new thread, in case
it's a sign that I'm not running the tests correctly (I've *cough* never
run them before).  I also, on one iteration of the tests against zsh
built with gcc4 got the second error below; I haven't dug into it, but
it's sleep-based, is it known to be load-sensitive?  Hrm, at the same
time as that failed, the tests against zsh built with gcc3 running in
another pty hung in Y01completion.ztst.  I ended up sending INT and
re-running, the tests ran to completion with only the by-now-expected
error shown.

Some blockdevice and /dev/fd/0 tests were skipped.

-Phil

Every test run (except the one which hung during this test file):
----------------------------8< cut here >8------------------------------
./Y01completion.ztst: starting.
*** /tmp/zsh.ztst.out.89827     Mon May 19 00:22:41 2008
--- /tmp/zsh.ztst.tout.89827    Mon May 19 00:22:41 2008
***************
*** 1,12 ****
  line: {: }{}
  DESCRIPTION:{file}
  DI:{dir1}
  DI:{dir2}
  FI:{file1}
  FI:{file2}
  line: {: dir1/}{}
  line: {: dir2/}{}
  line: {: file1}{}
  line: {: file2}{}
! line: {: dir1/}{}
! line: {: dir2/}{}
--- 1,13 ----
  line: {: }{}
  DESCRIPTION:{file}
+ FI:{compinit.dump}
  DI:{dir1}
  DI:{dir2}
  FI:{file1}
  FI:{file2}
+ line: {: compinit.dump}{}
  line: {: dir1/}{}
  line: {: dir2/}{}
  line: {: file1}{}
  line: {: file2}{}
! line: {: compinit.dump}{}
Test ./Y01completion.ztst failed: output differs from expected as shown above for:
  comptest $': \t\t\t\t\t\t\t'
Was testing: directories and files
----------------------------8< cut here >8------------------------------

Once:
----------------------------8< cut here >8------------------------------
./C03traps.ztst: starting.
This test takes at least three seconds...
*** /tmp/zsh.ztst.out.26737     Mon May 19 00:33:52 2008
--- /tmp/zsh.ztst.tout.26737    Mon May 19 00:33:52 2008
***************
*** 1 ****
- TERM2
--- 0 ----
Test ./C03traps.ztst failed: output differs from expected as shown above for:
  print -u $ZTST_fd 'This test takes at least three seconds...'
  fn1() {
    trap 'print TERM1' TERM
    fn2() { trap 'print TERM2; return 1' TERM; sleep 2; }
    fn2 &
    sleep 1
    kill -TERM $!
    sleep 2
  }
  fn1
Was testing:  Nested `trap ... TERM', triggered on inner loop
./C03traps.ztst: test failed.
----------------------------8< cut here >8------------------------------

Re: Memory errors with Fedora 9 x86_64

[Peter Stephenson]

Phil Pennock wrote:
> I get one solidly repeatable test failure, working from a fresh CVS
> checkout; including it below instead of starting a new thread, in case
> it's a sign that I'm not running the tests correctly (I've *cough* never
> run them before).

That was a typo that I've fixed.

> I also, on one iteration of the tests against zsh
> built with gcc4 got the second error below; I haven't dug into it, but
> it's sleep-based, is it known to be load-sensitive?

Yes, tests like this are definitely problematic and could do with a rethink.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070