Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)

Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)

[C. v. Stuckrad]

Hi!

We had a case of very strange core dumps here:
I compiled 3.0.2 with gcc 2.7.2 on a SUN Sparc10(sun4m) SunOS 4.1.3.
This SUN exports all its Filesystems (except the root) to another
'sun4m' with a slightly different CPU (faster, more cache on chip).

On this 'second' machine contrary to the identical setup and type of
machine this zsh coredumps during it's startup!

By debugging with gdb we found out the following things:
((The coredump is in 'global_permalloc()' and this is in 'mem.c',
  so I recompiled main.c and mem.c with '-O2 -g'. The error persisted))

.......................................................................
# gdb /usr/local/src/zsh-3.0.2/Src/zsh
.......................................................................
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Program received signal SIGSEGV (11), Segmentation fault
0x2cb58 in global_permalloc () at mem.c:124
124     }
(gdb) list
119
120         alloc = zcalloc;
121         ncalloc = zalloc;
122         useheap = 0;
123         return luh;
124     }
......................................... lines deleted ..........
Now STEPPING through the routine IT WORKS:
(see the optimized order of statements)
..................................................................
Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) s
46          global_permalloc();
(gdb) s
global_permalloc () at mem.c:120
120         alloc = zcalloc;
(gdb) s
118         int luh = useheap;
(gdb) s
121         ncalloc = zalloc;
(gdb) s
124     }
(gdb) s
main (argc=1, argv=0xeffff6ec) at init.c:48
48          for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);
(gdb) s
50          if (!(zsh_name = strrchr(argv[0], '/')))
(gdb) c
Continuing.
(SU)@kowalewsky:[1025](/)> q                                        (0)19:25:48

Program exited normally.
....................................... here we had a 'normal' zsh
BUT 'RUNNING' through the same code gets coredumped :-))
...................................................................
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) c
Continuing.

Program received signal SIGSEGV (11), Segmentation fault
.................................................................
Well, now I UN-Optimized 'mem.c', and (so far) the error was gone
Now stepping shows the 'original' routine:
.................................................................

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) s
46          global_permalloc();
(gdb) s
global_permalloc () at mem.c:118
118         int luh = useheap;
(gdb) s
120         alloc = zcalloc;
(gdb) s
121         ncalloc = zalloc;
(gdb) s
122         useheap = 0;
(gdb) s
123         return luh;
(gdb) s
124     }
(gdb) s
................................................................ END

I know that the 'value' of this, for the development of the zsh is nil,
but I wanted to let you all know, that the zsh is the first program I've
ever seen, which tricked one 'SPECIFIC' CPU into coredumping :-))

Your's   Stucki

Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /


>From stucki@math.fu-berlin.de Mon Jan 13 15:57:00 1997
From: "C. v. Stuckrad" <stucki@math.fu-berlin.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Noch seltsamer (zsh@kowalewsky)
To: Rene Mueller <rene@math.fu-berlin.de>
Date: Thu, 9 Jan 1997 19:34:07 +0100 (MET)



Der OPTIMIZER isses (zumindest 'auch')

# gdb /usr/local/src/zsh-3.0.2/Src/zsh
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.11 (sparc-sun-sunos4.1.3),
Copyright 1993 Free Software Foundation, Inc...
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Program received signal SIGSEGV (11), Segmentation fault
0x2cb58 in global_permalloc () at mem.c:124
124     }
(gdb) list
119
120         alloc = zcalloc;
121         ncalloc = zalloc;
122         useheap = 0;
123         return luh;
124     }
125
126     /* heappush saves the current heap state using this structure */
127
128     struct heapstack {
(gdb) c
Continuing.

Program terminated with signal SIGSEGV (11), Segmentation fault
The program no longer exists.
(gdb) file /usr/local/src/zsh-3.0.2/Src/zsh
Load new symbol table from "/usr/local/src/zsh-3.0.2/Src/zsh"? (y or n) y
Reading symbols from /usr/local/src/zsh-3.0.2/Src/zsh...done.
(gdb) b main
Breakpoint 1 at 0x2236c: file init.c, line 43.
(gdb) s
The program is not being run.
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) s
46          global_permalloc();
(gdb) s
global_permalloc () at mem.c:120
120         alloc = zcalloc;
(gdb) s
118         int luh = useheap;
(gdb) s
121         ncalloc = zalloc;
(gdb) s
124     }
(gdb) s
main (argc=1, argv=0xeffff6ec) at init.c:48
48          for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);
(gdb) s
50          if (!(zsh_name = strrchr(argv[0], '/')))
(gdb) c
Continuing.
(SU)@kowalewsky:[1025](/)> q                                        (0)19:25:48

