Messages in this thread | | | Date | Sun, 31 Mar 1996 13:31:05 -0800 | From | (Ben Wing) | Subject | Re: Linux-1.3.81 |
| |
In article <m2yboij7gx.fsf@deanna.miranova.com>, Steven L Baur <steve@miranova.com> wrote: |(Ben Wing is Cc'ed since XEmacs is now experiencing major breakage |with new Linux kernels). | |I'm triggering some other kind of bogosity now with XEmacs in that I |can no longer run Gnus in it if I start XEmacs out of an olvwm menu -- |it eventually dies with: |Fatal error: assertion failed, file signal.c, line 327, async_timer_suppress_count > 0 | |Fatal error (6). |Your files have been auto-saved. |and a stack backtrace of: |(gdb) where |#0 0x4017b875 in __kill () |#1 0x8086b90 in fatal_error_signal (sig=6) at emacs.c:170 |#2 0xbffda3ec in __ypbindlist () |#3 0x401a6eb9 in gsignal () |#4 0x80d3e4b in alarm (howlong=1) at signal.c:327 |#5 0x401bfd9b in sleep () |(gdb) | |It doesn't seem right to me that XEmacs should redefine alarm, but not |redefine sleep, which calls alarm (in libc 5.2.18 at least). Whatever |XEmacs is doing though causes XF86_SVGA (3.1.2) to crash in Linux |1.3.77 and 1.3.80; it does not crash the X server in 1.2.13 or 1.3.81.
This is a bug in XEmacs, and you've put your finger on exactly what's going wrong. The redefinition of alarm() is there specifically to catch places where alarm() is getting called without XEmacs's knowledge -- that's what the abort is telling you. XEmacs calls setitimer() on its own, and any calls to alarm() (except when specially bracketed inside of XEmacs) mess things up because Linux (and other Unixen) has the extremely annoying behavior of only providing one alarm timeout per process. I suppose this could be fixed using threads ...
The X-server crash is something else entirely, of course.
ben -- "... then the day came when the risk to remain tight in a bud was more painful than the risk it took to blossom." -- Anais Nin
| |