"Robin S. Socha" <robin(a)socha.net> writes:
configured using `configure --compiler=egcs
'-cflags=-I/usr/include/db1 -O6 -mcpu=pentiumpro -march=pentiumpro'
--error-checking=none --debug=no --verbose --with-scrollbars=athena3d
--with-dialogs=athena3d'
Please always compile betas with "-g"!
Lisp backtrace follows:
Did it print out an "Assert failed line?"
#4 0x8078b82 in assert_failed ()
#5 0x8113b67 in alarm ()
#6 0x4001d788 in esd_open_sound () from /usr/lib/libesd.so.0
#7 0x4001d98e in esd_play_stream () from /usr/lib/libesd.so.0
#8 0x4001edf8 in esd_play_file () from /usr/lib/libesd.so.0
#9 0x8092223 in esd_play_sound_file ()
#10 0x811407f in Fplay_sound_file ()
libesd is probably calling alarm so setup a timeout. From the look of
it esd_play_file should be wrapped in calls to
stop/start_async_timeouts.
However I am not sure whether is not indicative of a larger problem.
Potentially every library call could use SIGALRM internally.
From signal.c
/* If alarm() gets called when polling isn't disabled, it can mess
up the periodic timer. */
assert (async_timer_suppress_count > 0);
This comment is too terse. Why is that so? Is it even so if the
library is careful enough to put its own signal hanler into place?
<assert-haters-club>
Is messing up the periodic timer really worse than crashing?
</assert-haters-club>
Jan