* Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)
@ 1997-01-13 15:17 C. v. Stuckrad
1997-01-13 15:26 ` Strange coredump of zsh-3.0.2 (duplicated Lines, pleas excuse) C. v. Stuckrad
1997-01-13 18:44 ` Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) Bart Schaefer
0 siblings, 2 replies; 4+ messages in thread
From: C. v. Stuckrad @ 1997-01-13 15:17 UTC (permalink / raw)
To: Zsh workers list
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 /
^ permalink raw reply [flat|nested] 4+ messages in thread
* Strange coredump of zsh-3.0.2 (duplicated Lines, pleas excuse)
1997-01-13 15:17 Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) C. v. Stuckrad
@ 1997-01-13 15:26 ` C. v. Stuckrad
1997-01-13 18:44 ` Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) Bart Schaefer
1 sibling, 0 replies; 4+ messages in thread
From: C. v. Stuckrad @ 1997-01-13 15:26 UTC (permalink / raw)
To: Zsh workers list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)
1997-01-13 15:17 Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) C. v. Stuckrad
1997-01-13 15:26 ` Strange coredump of zsh-3.0.2 (duplicated Lines, pleas excuse) C. v. Stuckrad
@ 1997-01-13 18:44 ` Bart Schaefer
1997-01-14 11:20 ` C. v. Stuckrad
1 sibling, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 1997-01-13 18:44 UTC (permalink / raw)
To: C. v. Stuckrad, Zsh workers list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs)
1997-01-13 18:44 ` Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) Bart Schaefer
@ 1997-01-14 11:20 ` C. v. Stuckrad
0 siblings, 0 replies; 4+ messages in thread
From: C. v. Stuckrad @ 1997-01-14 11:20 UTC (permalink / raw)
To: schaefer; +Cc: Zsh workers list
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 /
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1997-01-14 11:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-01-13 15:17 Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) C. v. Stuckrad
1997-01-13 15:26 ` Strange coredump of zsh-3.0.2 (duplicated Lines, pleas excuse) C. v. Stuckrad
1997-01-13 18:44 ` Strange coredump of zsh-3.0.2 (gcc optimizer/two different CPUs) Bart Schaefer
1997-01-14 11:20 ` C. v. Stuckrad
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).