1:39 p.m.
Andy Piper <andy(a)xemacs.org> writes:
So I fixed up my linux box properly and read news for an hour with
the
current CVS, I played with vm, I switched windows, created and deleted
frames etc, etc and still no crash. Maybe there is some gnus-crash-xemacs-p
variable that I haven't set?
I cannot really try to give a recipe from "xemacs -vanilla" as it is
too risky too mess up my Gnus setup (maybe I need to create a new user
for doing that).
However I lied before. It definitely is garbage collection related..
Starting up Gnus with my sledge hammer checks gives...
#3 0x80bc85b in assert_failed (file=0x8246c50 "glyphs.c", line=638,
expr=0x8246d1d "found_in_cache") at emacs.c:3114
#4 0x8141682 in check_image_instance_in_window_cache (instance=140646640)
at glyphs.c:638
#5 0x8141818 in check_subwindow_instance_caches () at glyphs.c:656
#6 0x8087deb in garbage_collect_1 () at alloc.c:3567
#7 0x80c0bc2 in Feval (form=140525488) at eval.c:2938
#8 0x8173ecc in readevalloop (readcharfun=140228928, sourcename=137975524,
evalfun=0x80c08c8 <Feval>, printflag=0) at lread.c:1448
#9 0x8172a3f in Fload_internal (file=137975524, no_error=1078779856,
nomessage=1078779184, nosuffix=1078779856, codesys=1078706704,
used_codesys=1078779856) at lread.c:736
alloc.c:3567 is the check at the _end_ of g_c_1...
This means that the item was still in the frame weak list, but removed
from the window specific weak hash table...
hmmmm....
Anybody got an idea how to debug weak hash tables and lists?
Jan
2:55 p.m.
New subject: set-window-configuration vs error-checking sub windows
At 01:39 PM 5/26/00 +0100, Jan Vroonhof wrote:
However I lied before. It definitely is garbage collection related..
Starting up Gnus with my sledge hammer checks gives...
#3 0x80bc85b in assert_failed (file=0x8246c50 "glyphs.c", line=638,
expr=0x8246d1d "found_in_cache") at emacs.c:3114
I can reproduce this, I've tried various things but still no cigar. I'll
try on my linux box a bit later.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
5:45 p.m.
New subject: set-window-configuration vs error-checking sub windows
At 01:39 PM 5/26/00 +0100, Jan Vroonhof wrote:
However I lied before. It definitely is garbage collection related..
Here's what I think is happening. The instantiator changes due to someone
clicking on a tab, since the window hashtable is key weak once the old
instantiator is unreferenced the image instance is unreferenced also. Thus
it gets removed from the weak hashtable, however Ben's callback changes
mean that an instance can still be referenced from last-command-event so
the instance itself is not deleted and remains in the frame cache. Hence
the inconsistencies we are seeing.
If we make the hastable fully weak then we don't get any caching. If we
make the hashtable value weak we don't get any caching. It would be nice if
there was a hook in the hashtables that allowed you to do something when
something was removed. If we make the hashtable non-weak then we have no
way of removing instances except when the domain gets deleted - although
maybe this is an ok stratgey.
Maybe we need a new kind of weak hashtable - where the pair get removed
only if both the key and the value are unmarked.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8:32 p.m.
New subject: set-window-configuration vs error-checking sub windows
On Fri, May 26, 2000 at 05:45:57PM +0100, Andy Piper wrote:
It would be nice if
there was a hook in the hashtables that allowed you to do something when
something was removed.
[...]
Maybe we need a new kind of weak hashtable - where the pair get
removed
only if both the key and the value are unmarked.
Pick one.
OG.
9:42 a.m.
New subject: set-window-configuration vs error-checking sub windows
At 03:32 PM 5/26/00 -0400, Olivier Galibert wrote:
On Fri, May 26, 2000 at 05:45:57PM +0100, Andy Piper wrote:
> It would be nice if
> there was a hook in the hashtables that allowed you to do something when
> something was removed.
[...]
> Maybe we need a new kind of weak hashtable - where the pair get removed
> only if both the key and the value are unmarked.
Pick one.
The second.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
3:15 p.m.
New subject: set-window-configuration vs error-checking sub windows
On Sat, May 27, 2000 at 09:42:24AM +0100, Andy Piper wrote:
>> Maybe we need a new kind of weak hashtable - where the pair
get removed
>> only if both the key and the value are unmarked.
Here you are. Minimally tested, but of the obviously correct kind.
OG.
2000-05-29 Olivier Galibert <galibert(a)pobox.com>
* lisp.h: Add Qfull_assoc symbol and WEAK_LIST_FULL_ASSOC
constant.
* general.c (syms_of_general): Add Qfull_assoc symbol.
* data.c (finish_marking_weak_lists): Mark full-assoc lists
correctly.
(decode_weak_list_type): Decode full-assoc type.
(encode_weak_list_type): Encode full-assoc type.
(Fmake_weak_list): Update doc string.
9:18 a.m.
New subject: set-window-configuration vs error-checking sub windows
At 10:15 AM 5/29/00 -0400, Olivier Galibert wrote:
On Sat, May 27, 2000 at 09:42:24AM +0100, Andy Piper wrote:
> >> Maybe we need a new kind of weak hashtable - where the pair get removed
> >> only if both the key and the value are unmarked.
Here you are. Minimally tested, but of the obviously correct kind.
Except that you've done it for a list rather than a hastable ..... :)
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8942
days inactive
8946
days old
6 comments
4 participants
participants (4)
-
Andy Piper -
Andy Piper -
Jan Vroonhof -
Olivier Galibert