* Re: VM crashes on big INBOX file ==> problem found!!! [not found] ` <yoruabq6icer.fsf_-_@AFTERRDOUBT-LX.ds.corp.yahoo.com> @ 2007-10-27 13:57 ` Richard Stallman 2007-12-20 22:21 ` Baoqiu Cui 0 siblings, 1 reply; 3+ messages in thread From: Richard Stallman @ 2007-10-27 13:57 UTC (permalink / raw) To: Baoqiu.Cui; +Cc: emacs-devel garbage collection is triggered and function mark_object() (in alloc.c) is recursively called about 29,885 times (see the backtrace info below)!!! So many levels of mark_object() calls make the stack overflow, causing a segmentation fault. I wonder if this indicates a bad choice of data structures. mark_object calls itself recursively for many kinds of pointers, but it is supposed to loop rather than recurse for cdr pointers. This is so that long lists do not cause recursion. Most data structures don't have a tremendous amount of nesting in the car direction. I wonder what sort of data structures made 29,885 recursive calls necessary. Perhaps we should change those data structures or else change the garbage collector so it recurses less. For instance, maybe a lot of this recursion goes thru symbols. If so, here is an idea. Suppose that when mark_object finds a symbol which is not yet marked, and is interned in the main obarray, it sets a bit "needs to be marked" in the symbol. Then increment a counter which records how many symbols are in this state. Then gc_sweep could end by scanning the main obarray over and over, marking those symbols, until the counter goes to zero. Depending on the nature of the problem, this might or might not help much. If the main data types involved are others, a different solution might help. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: VM crashes on big INBOX file ==> problem found!!! 2007-10-27 13:57 ` VM crashes on big INBOX file ==> problem found!!! Richard Stallman @ 2007-12-20 22:21 ` Baoqiu Cui 2007-12-21 19:49 ` Richard Stallman 0 siblings, 1 reply; 3+ messages in thread From: Baoqiu Cui @ 2007-12-20 22:21 UTC (permalink / raw) To: rms; +Cc: Robert Widhopf-Fenk, emacs-devel Sorry for the late reply. I wanted to look deeper into the VM code but could not find time to do that. I guess it might be easier for the new maintainer of VM, Robert Widhopf-Fenk, to take a look at this problem and see if there is anything that can be changed in VM. I am copying this email to Robert... Thanks for looking into this problem, Richard! - Baoqiu Richard Stallman writes: > garbage collection is triggered and function mark_object() (in alloc.c) > is recursively called about 29,885 times (see the backtrace info > below)!!! So many levels of mark_object() calls make the stack > overflow, causing a segmentation fault. > > I wonder if this indicates a bad choice of data structures. > mark_object calls itself recursively for many kinds of pointers, > but it is supposed to loop rather than recurse for cdr pointers. > This is so that long lists do not cause recursion. > Most data structures don't have a tremendous amount of nesting > in the car direction. > > I wonder what sort of data structures made 29,885 recursive > calls necessary. Perhaps we should change those data structures > or else change the garbage collector so it recurses less. > > For instance, maybe a lot of this recursion goes thru symbols. If so, > here is an idea. Suppose that when mark_object finds a symbol which > is not yet marked, and is interned in the main obarray, it sets a bit > "needs to be marked" in the symbol. Then increment a counter > which records how many symbols are in this state. > > Then gc_sweep could end by scanning the main obarray over and over, > marking those symbols, until the counter goes to zero. > > Depending on the nature of the problem, this might or might not > help much. If the main data types involved are others, > a different solution might help. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: VM crashes on big INBOX file ==> problem found!!! 2007-12-20 22:21 ` Baoqiu Cui @ 2007-12-21 19:49 ` Richard Stallman 0 siblings, 0 replies; 3+ messages in thread From: Richard Stallman @ 2007-12-21 19:49 UTC (permalink / raw) To: Baoqiu Cui; +Cc: hack, emacs-devel This problem may be triggered by something about the data structures made by VM, but the bug is certainly not in VM. It is in Emacs. And the only way to debug it is to investigate with GDB looking at a crash. Can you collect sufficient data to make a test case with which someone else can observe the bug? ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-12-21 19:49 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <yoruodet2jjm.fsf@AFTERRDOUBT-LX.ds.corp.yahoo.com> [not found] ` <fflvjt$dcs$1@reader1.panix.com> [not found] ` <yoru7ildglb3.fsf@AFTERRDOUBT-LX.ds.corp.yahoo.com> [not found] ` <ffo8rl$169$1@reader1.panix.com> [not found] ` <v9myu82p62.fsf@marauder.physik.uni-ulm.de> [not found] ` <yorumyu8f7pt.fsf@AFTERRDOUBT-LX.ds.corp.yahoo.com> [not found] ` <yoruabq6icer.fsf_-_@AFTERRDOUBT-LX.ds.corp.yahoo.com> 2007-10-27 13:57 ` VM crashes on big INBOX file ==> problem found!!! Richard Stallman 2007-12-20 22:21 ` Baoqiu Cui 2007-12-21 19:49 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).