1:44 a.m.
I see the same backtrace on the second and subsequent times I run
ediff-buffers in b36, when I have my focus-follows-mouse fixes (which
don't quite work yet) applied. Backing them out avoids the assert
fail, but I still get the odd behavior that on the second and
subsequent runs of ediff-buffers, a floating minibuffer-only frame is
created. Any ideas what's up with that? This is with -q, btw.
greg
>>>> "Karl" == Karl M Hegbloom
<karlheg(a)inetarena.com> writes:
Karl>
Karl> opened, when I started an ediff session. I think that may be the
Karl> common thing between this crash and the two others where it bombed
Karl> when I opened up a speedbar frame. Both times there's a minibuffer
Karl> only frame.
Karl>
Karl>
Karl> Fatal error: assertion failed, file specifier.c, line 2451, abort()
3:01 a.m.
New subject: [crash] assertion failed, file specifier.c, line 2451, abort()
Some time ago, Greg Klanderman wrote...
|+
|
| I see the same backtrace on the second and subsequent times I run
| ediff-buffers in b36, when I have my focus-follows-mouse fixes (which
| don't quite work yet) applied. Backing them out avoids the assert
| fail, but I still get the odd behavior that on the second and
| subsequent runs of ediff-buffers, a floating minibuffer-only frame is
| created. Any ideas what's up with that? This is with -q, btw.
|-
Greg,
If you have steady reproduction, please try this. There is
a GC problem which is fixed by this patch; I only wanted to be
sure that all Karl's crashes are really caused by this. I was
not able to reproduce it by normal means.
Kirill
1998-04-24 Kirill M. Katsnelson <kkm(a)kis.ru>
* frame.c (Fmake_frame): GC-protect new frame immediately upon
creation.
Index: src/frame.c
===================================================================
RCS file: /var/cvsroot/ntxemacs/src/frame.c,v
retrieving revision 1.4
diff --unified=2 -r1.4 frame.c
--- src/frame.c 1998/04/05 13:16:54 1.4
+++ src/frame.c 1998/04/23 21:57:46
＠＠ -417,4 +417,5 ＠＠
f = allocate_frame_core (device);
+ XSETFRAME (frame, f);
specbind (Qframe_being_created, name);
＠＠ -446,5 +447,4 ＠＠
signal_simple_error ("Invalid value for `minibuffer'", minibuf);
- XSETFRAME (frame, f);
update_frame_window_mirror (f);
2:44 p.m.
New subject: [crash] assertion failed, file specifier.c, line 2451, abort()
I applied it and the assert fail went away. So I un-applied it and it
is still gone. BTW, is this patch correct in the case that an error
occurs? The XSETFRAME will have taken place, whereas previously it
hadn't?
Anyway, is anyone else seeing the incorrect minibuffer-only frame
creation the second time ediff-buffers is run after xemacs -q?
xemacs -q ; b36
C-x C-f ~/.tcshrc
C-x 2
C-x o
C-x C-f ~/.aliases
C-x o
M-x ediff-buffers
<return> ; accept default buffers
<return>
q
y
M-x ediff-buffers
<return> ; accept default buffers
<return>
You now have a new minibuffer-only frame created, which is a bug.
It does not appear to be an ediff problem as b27 is OK running the
same package path. Now, if you do:
q
y
it signals:
Signaling: (error "Can't expand minibuffer to full frame")
delete-other-windows()
ediff-cleanup-mess()
run-hooks(ediff-cleanup-mess)
ediff-really-quit(nil)
ediff-quit(nil)
call-interactively(ediff-quit)
>>>> "kkm" == Kirill M Katsnelson
<kkm(a)kis.ru> writes:
kkm>
kkm> Some time ago, Greg Klanderman wrote...
kkm> |+
kkm> |
kkm> | I see the same backtrace on the second and subsequent times I run
kkm> | ediff-buffers in b36, when I have my focus-follows-mouse fixes (which
kkm> | don't quite work yet) applied. Backing them out avoids the assert
kkm> | fail, but I still get the odd behavior that on the second and
kkm> | subsequent runs of ediff-buffers, a floating minibuffer-only frame is
kkm> | created. Any ideas what's up with that? This is with -q, btw.
kkm> |-
kkm>
kkm> Greg,
kkm>
kkm> If you have steady reproduction, please try this. There is
kkm> a GC problem which is fixed by this patch; I only wanted to be
kkm> sure that all Karl's crashes are really caused by this. I was
kkm> not able to reproduce it by normal means.
kkm>
kkm> Kirill
kkm>
kkm> 1998-04-24 Kirill M. Katsnelson <kkm(a)kis.ru>
kkm>
kkm> * frame.c (Fmake_frame): GC-protect new frame immediately upon
kkm> creation.
kkm>
kkm> Index: src/frame.c
kkm> ===================================================================
kkm> RCS file: /var/cvsroot/ntxemacs/src/frame.c,v
kkm> retrieving revision 1.4
kkm> diff --unified=2 -r1.4 frame.c
kkm> --- src/frame.c 1998/04/05 13:16:54 1.4
kkm> +++ src/frame.c 1998/04/23 21:57:46
kkm> ＠＠ -417,4 +417,5 ＠＠
kkm>
kkm> f = allocate_frame_core (device);
kkm> + XSETFRAME (frame, f);
kkm>
kkm> specbind (Qframe_being_created, name);
kkm> ＠＠ -446,5 +447,4 ＠＠
kkm> signal_simple_error ("Invalid value for `minibuffer'",
minibuf);
kkm>
kkm> - XSETFRAME (frame, f);
kkm> update_frame_window_mirror (f);
6:29 p.m.
New subject: [crash] assertion failed, file specifier.c, line 2451, abort()
Some time ago, Greg Klanderman wrote...
|+
|
| I applied it and the assert fail went away. So I un-applied it and it
| is still gone. BTW, is this patch correct in the case that an error
| occurs? The XSETFRAME will have taken place, whereas previously it
| hadn't?
Yes it is. XSETFRAME is just an assignment with a cast, plus some extra
error checking in debug build. GC protect stack is unwound on signal.
I have been able to get 100% crashes by adding (garbage-collect) to
make-initial-minibuffer-frame, which is called to create that
floating nimibuffer frame.
Another topic is that this frame should not be created at all...
| Anyway, is anyone else seeing the incorrect minibuffer-only frame
| creation the second time ediff-buffers is run after xemacs -q?
I do on Solaris. Here's a lisp code I used for testing:
(while t
(let ((gc-cons-threshold 1)
f)
(condition-case nil
(progn
(setq f (make-frame '(minibuffer nil)))
(sleep-for 0.5)
(delete-frame f)
(sleep-for 0.5))
(error nil))))
This when run stably caused crashes without my patch, and does not with it.
Although, crash happens not on the first iteration, the range is 2 to 6.
With my patch, after this runs for some time, there are dozens of minibuffer
only frames. delete-frame signals spurious errors that it cannot delete a
frame whose minibuffer is used in another frame.
When I run this in 20.3, no abandoned minibuffers are floating around.
There is no crash, but the setting (gc-cons-threshold 1) does not
work when DEBUG_XEMACS is undefined: it is adjusted to be no less than
15000 or something.
Also, with 21.0, there is the same symptom as Martin seen, lots of these
messages. They are so numerous so only C-\ works in xterm, no luck
with C-g or C-c. This happens spontaneously, and sleep-for calls in
the above code are helping a bit against this flood (but again not
in 100% cases).
This happens both with my patch and without it.
xemacs: X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 61 (X_ClearArea)
Resource id in failed request: 0x0
Serial number of failed request: 3046
Current serial number in output stream: 15281
xemacs: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 70 (X_PolyFillRectangle)
Resource id in failed request: 0x0
Serial number of failed request: 3047
Current serial number in output stream: 15281
Kirill
9709
days inactive
9709
days old
3 comments
2 participants
participants (2)
-
Greg Klanderman -
Kirill M. Katsnelson