Martin von Gagern wrote:

The following works for me: diff -ru polyml-4.1.3/driver/addresses.h polyml/driver/addresses.h --- polyml-4.1.3/driver/addresses.h 2002-06-18 20:47:45.000000000 +0200 +++ polyml/driver/addresses.h 2004-12-21 10:42:36.481444760 +0100 @@ -267,10 +267,10 @@ and 0x10000000 in later ones. It seems that mmap without a fixed address (and so malloc) maps at upwards of 0x40000000. These should be reasonable. DCJM 29/11/01. */ -#define LOCAL_IBOTTOM Words(0x60000000) -#define LOCAL_ITOP Words(0xa8000000) -#define LOCAL_MBOTTOM Words(0xa8000000) -#define LOCAL_MTOP Words(0xb8000000) +#define LOCAL_IBOTTOM Words(0x50000000) +#define LOCAL_ITOP Words(0x98000000) +#define LOCAL_MBOTTOM Words(0x98000000) +#define LOCAL_MTOP Words(0xa8000000) /* 1.1 Gbytes for immutable, 256Mbytes for mutable. */ /* This leaves 0xb8... - 0xbf... for the C stack. (i.e. 128 Mbytes) */

Brilliant! That's saved me a lot of work.

I hadn't had any problems when I tried with the 2.6.9 kernel based on the Fedora Core 2 distribution. I had another look at this yesterday and tried varying the options for the kernel and finally managed to build a kernel which generated the seg fault. It turned out that turning OFF the "4GB kernel space and 4 GB user-space virtual memory segment" resulted in the seg fault. Maybe this is turned off by default in debian. It looks as though this puts some of the libraries into the area used by Poly/ML for the local heap.

I've applied this patch and updated the development sources ( http://www.polyml.org/polyml-devel.tar.gz ). If this seems to solve the problem for everyone I'll build a new release.

In the longer term it would be better to get away from fixed addresses but it would need a major redesign.

David.