Re: [Bug: 21.5-b15] Gnus crash

Jerry> Jerry interjects: My system (RedHat, tcsh) has "unlimit", Jerry> but not "ulimit". Also, I'm pretty sure that "recurrance" Jerry> should be "recurrence". I'll fix the latter, but the former should go in a FAQ. The crash message is already too long. Jerry> Lisp backtrace follows: # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # bind (print-message-label) display-error((wrong-type-argument listp #<EMACS BUG: freed lrecord object 0x8c77adc Save your buffers immediately and please report this bug>) t) # bind (etype debug-on-error inhibit-quit error-object) command-error((wrong-type-argument listp #<EMACS BUG: freed lrecord object 0x8c77adc Save your buffers immediately and please report this bug>)) # (catch top-level ...) Jerry> That's a pretty useless backtrace. Is there some way I can Jerry> arrange to get a backtrace from the point where the freed Jerry> lrecord object is detected, instead of the point where the Jerry> top-level command loop figures out that an error object is Jerry> not a list? I don't think so. I don't see why it would tell you anything you don't already know. Hasn't the code that freed the object improperly already flown to Rio de Janeiro, with the loot? Also AFAIK that's where this _is_ detected. listp checks some bits for equality to lrecord_type_cons, then calls w-t-a, expecting to throw to an error-handler. w-t-a then actually tries to decode the object; until then, it's opaque. #6 0x081ed71f in printing_major_badness (printcharfun=0, badness_string=0x6 <Address 0x6 out of bounds>, type=137356736, val=0x6, badness=BADNESS_INTEGER_OBJECT) at /usr/src/xemacs/xemacs-21.5/src/print.c:1480 I wonder if this is compiler or gdb breakage. That 0x6 is supposed to point to a string, namely "freed lrecord". Now _this_ is bad news: #7 0x081ed8cd in print_internal (obj=147290844, printcharfun=139642720, escapeflag=1) at /usr/src/xemacs/xemacs-21.5/src/print.c:1709 #8 0x081ebada in print_error_message (error_object=1, stream=139642720) at /usr/src/xemacs/xemacs-21.5/src/print.c:977 #9 0x081ebed0 in Fdisplay_error (error_object=0, stream=0) at /usr/src/xemacs/xemacs-21.5/src/print.c:1035 #10 0x080ece95 in Ffuncall (nargs=3, args=0x1) at /usr/src/xemacs/xemacs-21.5/src/eval.c:3866 In frame #10, args is supposed to be a Lisp_Object *, so stack is being corrupted here somehow. Maybe there's a compiler bug, since that value should get trapped by the code #ifdef ERROR_CHECK_BYTE_CODE in execute_optimized_program before you get to the Ffuncall (check that ERROR_CHECK_BYTE_CODE is defined in config.h). But it seems more likely that the stack got corrupted after these frames, as error_object and stream are both Lisp_Objects, too. Then, the obj in print_internal is the freed lrecord (0x8C77ADC), so things look consistent again. The only thing I can think of that's remotely related is that Vin had partially analyzed a (possible) problem with stack depth allocation by the byte compiler, Martin and I each replied once, but nothing since. http://list-archive.xemacs.org/xemacs-beta/200302/msg00268.html http://list-archive.xemacs.org/xemacs-beta/200303/msg00107.html I guess this could be related, since execute_optimized_program allocas its stack. Jerry> Those last two commands were to take a peek at the Jerry> supposedly free object. The first word, which is supposed Jerry> to be the lrecord_header looked suspicious to me (note all Jerry> the set bits in the "unused" part), hence the memory dump. Jerry> It looks to me like it is not an lrecord_header at all, but Jerry> a former 0xdeadbeef that had two of its bits zeroed. Many You're almost there: at least some freed lrecords may look like this, see eg FREE_FIXED_TYPE in alloc.c and note lrecord_type_free == 0x3F (if I'm counting correctly in the enum lrecord_type table). Jerry> of the subsequent words also look like former 0xdeadbeef Jerry> entries with some twiddled bits. Heap corruption? Maybe, but the stack is definitely badly mangled. ------------------------------------------------------------------------ (prog-modes :version 1 .83 :type single-file) Jerry interjects: What happened there? Overly narrow margins gone wild? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< prog-modes is always like that. Somebody figured out why once but nobody ever got around to fixing it. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.