Forum: Ruby cross-thread violation on rb_gc() and Windows arguments

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
017e05d1a49ffa59ea03e149e7af720b?d=identicon&s=25 Chris Shea (Guest)
on 2007-02-16 05:26
(Received via mailing list)
Hello,

I was working on a script and running into problems with passing an
argument with a wildcard with the C:\WINDOWS\System32 path. Observe:

---
C:\>more test.rb
puts ARGV

C:\>test.rb C:\ruby\*.txt
C:/ruby/ChangeLog.txt
C:/ruby/LICENSE.txt
C:/ruby/ReleaseNotes.txt

C:\>test.rb C:\WINDOWS\system32\runonce.exe
C:\WINDOWS\system32\runonce.exe

C:\>test.rb C:\WINDOWS\system32\runonce.ex*
[BUG] cross-thread violation on rb_gc()
ruby 1.8.5 (2006-08-25) [i386-mswin32]


This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.

C:\>ruby -v
ruby 1.8.5 (2006-08-25) [i386-mswin32]
---

I haven't been able to figure out or find a workaround (besides just
knowing all the filenames) or fix.

I thought Windows takes care of the wildcard, generating the argument
list. I don't know how that would help, but earlier today it made
sense to me that it meant something.

And this happens even if ARGV is never referenced (e.g. an empty
test.rb does the same thing), so it looks like the violation happens
even before the script is interpreted.

And, yes, I'm logged in with an administrator account (Windows users
usually are, aren't they?).

Anyone have any insight? Or is this just one of those things (one of
those things about working with Windows)?
Feee221f9eb7818d90625ea141bfd60c?d=identicon&s=25 bbiker (Guest)
on 2007-02-16 19:06
(Received via mailing list)
On Feb 15, 11:20 pm, "Chris Shea" <cms...@gmail.com> wrote:
> C:/ruby/ChangeLog.txt
> This application has requested the Runtime to terminate it in an
> I thought Windows takes care of the wildcard, generating the argument
> Anyone have any insight? Or is this just one of those things (one of
> those things about working with Windows)?

Not the answer you want.
I've tried on my box and it works fine ...

Have you tried: dir C:\WINDOWS\system32\runonce.ex* in a dos window?

No problem on my box

C:\Documents and Settings\Owner>dir c:\windows\system32\runonce.ex*
 Volume in drive C has no label.
 Volume Serial Number is 2CEC-6C29

 Directory of c:\windows\system32

08/10/2004  02:00 PM            14,336 runonce.exe
               1 File(s)         14,336 bytes
               0 Dir(s)  169,529,577,472 bytes free
017e05d1a49ffa59ea03e149e7af720b?d=identicon&s=25 Chris Shea (Guest)
on 2007-02-16 19:10
(Received via mailing list)
On Feb 16, 11:03 am, "bbiker" <ren...@nc.rr.com> wrote:
> > C:\>more test.rb
> > C:\>test.rb C:\WINDOWS\system32\runonce.ex*
>
>
>
>                0 Dir(s)  169,529,577,472 bytes free
Yes.  I thought of mentioning that similar wildcard arguments are fine
with Windows commands (like dir).  I've only found this to happen when
passing that argument to ruby.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2007-02-17 06:42
Chris Shea wrote:
> C:\>test.rb C:\WINDOWS\system32\runonce.ex*
> [BUG] cross-thread violation on rb_gc()
> ruby 1.8.5 (2006-08-25) [i386-mswin32]

To my knowledge, a cross-thread violation occurs when a piece of code
(which exists on a different *stack* altogether, i.e. running within a
POSIX or native thread alongside the Ruby interpreter in the same
process) makes use of Ruby's C language API.

I have encountered this when I was embedding a Ruby interpreter inside a
C program. Ruby was running inside a POSIX thread and therefore had its
own *stack*. When the C program made use of Ruby's C language API, the
entire process would crash with that cross-thread violation error.

Here, you can see why the violation is cross-thread. When the C program
(which existed on a different *stack* than the Ruby interpreter) tried
to use Ruby's C language API, those API functions would assume that the
caller existed within the Ruby interpreter's stack.

That's what I remember, anyways. Please correct me if I am wrong. :-)

P.S. The ruby-core developers, such as Nobu Nakada, are much more
knowledgeable than me; they can tell you more about this.
017e05d1a49ffa59ea03e149e7af720b?d=identicon&s=25 Chris Shea (Guest)
on 2007-02-17 09:05
(Received via mailing list)
On Feb 16, 10:42 pm, Suraj Kurapati <s...@gna.org> wrote:
> P.S. The ruby-core developers, such as Nobu Nakada, are much more
> knowledgeable than me; they can tell you more about this.

Well I wasn't sure if this was worthy of a ruby-core post.

I'm not sure if my ignorance of the causes of the underlying problem
comes from not having delved deep enough into the way Ruby handles
arguments, or from not understanding how Windows delivers arguments.

Or maybe I just don't know that this isn't an interesting problem.
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (Guest)
on 2007-02-17 15:57
(Received via mailing list)
Hi,

At Fri, 16 Feb 2007 13:25:08 +0900,
Chris Shea wrote in [ruby-talk:239448]:
> C:\>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
> ---

AFAIK, it should have been fixed in October.

> I thought Windows takes care of the wildcard, generating the argument
> list.

No, it is done by the runtime startup routine, but in very poor
manor.
This topic is locked and can not be replied to.