Thanks for your advice and that of Eric Marsden. I am using version 18e. I tried increasing the dynamic space instruction at the command line (moving itto as high as 600) but without much effect. I then made some changes in the program to be more careful in dealing with the edges of the drawing (and thus trying to prevent the foreign functions from overstepping the memory boundary), and this had the dual effect of reducing the dynamic space required in processing as recorded by dynamic-space-size variable and allowedthe program to complete without failure. Whether it was the foreign function kicking out (likely) or something else, I am not sure. I appreciate your help. Blake
Raymond Toy wrote: "blake" == blake <[EMAIL PROTECTED]>[1] writes: blake> I am using cmucl for the creation of a large graphic image (interfaced blake> through the alien functions with Intels opencv and IPP libraries). The blake> program works fine for images less than 40 megabytes, but when I try to blake> do something larger than this (essentially I just change the size of the blake> drawing), it silently fails and returns me to the operating system. I blake> am not sure how to go about debugging this. Flailing around, I thought blake> it might be the "dynamic space" so I put in to print it out. It starts blake> out with: [snip] blake> 134,406,144 bytes for 5,266,093 dynamic objects (space total.) blake> ; Compiling LAMBDA (#:G1572 #:G1573 #:G1574): blake> ; Compiling Top-Level Form: blake> ; Compiling LAMBDA (#:G1575 #:G1576 #:G1577 #:G1578 #:G1579 #:G1580): blake> ; Compiling Top-Level Form: blake> ; Compiling LAMBDA (#:G1581 #:G1582 #:G1583 #:G1584 #:G1585 #:G1586 blake> #:G1587 #:G1588): blake> ; Compiling Top-Level Form: blake> [EMAIL PROTECTED] tiha]$ Could it be the alien libraries exiting for some reason? If it were a heap-overflow, there would normally be a segfault with a terse message. Ray --- Links --- 1 mailto:[EMAIL PROTECTED]
