Not sure of exact conditions to reproduce this, but lately I have occasionally been getting an error like
the following when attempting to eval something via M-:

    NS_ERROR_FILE_NOT_FOUND: File error: Not found
    null()@chrome://conkeror/content/commands.js:283
    _co_impl__send()@chrome://conkeror/content/coroutine.js:415
    Handler.prototype.process()@chrome://conkeror/content/compat/Promise.jsm:578
    null()@chrome://conkeror/content/compat/Promise.jsm:360
    null()@null:0

This seems to do it:

    M-: function foobar () { return 1; }
    M-: foobar

I can reproduce this, and I think I know what is happening.  It is the call to String(result), for
generating a string representation of a function, in commands.js that produces the exception.  Mozilla
doesn't store the source code of the function in memory when it first evaluates the function; it just
stores the filename and offset where the function is defined.  The first time the string representation
of the function is needed, it opens the file again and reads the function definition.  Subsequently, it
just uses the cached value and doesn't need to open the file.

The temporary file used by evaluate is deleted before the call to String(result), hence the error. 
However, the same temporary file name tends to be reused repeatedly.  If the file exists but has the
wrong contents, you end up with a garbled result.  For instance:

M-: function foobar () { return 1; }
M-: String(foobar)

<prints garbled output but doesn't throw an exception>

or

M-: function returns1 () { return 1; }
M-: function returns2 () { return 2; } String(returns1)

Prints:
function returns1() { return 2; }


Do you know why we use a temporary file for evaluate instead of just using eval?  If there aren't any
problems with using eval that might be the easiest solution.

Note: My description of how Mozilla handles string representations of funtions is just based on the
observed behavior from playing around with it, not from reading the source code.