Re: [Bug: 21.5-b15] Gnus crash

Jerry> And since that string got printed, it did point to it at Jerry> one time. I have the latest RedHat 9 packages installed, Jerry> namely gcc-3.2.2-5 and gdb-5.3post-0.20021129.18. Now why Jerry> does that gdb version number fail to inspire me with Jerry> confidence? Uh-oh. gcc-3.2 does this too? I was hoping it was a gcc-3.3-ism, as "freed lrecords" are suddenly coming up in 21.4 too (Gnus users, all). But then, Red Hat version numbers have always been meaningless. Anybody want to see how much of gcc 3.3 is in Red Hat's gcc 3.2? :-( I'll see what I can come up with; today this has happened to me about every 15 minutes. New gnus is bad gnus. Bad Gnus, bad, ba-a-a-ad Gnus! :-( Jerry> I agree. It looks like that stack is hosed (or else gdb Jerry> lost its mind). I can confirm that recent gdb is non compos mentis. For a couple of debian upgrades it couldn't read XEmacs's symbols! But I find it hard to believe that it could read parts of the stack correctly and not others. Jerry> But since ERROR_CHECK_BYTE_CODE is defined for beta Jerry> versions, wouldn't the check at the top of the while loop Jerry> in execute_optimized_program catch that kind of problem? Jerry> Apparently not, but I don't understand why. That depends on whether any of the bytecodes do anything else with the stack. If there are any data manipulations that are byte-interpreter- stack-relative.... Jerry> Hmmmm. What was check_specbind_stack_sanity() supposed to Jerry> do? It looks like whoever came up with the idea never got Jerry> around to writing it. Not that it makes any difference, Jerry> since ERROR_CHECK_CATCH is not defined by --error-checking. I'd guess that's why it's not defined. :-/ -- 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.