Re: 21.2.34 crash in Gnus
23 years, 10 months
Jan Vroonhof
Jan Vroonhof
Pekka Marjola <pema(a)iki.fi> writes:
> Fatal error: assertion failed, file glyphs.c, line 590, DOMAIN_LIVE_P (instance)
Andy and I nailed this one finally. Either update from CVS,
xemacs-patches archive or from
Andy's recent message to Raymon Toy?
Jan
P.S. Martin , how about making a new 21.2 release, just for this. It
makes the betas useful again for a lot of people!
- 1 participants
- 0 comments
21.2.34 crash in Gnus
23 years, 10 months
Pekka Marjola
Pekka Marjola
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
In XEmacs 21.2 (beta34) "Molpe" [Lucid] (i686-pc-linux) of Wed May 31 2000 on gato
configured using `configure --without-wmcommand --prefix=/usr/local/pema/xemacs-21.2.34 --with-athena=xaw --package-path=/usr/share/xemacs21/packages --with-postgresql=no'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
Fatal error: assertion failed, file glyphs.c, line 590, DOMAIN_LIVE_P (instance)
Fatal error (6).
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# bind (inhibit-quit)
set-window-configuration(#<window-configuration 0xb42e>)
# bind (found-start found-point inhibit-quit edit nopush)
isearch-done()
isearch-pre-command-hook()
# (condition-case ... . error)
# (condition-case ... . error)
# (catch top-level ...)
[2] - 26000 abort (core dumped) xemacs -xrm "*Desk: 1" -f gnus
gato ~ % gdb /usr/local/src/xemacs/xemacs-21.2.34/src/xemacs core
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `xemacs -xrm *Desk: 1 -f gnus'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/X11R6/lib/libXm.so.1...done.
Reading symbols from /usr/lib/libtiff.so.3...done.
Reading symbols from /usr/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /usr/lib/libcompface.so.1...done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libncurses.so.5...done.
Reading symbols from /usr/lib/libesd.so.0...done.
Reading symbols from /usr/lib/libaudiofile.so.0...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_dns.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libnss_compat.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libnss_db.so.2...done.
#0 0x403ea931 in kill () from /lib/libc.so.6
(gdb) where
#0 0x403ea931 in kill () from /lib/libc.so.6
#1 0x80af653 in fatal_error_signal (sig=6) at emacs.c:514
#2 0x403ea868 in sigaction () from /lib/libc.so.6
#3 0x403ebc71 in abort () from /lib/libc.so.6
#4 0x80b222b in assert_failed (file=0x8209430 "glyphs.c", line=590,
expr=0x82094e4 "DOMAIN_LIVE_P (instance)") at emacs.c:3114
#5 0x811af54 in check_image_instance_structure (instance=148351640)
at glyphs.c:590
#6 0x8123239 in unmap_subwindow (subwindow=148351640) at glyphs.c:4425
#7 0x8122dc0 in reset_frame_subwindow_instance_cache (f=0x8543650)
at glyphs.c:4193
#8 0x81c14a4 in Fset_window_configuration (configuration=148705592)
at window.c:5222
#9 0x80b7557 in Ffuncall (nargs=2, args=0xbfffec58) at eval.c:3214
#10 0x808fac7 in execute_optimized_program (
program=0x9027fe0 "À\031\n«)Ã\n!«$r\nq\210Ä\025ÆÇÈ\"\210É\016\nÄ\"\210Ä\026\013Ì \210Í \210Î \210ÏÄ\211\"\210)ÐÑ !`\036\022\036\023Ô \016\025a«\030Ö\016\027!\210\016\030«\a\016\022b\210ª\tÙÑ \016\023À#\210Ã\n!« Ú\n!\016\eU¬\030Ü\016\eÀÄ\n$\210\016\035¬\fÞ ßV¬\006àáâ\"\210*Ä\022)\016#GßV«\f\016$¬\bå\016#\016&\"\210çè!\210\016)?\a\016*\003ë \207", stack_depth=5, constants_data=0x83eeeb0)
at bytecode.c:747
#11 0x808f719 in funcall_compiled_function (fun=138284628, nargs=0,
args=0xbfffedac) at bytecode.c:519
#12 0x80b76ff in Ffuncall (nargs=1, args=0xbfffeda8) at eval.c:3249
#13 0x808fac7 in execute_optimized_program (
program=0x8dc2668 "p\ba¬\013Á \210ÂÃ !\211\024\207Å \210\f\b\f9\004\fÆN?\003Á \207", stack_depth=2, constants_data=0x83f3d08) at bytecode.c:747
#14 0x808f719 in funcall_compiled_function (fun=138343920, nargs=0,
args=0xbfffef7c) at bytecode.c:519
#15 0x80b76ff in Ffuncall (nargs=1, args=0xbfffef78) at eval.c:3249
#16 0x80b886d in run_hook_with_args_in_buffer (buf=0x8dc75f8, nargs=1,
args=0xbfffef78, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3693
---Type <return> to continue, or q <return> to quit---
#17 0x80bbf7e in run_hook_with_args (nargs=1, args=0xbfffef78,
cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3713
#18 0x80bda0d in catch_them_squirmers_run_hook (hook_symbol=136901476)
at eval.c:3567
#19 0x80b9391 in safe_run_hook_trapping_errors (
warning_string=0x81ff1a0 "Error in `pre-command-hook' (setting hook to nil)", hook_symbol=136901476, allow_quit=1) at eval.c:1640
#20 0x80eb785 in pre_command_hook () at event-stream.c:3887
#21 0x80e91a2 in execute_command_event (command_builder=0x84a18d0,
event=152126728) at event-stream.c:3829
#22 0x80e9c0d in Fdispatch_event (event=152126728) at event-stream.c:4205
#23 0x8098ee3 in Fcommand_loop_1 () at cmdloop.c:579
#24 0x809916e in command_loop_1 (dummy=136811892) at cmdloop.c:494
#25 0x80bcb92 in condition_case_1 (handlers=136811988,
bfun=0x8099134 <command_loop_1>, barg=136811892,
hfun=0x80991dc <cmd_error>, harg=136811892) at eval.c:1640
#26 0x80992cf in command_loop_2 (dummy=136811892) at cmdloop.c:256
#27 0x80bca5c in internal_catch (tag=136883652,
func=0x8099290 <command_loop_2>, arg=136811892, threw=0x0) at eval.c:1306
#28 0x809881a in initial_command_loop (load_me=136811892) at cmdloop.c:305
#29 0x80b0562 in xemacs_21_2_b34_i686_pc_linux () at emacs.c:2146
#30 0x80b244b in main () at emacs.c:2575
#31 0x403e4a42 in __libc_start_main () from /lib/libc.so.6
(gdb) quit
gato ~ %
--
Pekka.Marjola(a)nixu.fi * http://www.nixu.fi * +358-40-551 4842
pema-init-0.15 ＠ http://www.nixu.fi/~pema/emacs/
- 1 participants
- 0 comments
Re: Better toolbar button descriptions (was Re: question about the new widget/glyph code...)
23 years, 10 months
James N. Potts
James N. Potts
James N. Potts <jpmail(a)limolink.com> writes:
>>Andy Piper <andy(a)xemacs.org> writes:
>>
>>> At 09:22 PM 5/29/00 -0500, William M. Perry wrote:
>>> >so, since the widgets are glyphs, and glyphs go in toolbars, would I be
>>> >able to put a text-entry or combo-box into the toolbar now?
>>>
>>> Theory says yes. Reality says no because for windows at least its down
to
>>> the supported button types. It might work under X though. This is the
>>> problem with working with native widgets - lowest common denominator and
>>> all that.
>>>
>>Oh, windows doesn't let you stick arbitrary widgets into the toolbar? Hrm.
>
>Actually, I believe it does. At least, I've stuck arbitrary controls into
a
>native Win32 toolbar in Delphi programs, but I haven't dug into the Delphi
>source to see how it achieves it. Delphi wraps the Win32 Common Controls,
>so you can just plop controls onto the toolbar at designtime.
>
>From the look of it, it just creates the arbitrary control using the
toolbar
>as the control's parent window. Out of curiosity, I'll dig into it.
Windows sortof supports this. The tricky part is getting the toolbar
buttons to line up with the arbitrary widget:
You add a separator to the toolbar of the width that you want your widget to
be, and in the location that you it to be. You then create whatever widget
you like, setting its parent window to be the toolbar, and its bounds to be
the bounds of the separator.
Given toolbar handle "bar" the following creates a text box inside a
toolbar:
(translated from pascal in my head, so it probably doesn't compile)
TBBUTTON tb;
RECT r;
int i;
tb.iBitmap = 100; // The width goes in the bitmap field.
// Of course! It's so obvious!
tb.idCommand = 123;
tb.fsState = 0;
tb.fsStyle = TBSTYLE_SEP;
tb.dwData = 0;
tb.iString = 0;
SendMessage(bar, TB_ADDBUTTONS, 1, &tb);
i = SendMessage(bar, TB_COMMANDTOINDEX, 123, 0);
SendMessage(bar, TB_GETITEMRECT, i, &r);
h = CreateWindow('EDIT','Foobar', WS_CHILD | WS_VISIBLE | WS_BORDER,
r.left, r.top, r.right - r.left, r.bottom - r.top,
bar, 0, instance, NULL);
The only hard part after this is to catch any button order updates, and
change the bounds of the widget so that it stays "on top of" the separator.
A smart programmer (unlike me) would store the handle in the dwData field
(or in a structure pointed to by the dwData field) for easy reference.
-Jim
- 1 participants
- 0 comments
Re: Better toolbar button descriptions (was Re: question about the new widget/glyph code...)
23 years, 10 months
James N. Potts
James N. Potts
-----Original Message-----
From: William M. Perry <wmperry(a)aventail.com>
To: Andy Piper <andy(a)xemacs.org>
Cc: xemacs-beta(a)xemacs.org <xemacs-beta(a)xemacs.org>
Date: Wednesday, May 31, 2000 5:35 PM
Subject: Better toolbar button descriptions (was Re: question about the new
widget/glyph code...)
>Andy Piper <andy(a)xemacs.org> writes:
>
>> At 09:22 PM 5/29/00 -0500, William M. Perry wrote:
>> >so, since the widgets are glyphs, and glyphs go in toolbars, would I be
>> >able to put a text-entry or combo-box into the toolbar now?
>>
>> Theory says yes. Reality says no because for windows at least its down to
>> the supported button types. It might work under X though. This is the
>> problem with working with native widgets - lowest common denominator and
>> all that.
>>
>> The combo-box style is a specific toolbar style I think, we would have to
>> fix up the code to cope. MIght not be too hard though ...
>
>Oh, windows doesn't let you stick arbitrary widgets into the toolbar? Hrm.
Actually, I believe it does. At least, I've stuck arbitrary controls into a
native Win32 toolbar in Delphi programs, but I haven't dug into the Delphi
source to see how it achieves it. Delphi wraps the Win32 Common Controls,
so you can just plop controls onto the toolbar at designtime.
>From the look of it, it just creates the arbitrary control using the toolbar
as the control's parent window. Out of curiosity, I'll dig into it.
-Jim
- 1 participants
- 0 comments