Sorry for the delay with the reply. In my free-time I was exploring
the possible solutions, but didn't find any working one. So I decided
to prepare the test case. One problem with it, is that it's quite
heavy (1k LOC).
The crash occurs after trying to load the macro (def-user-page :trs
...) for the second time (for example, after a minor change). First
time it loads OK (the whole compilation takes some time: around a
minute or two). But if I try to recompile, I always get to LDB.
I've gathered all the code in one file and organized it from the
general-purpose operations to the specific ones from top to bottom.
The macro, which causes the problem is the bottom-most. There will be
some warnings about undefined variables (which are in fact
symbol-macros), but that, as fa as I know, shouldn't impact the
But there's the problem with this test: when run in isolation (on the
blank image, so to say), I can re-load it as many times as I like, and
it doesn't cause heap exhaustion. (Although you can see, that the
expansion takes some time). But this illustrates, that the problem is
not in the macro itself (as exactly the same code with the same
optimization parameters) causes exhaustion in production environment.
I'd be glad to learn the way to debug this issue myself (or maybe
control it with the use of some optimization parameters).
On 11/30/08, Nikodemus Siivola <nikodemus@...> wrote:
> On Mon, Nov 24, 2008 at 10:56 PM, Vsevolod <vseloved@...> wrote:
>> I thought of that too, but at first run everything compiles, and the
>> generated code runs OK. Besides, all the application runs without any
>> difficulties (web-server, database access, data processing), so the
>> problem should be local (I mean no memory leaks etc.)
> I'm also inclined to *guess* this is a recursive macro issue - or
> something similar.
> However, telepathic debugging is not going to lead very far in here: a
> test case which exhibits this behaviour would be welcome.
> -- Nikodemus