Segmentation fault

[GoogleCodeExporter]

Hello.

I currently get segfaults with muSE when i try to cons a lot of cells.
Happens when consing more than 10.000 cells using a recursive procedure,
on a Win32 (XP) machine, using both v372 and v437 from the Downloads tab.

Original issue reported on code.google.com by archvill...@gmail.com on 24 Apr 2009 at 9:38

[GoogleCodeExporter]

Can you give a sample program? I guess it'll be short. I tried the following 
which worked fine in v437 (albeit 
in macosx) -
{{{
(define b (box ()))
(define (fib n)
  (let ((result (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2))))))
    (b (cons result (b)))
    result))
}}}

With that, `(fib 33)` worked fine and `b` will be holding a list that's about 
11 million items long. 

Original comment by srikuma...@gmail.com on 12 May 2009 at 6:12

[GoogleCodeExporter]

I think it is time for another release update to muSE. Some fairly significant 
fixes have gone in since v437.

Original comment by srikuma...@gmail.com on 12 May 2009 at 6:45

• Changed state: Started

[GoogleCodeExporter]

Original comment by srikuma...@gmail.com on 12 May 2009 at 6:45

[GoogleCodeExporter]

Just checked: The example in comment #1 worked in v372 on macosx as well.

Original comment by srikuma...@gmail.com on 12 May 2009 at 7:06

[GoogleCodeExporter]

Found a category of errors related to large numbers of arguments given to 
functions 
(say, using apply). In particular, hashtable conversion and vector conversion 
functions 
were blowing up the stack when given large numbers of arguments. More stack 
blow up 
occurred when those arguments were generated by means of lazy lists.

The run of changes r514, r516, r517, r518, r519 and r520 address these issues.

Original comment by srikuma...@gmail.com on 4 Jul 2009 at 9:54

• Added labels: Priority-High

[GoogleCodeExporter]

Original comment by srikuma...@gmail.com on 4 Jul 2009 at 9:54

• Added labels: Type-Defect

[GoogleCodeExporter]

Ok - there is a limit to the number of cells that can be held in an environment 
- its of the order of 250million ... 
beyond which muSE will, essentially, fail. One alternative is to build muSE so 
that the "muse_cell" type is 64-bits 
in size rather than 32-bits. This doubles muSE's memory usage, but allows a 
much larger cell count. 

Original comment by srikuma...@gmail.com on 25 Jul 2009 at 7:54

[GoogleCodeExporter]

Original comment by srikuma...@gmail.com on 25 Jul 2009 at 7:55

• Added labels: Priority-Low, Performance
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by srikuma...@gmail.com on 25 Jul 2009 at 8:01

• Added labels: Usability
• Removed labels: Performance

[GoogleCodeExporter]

One way to reduce the cell count of your data structures is to use vectors 
instead of 
lists. A vector, irrespective of its length, consumes only one cell in muSE 
(unless a 
datafn is associated with it, that is). So you can have a 250-million sized 
vector and 
still not hit the cell count limit.

Original comment by srikuma...@gmail.com on 29 Jul 2009 at 2:11