Re: [Bug: 21.5-b15] Gnus crash

>>>>> "Jerry" == Jerry James <james(a)xemacs.org&gt; writes: #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.