Program exited normally.
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) c
Continuing.

Program received signal SIGSEGV (11), Segmentation fault
0x2cb58 in global_permalloc () at mem.c:124
124     }
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) s
46          global_permalloc();
(gdb) s
global_permalloc () at mem.c:120
120         alloc = zcalloc;
(gdb) s
118         int luh = useheap;
(gdb) s
121         ncalloc = zalloc;
(gdb) s
124     }
(gdb) s
main (argc=1, argv=0xeffff6ec) at init.c:48
48          for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);
(gdb) c
Continuing.
(SU)@kowalewsky:[1025](/)> q                                        (0)19:26:13

Program exited normally.
(gdb) file /usr/local/src/zsh-3.0.2/Src/zsh
Load new symbol table from "/usr/local/src/zsh-3.0.2/Src/zsh"? (y or n) y
Reading symbols from /usr/local/src/zsh-3.0.2/Src/zsh...done.
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh
main (argc=1, argv=0xeffff6ec) at init.c:48
48          for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);
(gdb) c
Continuing.
(SU)@kowalewsky:[1025](/)> q                                        (0)19:29:09

Program exited normally.
(gdb) r
Starting program: /usr/local/src/zsh-3.0.2/Src/zsh

Breakpoint 1, main (argc=1, argv=0xeffff6ec) at init.c:43
43          setlocale(LC_ALL, "");
(gdb) c
Continuing.
(SU)@kowalewsky:[1025](/)> q                                        (0)19:29:15

Program exited normally.
(gdb)


Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /

Strange coredump of zsh-3.0.2 (duplicated Lines, pleas excuse)

[C. v. Stuckrad]

On Mon, 13 Jan 1997, C. v. Stuckrad wrote:

> We had a case of very strange core dumps here:
> I compiled 3.0.2 with gcc 2.7.2 on a SUN Sparc10(sun4m) SunOS 4.1.3.
.... long explanation ...
> Your's   Stucki
...signature...
> >From stucki@math.fu-berlin.de Mon Jan 13 15:57:00 1997
> From: "C. v. Stuckrad" <stucki@math.fu-berlin.de>
...signature...

Sorry, the Inhouse-Version of the mail was left 'trailing' after my
signature, please ignore the waste of bandwidth...
							Stucki

Re: Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)

[Bart Schaefer]

On Jan 13,  4:17pm, C. v. Stuckrad wrote:
} Subject: Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)
}
} We had a case of very strange core dumps here:
} I compiled 3.0.2 with gcc 2.7.2 on a SUN Sparc10(sun4m) SunOS 4.1.3.
} This SUN exports all its Filesystems (except the root) to another
} 'sun4m' with a slightly different CPU (faster, more cache on chip).
} 
} On this 'second' machine contrary to the identical setup and type of
} machine this zsh coredumps during it's startup!
} 
} .................................................................
} Well, now I UN-Optimized 'mem.c', and (so far) the error was gone

Sounds like incompatible versions of dynamically-loaded libc, to me.
Are you sure that all the .so that zsh is loading are the same version
on both machines?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)

[C. v. Stuckrad]

On Mon, 13 Jan 1997, Bart Schaefer wrote:

> On Jan 13,  4:17pm, C. v. Stuckrad wrote:
> } Well, now I UN-Optimized 'mem.c', and (so far) the error was gone
> 
> Sounds like incompatible versions of dynamically-loaded libc, to me.
> Are you sure that all the .so that zsh is loading are the same version
> on both machines?

As only the root is different, and thereon are no libraries,
the complete structure of all files must be absolutely identical!
The 'second' machine mounts the whole system from the 'first'
(on which zsh was configured and compiled :-)

Stucki

Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /