Fabrice POPINEAU wrote: > > I have reported a crash with 21.0b46 native under NT. In fact, this > happens constantly when using Gnus. The crash happens in gc, sometimes > very quickly, and it seems that some : > > struct string_chars > { > struct Lisp_String *string; > unsigned char chars[1]; > }; > > is overwritten with data : [snip] I've been looking at this bug, but havn't made much progress. This is what I've found out so far: The bug isn't gnus-specific, but gnus seems to trigger it more often than anything else, usually in a call to delete-window or delete-other-windows. This is the same bug that Kirill reported in his message "[CRASH] in GC, in compact_string_chars()" to xemacs-beta back on 980428. It looks like a gc bug but it is actually a redisplay bug. The bug occurs during modeline frobbing in generate_formatted_string_db() when called by generate_modeline(). In detail: generate_formatted_string_db() calls generate_fstring_runes() to build up a set of runes in the modeline display block. Usually when generate_fstring_runes() finally returns Dynarr_length(db->runes) == data.bytepos, or 1+data.bytepos if the gnus pixmap is present in the modeline. However, very occasionally, Dynarr_length(db->runes) >> data.bytepos. I don't know why. data.bytepos is used in a call to resize_string() at line 3597 in generate_formatted_string_db() to resize the modeline string, but the string is filled with ~Dynarr_length(db->runes) characters. When Dynarr_length(db->runes) >> data.bytepos, the modeline string overflows and trashes the next string in its string block. This is noticed and generates an assertion failure next time gc happens, if the trashed string_chars struct hasn't happened to have been subsequently freed. It looks like something is going wrong and pos is getting too large in generate_fstring_runes(), but I'm having problems finding out exactly what causes this. Jonathan. -- Jonathan Harris | jhar(a)tardis.ed.ac.uk London, England | Jonathan.Harris(a)symbian.com