1:04 p.m.
Justin Vallon <vallon(a)mindspring.com> writes:
I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets
dumped.
However, when src/xemacs is first run (as part of lisp shadows), it hangs,
and can't be interrupted, killed, or kill -9'ed.
If I run it from gdb (gdb ./xemacs CR run), it works.
If I use dde:
(Warning) Object file
"/var/tmp/vallon/public/xemacs-21.1/xemacs-21.1.2/src/xemacs" has no debug
information.
Could you compile with debugging enabled (i.e. -g), so that you can
use the debugger where to see where it is hanging?
(BTW if it cannot be KILL -9'ed (assuming -9 is SIGKILL) then that is
also an OS problem.)
Is the "Should XEmacs use the GNU version of malloc?" ok to
be
yes, if using the native compiler?
Yes.
Anything else to try?
Jan
6:56 a.m.
New subject: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20
Jan Vroonhof writes:
| Justin Vallon <vallon(a)mindspring.com> writes:
|
| > I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets dumped.
| > However, when src/xemacs is first run (as part of lisp shadows), it hangs,
| > and can't be interrupted, killed, or kill -9'ed.
Just another compile failed on HP-UX 10.20. We are seeing a bunch of
these unfortunately.
| (BTW if it cannot be KILL -9'ed (assuming -9 is SIGKILL) then that is
| also an OS problem.)
Hm, not neccessarily! Well, depending on the machine state it can take
a while before a SIGKILL gets delivered to a process. But there is
another possibility. A process can be in a high priority sleep
(usually use when the process waits very very short time on
IO). Signals don't get delivered to a process who is currently in that
state. If the process is blocked on that particular IO you cannot
SIGKILL it.
| Anything else to try?
Maybe force --with-dynamic to be yes.
11:09 a.m.
New subject: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20
On 31 May 1999, Jan Vroonhof wrote:
Justin Vallon <vallon(a)mindspring.com> writes:
> I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets dumped.
> However, when src/xemacs is first run (as part of lisp shadows), it hangs,
> and can't be interrupted, killed, or kill -9'ed.
>
>
> If I run it from gdb (gdb ./xemacs CR run), it works.
>
> If I use dde:
>
> (Warning) Object file
> "/var/tmp/vallon/public/xemacs-21.1/xemacs-21.1.2/src/xemacs" has no
debug
> information.
Could you compile with debugging enabled (i.e. -g), so that you can
use the debugger where to see where it is hanging?
./configure --cflags -g --compiler cc
Same problem: src/xemacs hangs, can't be kill -KILL'ed. dde won't even
start (complaining about a bad virtual address), just as with -O.
Anything else to try?
21.1.1 (the only real change was the version number): Same problem. Also
failed with --dynamic=yes.
21.0.67. (Very verbose) Without dynamic: failed. With --dynamic=yes:
failed.
I'll have to go and check out some of the recent build successes more
carefully.
It may also be an OS patch-level problem. We've had some difficulties
between purify and dld (patches), though kill -9 always worked.
-Justin
vallon(a)mindspring.com
12:24 p.m.
New subject: [21.1.2] Problems running dumped xemacs on hppa1.1-hp-hpux10.20
On 31 May 1999, Jan Vroonhof wrote:
Justin Vallon <vallon(a)mindspring.com> writes:
> I'm trying to build 21.1.2 on HP using HP's cc. xemacs gets dumped.
> However, when src/xemacs is first run (as part of lisp shadows), it hangs,
> and can't be interrupted, killed, or kill -9'ed.
>
>
> If I run it from gdb (gdb ./xemacs CR run), it works.
>
> If I use dde:
>
> (Warning) Object file
> "/var/tmp/vallon/public/xemacs-21.1/xemacs-21.1.2/src/xemacs" has no
debug
> information.
Could you compile with debugging enabled (i.e. -g), so that you can
use the debugger where to see where it is hanging?
Ok. ./configure --compiler cc --cflags -g.
xdb... step step step... I'm not sure what this means, but alloca_array
is messing up (xdb's perception of?) the stack:
src/bytecode.c:
297: stackp = alloca_array (Lisp_Object, XINT (maxdepth));
298: memset (stackp, 0, XINT (maxdepth) * sizeof (Lisp_Object));
t 10
0 Fbyte_code (bytestr = 1611101228, vector = -2146994976,
maxdepth = 6) [bytecode.c: 297]
1 funcall_lambda (fun = 537360036, nargs = 0, arg_vector = 0x7b03b440) [eval.c: 3597]
2 apply_lambda (fun = 537360036, numargs = 0, unevalled_args = -1609510908) [eval.c:
3501]
3 Feval (form = 1075507092) [eval.c: 3067]
4 condition_case_1 (handlers = -1609510812, bfun = 0x400d7cca, barg = 1075507092, hfun =
0x400d7e52, harg = -1609510908) [eval.c: 1653]
5 top_level_1 (dummy = -1609510908) [cmdloop.c: 206]
6 internal_catch (tag = -1609433260, func = 0x400d7e62, arg = -1609510908, threw =
00000000) [eval.c: 1328]
7 initial_command_loop (load_me = -1609510908) [cmdloop.c: 290]
8 xemacs_21_1_p2_hppa1_1_hp_hpux10_20 (argc = 0, argv = 00000000, envp = 00000000,
restart = 0) [emacs.c: 1708]
9 _end + 0x3af360ec (0, 0, 0, 0)
s ; t 10
0 Fbyte_code (bytestr = 0, vector = 0, maxdepth = 0)
[bytecode.c: 298]
1 TMEM(a)libc.1 + 0x0011a53c (0, 0, 0, 0)
2 DMEM(a)libc.1 + 0x0000a918 (Bad access to child process (UE308)
This step single-stepped over the alloca_array. Maybe the debugger is
(just) not handling the alloca correctly.
-Justin
vallon(a)mindspring.com
9095
days inactive
9096
days old
3 comments
3 participants
participants (3)
-
Jan Vroonhof -
Justin Vallon -
Marcus Thiessel