Bug: Unbound variable:

Bug: Unbound variable:

[Linas Vepstas]

Hi,

In guile-1.8.5 (haven't yet tried 1.8.6) I'm seeing a strange bug:
a program that has been running a while (12-24 hours) and
approaching an out-of-memory condition (system on verge
of swapping to disk) will suddenly get an 'Unbound variable'
error on a variable that is heavily in use (dozens or maybe
thousands of calls per second).  This system has only *one*
thread in guile mode.

Anyone seen anything like that before? Any suggestions
for how to debug?

--linas

p.s. yes, am trying 1.8.6 shortly.

Re: Bug: Unbound variable:

[Ludovic Courtès]

Hi,

"Linas Vepstas" <linasvepstas@gmail.com> writes:

> In guile-1.8.5 (haven't yet tried 1.8.6) I'm seeing a strange bug:
> a program that has been running a while (12-24 hours) and
> approaching an out-of-memory condition (system on verge
> of swapping to disk) will suddenly get an 'Unbound variable'
> error on a variable that is heavily in use (dozens or maybe
> thousands of calls per second).  This system has only *one*
> thread in guile mode.

Are you able to get a meaningful backtrace when that exception is
raised?  Can you reproduce that with a simple example?  Is your program
doing something nasty with threads?  :-)

Thanks,
Ludo'.

Re: Bug: Unbound variable:

[Linas Vepstas]

2008/12/13 Ludovic Courtès <ludo@gnu.org>:
> Hi,
>
> "Linas Vepstas" <linasvepstas@gmail.com> writes:
>
>> In guile-1.8.5 (haven't yet tried 1.8.6) I'm seeing a strange bug:
>> a program that has been running a while (12-24 hours) and
>> approaching an out-of-memory condition (system on verge
>> of swapping to disk) will suddenly get an 'Unbound variable'
>> error on a variable that is heavily in use (dozens or maybe
>> thousands of calls per second).  This system has only *one*
>> thread in guile mode.
>
> Are you able to get a meaningful backtrace when that exception is
> raised?

Sure .. but its in my code .. for example:

guile> (doit)
Backtrace:
In current input:
   1:  0* [doit]
   1:  1  [process-data
"/home2/linas/src/novamente/data/enwiki/enwiki-20080524/parsed/A" ...]
    ...
  24:  2  [for-each #<procedure process-file #> #]
   ?:  3* [process-file "Andrew Van de Kamp.xml"]
   3:  4* (let ((fullname #) (donename #)) (system (string-join #)) ...)
  14:  5* [ldj-process]
   2:  6  [for-each #<procedure ldj-process-document (doco)> (#)]
   ?:  7* [ldj-process-document #]
   2:  8* [for-each #<procedure ldj-process-sentence (sent-node)> ...
   2:  9*  [document-get-sentences #]
   2: 10   (cog-get-reference doco)

<unnamed port>:2:9: In expression (cog-get-reference doco):
<unnamed port>:2:9: Unbound variable: cog-get-reference
ABORT: unbound-variable
guile>

This is the umpteenth document that was processed
in exactly the same way, so its hard for me to imagine
how things got unbound ...

> Can you reproduce that with a simple example?

I'll try, but since this can takes 12-24 hours to reproduce,
i's tricky. Which is why I thought I'd ask first.

> Is your program
> doing something nasty with threads?  :-)

Mostly no. The initial load of the scheme code happens
across multiple threads, and there are still races of
some kind that I'm working around by putting in
sleeps so that each thread finishes before the next
one starts.  But once the code is loaded, its single
threaded only. It works fine (usually), running for days
(till the batch job finishes), but sometimes stops
prematurely with random unbound-variable messages.

--linas

Re: Bug: Unbound variable:

[Neil Jerram]

2008/12/14 Linas Vepstas <linasvepstas@gmail.com>:
> 2008/12/13 Ludovic Courtès <ludo@gnu.org>:
>>
>> Are you able to get a meaningful backtrace when that exception is
>> raised?
>
> Sure .. but its in my code .. for example:
>
> guile> (doit)
> Backtrace:
> In current input:
>   1:  0* [doit]
>   1:  1  [process-data
> "/home2/linas/src/novamente/data/enwiki/enwiki-20080524/parsed/A" ...]
>    ...
>  24:  2  [for-each #<procedure process-file #> #]
>   ?:  3* [process-file "Andrew Van de Kamp.xml"]
>   3:  4* (let ((fullname #) (donename #)) (system (string-join #)) ...)
>  14:  5* [ldj-process]
>   2:  6  [for-each #<procedure ldj-process-document (doco)> (#)]
>   ?:  7* [ldj-process-document #]
>   2:  8* [for-each #<procedure ldj-process-sentence (sent-node)> ...
>   2:  9*  [document-get-sentences #]
>   2: 10   (cog-get-reference doco)
>
> <unnamed port>:2:9: In expression (cog-get-reference doco):
> <unnamed port>:2:9: Unbound variable: cog-get-reference
> ABORT: unbound-variable
> guile>

Could you get a C backtrace too, by setting a breakpoint on
error_unbound_variable?  There are two places that call
error_unbound_variables, and at first glance the one from eval.c line
2884 looks more unusual, so it would be interesting to know if it was
that place causing your problem.

Regards,
     Neil

Re: Bug: Unbound variable:

[Neil Jerram]

2008/12/14 Neil Jerram <neiljerram@googlemail.com>:
>
> There are two places that call
> error_unbound_variables, ...

s/variables/variable/

    Neil