Error during eval()

Hi,

We embedded Ruby 1.3.29 in a Windows XP application, and sometimes we
get strange errors back from the Ruby interpreter.

The error we get is something like:
#<Errno::EBADF: (eval):3702:in `write’Bad file descriptor>
Where the number (3709) varies.

I attached a code snippet in C++ where we make the actually call to
Ruby.
The Ruby script does not use OS resources like files or sockets, we only
do some numerical processing there.

I wonder if the eval() tries to open a file? Maybe for logging or
something similar. Any ideas?

Thanks,
Luc

bool ApplyScript (const string &inScript, string& outErrorString)
{
int theState = 0;
rb_eval_string_protect (inScript.c_str (), &theState);

if (theState) {
    string errorString = STR2CSTR (rb_obj_as_string

(rb_inspect(ruby_errinfo)));
rb_p (ruby_errinfo);
outErrorString = errorString;
return false;
}
return true;
}

On 9/5/07, Luc H. [email protected] wrote:

Hi,

We embedded Ruby 1.3.29 in a Windows XP application, and sometimes we
get strange errors back from the Ruby interpreter.

The error we get is something like:
#<Errno::EBADF: (eval):3702:in `write’Bad file descriptor>
Where the number (3709) varies.

Can you check line #3702 of your eval’ed script if there’s “write” by
any chance?
Can you post preferably smallest script that produces this error, or
at least few lines before and after where the error happens?

NB: I guess 1.3.29 is SWIG version not RUBY…

J.

Jano S. wrote:

On 9/5/07, Luc H. [email protected] wrote:

Hi,

We embedded Ruby 1.3.29 in a Windows XP application, and sometimes we
get strange errors back from the Ruby interpreter.

The error we get is something like:
#<Errno::EBADF: (eval):3702:in `write’Bad file descriptor>
Where the number (3709) varies.

Can you check line #3702 of your eval’ed script if there’s “write” by
any chance?
Can you post preferably smallest script that produces this error, or
at least few lines before and after where the error happens?

NB: I guess 1.3.29 is SWIG version not RUBY…

J.

Hi Jano,

Yes, the 1.3.29 is indeed SWIG, sorry for the confusion
We use:
SWIG Version 1.3.29 Compiled with g++ [i686-pc-cygwin]
ruby 1.8.1 (2003-12-25) [i386-mswin32]

The script itself is very simple, just one line:

Fcstest::Log (“Test 123”)

The Fcstest::Log function was wrapped with SWIG. When I tested with this
script I got error such as:
#<Errno::EBADF: (eval):190:in write'Bad file descriptor> #<Errno::EBADF: (eval):380:inwrite’Bad file descriptor>

If a add more lines to the script I get the errors more often, and the
numbers tend to be higher.

Maybe ruby tries to write to the console? It’s a windows app, so it has
no console. But normally the calls to puts() don’t cause any problems if
you have no console, at least not in C++.

Luc

On 9/6/07, Luc H. [email protected] wrote:

Fcstest::Log (“Test 123”)
no console. But normally the calls to puts() don’t cause any problems if
you have no console, at least not in C++.

Luc

Ok, I’m lost :wink: Anyway, two hints:

  1. Ruby redefines write/read functions. (#define write(f,x,y)
    rb_write(f,x,y) or similar) That meas, if you use I/O, you might end
    using ruby output routines. Check that. (see win32.h)

  2. Try to find out how eval numbers code lines, and find the wrong
    one. I guess it will be something involving IO.

If that doesn’t help (desperate scenario :-), build your own ruby,
find in sources where it might be thrown, and set breakpoint there
(most probably file.c or io.c).

Nobuyoshi N. wrote:

We use:
SWIG Version 1.3.29 Compiled with g++ [i686-pc-cygwin]
ruby 1.8.1 (2003-12-25) [i386-mswin32]

Cygwin runtime and msvcrt don’t share file descriptors.

You need to SWIG compiled with MSVC or mingw.

Ok, I build ruby myself, and I installed the windows version of SWIG.
Both my app and ruby are build with VS8

ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32_80]
SWIG Version 1.3.31 Compiled with g++ [i686-pc-mingw32]

My script does not use file handles, actually it does not matter what is
inside the script, if it calls any of my functions wrapped with swig
then I get errors such as

#<Errno::EBADF: (eval):896:in `write’: Bad file descriptor>

What to do next?
How can I build a debug version of the ruby dll?

Luc

Hi,

At Thu, 6 Sep 2007 20:56:07 +0900,
Luc H. wrote in [ruby-talk:267869]:

We use:
SWIG Version 1.3.29 Compiled with g++ [i686-pc-cygwin]
ruby 1.8.1 (2003-12-25) [i386-mswin32]

Cygwin runtime and msvcrt don’t share file descriptors.

You need to SWIG compiled with MSVC or mingw.

On 9/11/07, Nobuyoshi N. [email protected] wrote:

Mingw/VC6 and VC8 are not compatible. Dont’ mix them.
I guess that’s not a problem - SWIG just generates wrapper source
code, and its binary files are not involved in the resulting binary
(there’s no libswig anymore).

The important thing is to have matching Ruby compiler and
extension/embedding program compiler.

Hi,

At Tue, 11 Sep 2007 00:02:56 +0900,
Luc H. wrote in [ruby-talk:268501]:

Ok, I build ruby myself, and I installed the windows version of SWIG.
Both my app and ruby are build with VS8

ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32_80]
SWIG Version 1.3.31 Compiled with g++ [i686-pc-mingw32]

Mingw/VC6 and VC8 are not compatible. Dont’ mix them.

Jano S. wrote:

The important thing is to have matching Ruby compiler and
extension/embedding program compiler.

We have that now.
I did some more debugging and now know what causes the problem, but
don’t understand what goes wrong.

If I make the script:


calls a function wrapped by SWIG returning a singleton

theInterface = Fcstest::GetInterface ()

And run it a few times I get the eval error. But if I change it to:


import GC

calls a function wrapped by SWIG returning a singleton

theInterface = Fcstest::GetInterface ()
theInterface = nil
GC.start()

All is ok in the second script.
In the first script, theInterface is garbage collected when the script
runs for the second time, and that causes the problem.
But I do not understand why… SWIG just wraps my singleton in a
SWIG_NewPointerObj it does not delete or new it.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs