Sawfish core dumps under SOLARIS under the following conditions:
(a)the  'Sounds for events' option in the 'Multimedia:Sound' config screen &
(b)the 'Play sound effects for window events' option in the 'Sawfish Window
Manager:Sound' config screen.

To recreate:
1) Start a gnome terminal and minimise
2) Start gnomecc and on the 'Multimedia:Sound' config screen enable the 'Sounds
for events' option. Click OK.
3) On the 'Sawfish Window Manager:Sound' config screen enable the'Play sound
effects for window events' option. Click OK.
4) Go back to the 'Sawfish Window Manager:Sound' config screen and select a
sound and click 'Edit'. Do not edit the sound and click OK.
5) Maximise the gnome terminal.
6) Minimise the gnome terminal
7) Click on the  'Sawfish Window Manager:Sound' config screen - The result is
that the sawfish window manager core dumps 

Possible causes?:
	1) librep may need to be 64-bit cleaned.
	2) rep thread handling (rep_TEST_INT...) may not restore stack properly
	3) gnome-config writes bad lisp code in case where audio filename isn't
edited.  

(gdb backtrace from Sawfish 0.38 crash)

+ Trace 9861

------- Additional Comments From jsh@pixelslut.com 2001-08-31 08:12:10 ----

>Possible causes?:
>1) librep may need to be 64-bit cleaned.

librep should be 64-bit clean already - I know that people have run it on
alpha/ia-64 architectures

>2) rep thread handling (rep_TEST_INT...) may not restore stack properly

rep_TEST_INT doesn't reallt have anything to do with rep's thread handling
(though it does decide when to preempt software threads). In any case, none of
sawfish uses rep's threads

>3) gnome-config writes bad lisp code in case where audio filename isn't edited.  

it's very unlikely that bad lisp code could cause these symptoms

The backtraces show that both crashes happen in malloc. It looks like the malloc
implementation may be the dlmalloc.c included with sawfish, this is known to
have issues on 64 bit systems, e.g. it's disabled on Compaq Tru64 systems. The
same may need to be done for 64-bit solaris..

To do this I need to know the architecture string that configure gives for your
system. (I also need to be able to tell 32 bit from 64 bit machines)

Disabling dlmalloc may have a negative effect on performance - the reason I
first started using it was that the solaris malloc implementation was way too
slow for the usage patterns generated by librep



------- Additional Comments From brian.nitz@sun.com 2001-09-07 02:14:08 ----

The string returned by configure for this version of Solaris is:
sparc-sun-solaris2.8

To determine the current bitmode of the kernel:
$ isainfo -b
64Although the kernel is in 64 bit mode, the sawfish executable was built as an
ELF 32-bit MSB executable SPARC Version 1, dynamically linked not stripped.

If there are dlmalloc problems when used on 64-bit kernels, instead of bypassing
dlmalloc and possibly reducing performance, might setting INTERNAL_SIZE_T to a
32 bit `unsigned int' instead of size_t help?



------- Additional Comments From jsh@pixelslut.com 2001-09-07 08:05:38 ----

Hmm. So if it's running in 32-bit mode, why was one of your `suggestions' that
librep needed to be made 64-bit clean?

I have node idea if tweaking the dlmalloc options may help. I did try that once
(or at least, got someone else to). But I don't recall it helping.

Anyway, you're the one with the 64-bit sparc, so you're probably better placed
to invertigate it. I recommend disabling dlmalloc and seeing if that fixes the
problem.. If not, it's probably a memory smasher somewhere..



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:18 -------