Ruby and networking crashes app on windows

Hi!

It’s been quite long since I last posted here, but now I feel I’m stuck.

What I’m trying is to embed a ruby interpreter into a (multi-threaded)
3rd party app (using its scripting interface and its ability to load
DLLs through it), and run my ruby code by it. After much trial and
error, I’ve managed to have it work to the extent that I can call into
my own ruby code without having it crash the app.

However, anytime I try to access any networking abilities from ruby, it
crashes the host app immediately, with a MS Visual C++ Runtime dialog
telling me that it’s requested to terminate the app in an unusual way,
and a sole OK button. There’s no logs, standard output, anything.

Does anyone have some insight as to how I could circumvent this problem?

Some details: I’m trying to embed MRI ruby 1.8.7 (2008-08-11 patchlevel
72) [i386-mswin32] through a DLL compiled using MinGW gcc on WinXP SP2,
and tried to run it on SP3.

thx in advance
mortee

Some details: I’m trying to embed MRI ruby 1.8.7 (2008-08-11 patchlevel
72) [i386-mswin32] through a DLL compiled using MinGW gcc on WinXP SP2,
and tried to run it on SP3.

How about the rubyinstaller version?
-rp

On 04/07/2010 00:48, Roger P. wrote:

Some details: I’m trying to embed MRI ruby 1.8.7 (2008-08-11 patchlevel
72) [i386-mswin32] through a DLL compiled using MinGW gcc on WinXP SP2,
and tried to run it on SP3.

How about the rubyinstaller version?
-rp

I’ve tried using the latest versions from the rubyinstaller page, though
not the self-installing versions, but the 7zip stuff. It still crashes
using both of these:

ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32]
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-mingw32]

Does anyone have some insight as to how I could circumvent this problem?

Make sure to run your ruby code in only one thread at a time and only
from the “main” thread (?)

You could post backtraces, as well.
-rp

Make sure to run your ruby code in only one thread at a time and only
from the “main” thread (?)

Well, I’m making sure to call it from a single thread, but I can’t force
to do it from the main one. I’m writing an extension for a 3rd party
app, which calls my code from whatever thread it wants to, and it’s
definitely not the main one.

You could post backtraces, as well.

I’d be glad to, but as I’ve said already, I have no logs (at least not
at this level), and no terminal output from the app involved. All I get
is a dialog window from the MS Visual Runtime telling me about the
crash, without any usable details.

The weird part is that non-network code (even usong multiple ruby
threads) runs without problems.

On 4/5/10, mortee [email protected] wrote:

What I’m trying is to embed a ruby interpreter into a (multi-threaded)
3rd party app (using its scripting interface and its ability to load
DLLs through it), and run my ruby code by it. After much trial and
error, I’ve managed to have it work to the extent that I can call into
my own ruby code without having it crash the app.

However, anytime I try to access any networking abilities from ruby, it
crashes the host app immediately, with a MS Visual C++ Runtime dialog
telling me that it’s requested to terminate the app in an unusual way,
and a sole OK button. There’s no logs, standard output, anything.

This is just a wild guess, but it’s possible that embedding in a
multi-threaded program is what gives you grief. Suraj Kurapatni (sp?)
was having problems with it a while ago. I don’t remember the exact
details, but it seems that ruby likes the stack(s) to be where it
wants them to be… he eventually came up with some patches to let you
at least tell ruby where the stacks actually are, but I don’t think
they were accepted. I’d point you at the relevant bug report on
redmine, but it’s seemingly down for repairs right now. :frowning:

On Apr 8, 8:01 pm, mortee [email protected] wrote:

You could post backtraces, as well.

I’d be glad to, but as I’ve said already, I have no logs (at least not
at this level), and no terminal output from the app involved. All I get
is a dialog window from the MS Visual Runtime telling me about the
crash, without any usable details.

The weird part is that non-network code (even usong multiple ruby
threads) runs without problems.

Is the application you’re embedding/calling ruby library compiled with
a newer version of Microsoft C? Can you verify it links to MSVCRT and
not MSVCR80.DLL or MSVCR90.DLL?

On 4/8/10, mortee [email protected] wrote:

Make sure to run your ruby code in only one thread at a time and only
from the “main” thread (?)

Well, I’m making sure to call it from a single thread, but I can’t force
to do it from the main one. I’m writing an extension for a 3rd party
app, which calls my code from whatever thread it wants to, and it’s
definitely not the main one.

Calling out to the ruby interpreter from a program whose source you
don’t control and not from the program’s main thread… definitely
sounds dangerous. Now that redmine is back, I went and found the bug I
mentioned before, but upon reading, that problems seems to have been
with invoking ruby from the main thread only. So, it may not help you,
directly, but maybe these bug reports will stimulate some ideas:

http://redmine.ruby-lang.org/issues/show/2258
http://redmine.ruby-lang.org/issues/show/2294

I’d be glad to, but as I’ve said already, I have no logs (at least not
at this level), and no terminal output from the app involved. All I get
is a dialog window from the MS Visual Runtime telling me about the
crash, without any usable details.

You need to get some visibility into this problem. Maybe you can run
the program within a debugger, and extract a stack dump from that when
it crashes?

Is the application you’re embedding/calling ruby library compiled with
a newer version of Microsoft C? Can you verify it links to MSVCRT and
not MSVCR80.DLL or MSVCR90.DLL?

It seems to load both msvcrt.dll and msvcr80.dll, even before hitting
any of my code. It also loads msvcp80.dll, for that matter.

mortee

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