Odd strings in running image?

I have some simple Lisp code that ideally should just keep on running, but unfortunately the running image keeps growing until it runs out of memory. To get an idea of what is happening, I wrote a simple function that lists all packages with the number of internal/external symbols, and another that lists all all object types [(class-name (class-of o))] along with the count of objects of that type.

I saw that the number of simple-strings kept growing, so I wrote another function to look at those. I found that there were a huge number of strings of the form

~d=> ~d [WHATEVER]++

where the length of WHATEVER matches the value represented by the ~d's (identical, for all the cases I've seen).

I was stumped for a while, until I realised that these strings matched stuff that had previously been written to *standard-output* and/or *error-output*.

My current best guess (which replaced some earlier guesses that turned out to be less than perfect) is that Lispworks caches strings sent to *standard-output*/*error-output*, possibly for debugging purposes. If this is the case, I'd like to be able to restrict the size of this cache.

Any hints?

Regards,
Raymond Wiker

Re: Odd strings in running image?

Followup: in the lisp image (in my case,
lispworks-6-0-0-x86-win32.exe), I find the string

~a=> ~a [~a]++

--- this looks like it would be the format string that generates the
strings cause my lisp image to blow up. I've been trying to find a
symbol that points to this string, but without success (no reason that
it should be available through a symbol, of course).

This format string can also be found in the Lispworks Personal image
(also Windows).

On Mon, Aug 23, 2010 at 5:37 PM, Raymond Wiker <rwiker@gmail.com> wrote:
> I have some simple Lisp code that ideally should just keep on running, but unfortunately the running image keeps growing until it runs out of memory.. To get an idea of what is happening, I wrote a simple function that lists all packages with the number of internal/external symbols, and another that lists all all object types [(class-name (class-of o))] along with the count of objects of that type.
>
> I saw that the number of simple-strings kept growing, so I wrote another function to look at those. I found that there were a huge number of strings of the form
>
> ~d=> ~d [WHATEVER]++
>
> where the length of WHATEVER matches the value represented by the ~d's (identical, for all the cases I've seen).
>
> I was stumped for a while, until I realised that these strings matched stuff that had previously been written to *standard-output* and/or *error-output*.
>
> My current best guess (which replaced some earlier guesses that turned out to be less than perfect) is that Lispworks caches strings sent to *standard-output*/*error-output*, possibly for debugging purposes. If this is the case, I'd like to be able to restrict the size of this cache.
>
> Any hints?
>
> Regards,
> Raymond Wiker

Re: Odd strings in running image?

I'm attaching a simple test case along with a delivery script. When
run, the test generates a single string of the type I found ~85000 of
from a small run with my application; I suspect that I should be able
to generate more of these strings with a bit of experimentation.

The "problem string" in my output (in the file simple-strings.txt) is

=====================================
Length:     128; Value = 1282=> 8192 [ssage 809: The quick brown fox
jumps over the l ... \000ADebug output message 810: The quick brown
fox jumps over th
=====================================

The test file contains several test cases; the only ones I could get
to cause errors used a combination of string output streams and
writing to *debug-io* (I just checked, and I get the same behaviour if
I use *standard-output*).

On Tue, Aug 24, 2010 at 1:22 PM, Martin Simmons <martin@lispworks.com> wrote:
>
> Hi Raymond,
>
> There is a cache of format strings, so that might be the cause.
>
> Can you post the code that causes the problem?
>
> --
> Martin Simmons
> LispWorks Ltd
> http://www.lispworks.com/
>
>
>
>>>>>> On Tue, 24 Aug 2010 10:56:23 +0200, Raymond Wiker said:
>>
>> Followup: in the lisp image (in my case,
>> lispworks-6-0-0-x86-win32.exe), I find the string
>>
>> ~a=> ~a [~a]++
>>
>> --- this looks like it would be the format string that generates the
>> strings cause my lisp image to blow up. I've been trying to find a
>> symbol that points to this string, but without success (no reason that
>> it should be available through a symbol, of course).
>>
>> This format string can also be found in the Lispworks Personal image
>> (also Windows).
>>
>> On Mon, Aug 23, 2010 at 5:37 PM, Raymond Wiker <rwiker@gmail.com> wrote:
>> > I have some simple Lisp code that ideally should just keep on running, but
>> > unfortunately the running image keeps growing until it runs out of
>> > memory. To get an idea of what is happening, I wrote a simple function
>> > that lists all packages with the number of internal/external symbols, and
>> > another that lists all all object types [(class-name (class-of o))] along
>> > with the count of objects of that type.
>> >
>> > I saw that the number of simple-strings kept growing, so I wrote another
>> > function to look at those. I found that there were a huge number of
>> > strings of the form
>> >
>> > ~d=> ~d [WHATEVER]++
>> >
>> > where the length of WHATEVER matches the value represented by the ~d's
>> > (identical, for all the cases I've seen).
>> >
>> > I was stumped for a while, until I realised that these strings matched
>> > stuff that had previously been written to *standard-output* and/or
>> > *error-output*.
>> >
>> > My current best guess (which replaced some earlier guesses that turned out
>> > to be less than perfect) is that Lispworks caches strings sent to
>> > *standard-output*/*error-output*, possibly for debugging purposes. If this
>> > is the case, I'd like to be able to restrict the size of this cache.
>> >
>> > Any hints?
>> >
>> > Regards,
>> > Raymond Wiker
>>
>
>

Re: Odd strings in running image?

Unable to parse email body. Email id is 10493