Cross-thread violation & how I fixed the problem


#1

I just spent 2 days figuring this out but it seems the issue is one of
the gems in the vendor/gems directory.

Machine is a Mac Mini G4 1.25ghzisch with 10.4.6isch? (Anybody else
dislike the new intel mac’s? :wink: )

I completely removed ruby & made sure it was using the macports version
and after pretty much nuking every single gem and gem install typo on a
empty directory stll got this:

lhc:/var/www/atomlab root# rake db:create RAILS_ENV=‘production’
(in /private/var/www/atomlab)
config.gem: Unpacked gem calendar_date_select-1.15 in vendor/gems has no
specification file. Run ‘rake gems:refresh_specs’ to fix this.
config.gem: Unpacked gem coderay-0.8.260 in vendor/gems has no
specification file. Run ‘rake gems:refresh_specs’ to fix this.
config.gem: Unpacked gem htmlentities-4.0.0 in vendor/gems has no
specification file. Run ‘rake gems:refresh_specs’ to fix this.
config.gem: Unpacked gem json-1.1.3 in vendor/gems has no specification
file. Run ‘rake gems:refresh_specs’ to fix this.
[BUG] cross-thread violation on rb_gc()
ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0]

So I went ahead and mv vendor/gems/* /tmp/gems/

Of course now I was getting:
lhc:/var/www/atomlab root# rake db:create
(in /private/var/www/atomlab)
rake aborted!
no such file to load – coderay

After
gem install coderay htmlentities json calendar_date_select

drumroll
lhc:/var/www/atomlab atom$ rake db:migrate RAILS_ENV=‘production’
(in /private/var/www/atomlab)
== InitialSchema: migrating

– create_table(:users)
-> 0.0712s
– create_table(:articles)
-> 0.1310s
– add_index(:articles, :permalink)

We have migrationage!

Oh I then ran
lhc:/var/www/atomlab atom$ sudo rake gems:unpack
Password:
(in /private/var/www/atomlab)
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/coderay-0.8.312’
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/htmlentities-4.0.0’
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/json-1.1.4’
Unpacked gem:
‘/private/var/www/atomlab/vendor/gems/calendar_date_select-1.15’

– Atom


#2

Matijs van Zuijlen wrote:

(Anybody else

dislike the new intel mac’s? :wink: )

No! :slight_smile:

Jay L.
Mac Pro (early 2008), 8-core 3.2GHz Xeon, 16GB RAM


#3

Thomas Gallaway wrote:

I just spent 2 days figuring this out but it seems the issue is one of
the gems in the vendor/gems directory.

Thanks a lot for doing this figuring out.

Machine is a Mac Mini G4 1.25ghzisch with 10.4.6isch? (Anybody else
dislike the new intel mac’s? :wink: )

He he, that reminds me I have an iBook G3 running Ubuntu I could test
this on.

[…]

We have migrationage!

Yay!

Oh I then ran
lhc:/var/www/atomlab atom$ sudo rake gems:unpack
Password:
(in /private/var/www/atomlab)
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/coderay-0.8.312’
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/htmlentities-4.0.0’
Unpacked gem: ‘/private/var/www/atomlab/vendor/gems/json-1.1.4’
Unpacked gem:
‘/private/var/www/atomlab/vendor/gems/calendar_date_select-1.15’

One thing I wonder is whether migrations still work now that you did the
unpack.

Fellow developers, do we still need the unpacked gems in vendor/gems, or
can we just have them installed?

Regards,
Matijs


#4

Jay L. wrote:

Matijs van Zuijlen wrote:

(Anybody else

dislike the new intel mac’s? :wink: )

No! :slight_smile:

Jay L.
Mac Pro (early 2008), 8-core 3.2GHz Xeon, 16GB RAM
Processor Name: PowerPC G5 (3.1)
Processor Speed: 2.7 GHz
Number Of CPUs: 2
L2 Cache (per CPU): 512 KB
Memory: 6 GB
23" Cinema Display

:wink: I love my G5. How is the 8-core Mac Pro?
It seem to not feel as “creative” when working on my Intel Macbook vs.
The PPC.
Or rather when I start a project on the Macbook nothing works ever heh
:wink:
And I don’t think it’s the screen.


#5

Hi,

Using Macports or system Ruby?


#6

Scott M. Likens wrote:

Hi,

Using Macports or system Ruby?

lhc:/var/www/atomlab atom$ gem env
RubyGems Environment:

  • RUBYGEMS VERSION: 1.3.2
  • RUBY VERSION: 1.8.7 (2009-04-08 patchlevel 160) [powerpc-darwin8]
  • INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8
  • RUBY EXECUTABLE: /opt/local/bin/ruby
  • EXECUTABLE DIRECTORY: /opt/local/bin
  • RUBYGEMS PLATFORMS:
    • ruby
    • powerpc-darwin-8
  • GEM PATHS:
    • /opt/local/lib/ruby/gems/1.8
    • /Users/atom/.gem/ruby/1.8
  • GEM CONFIGURATION:
  • REMOTE SOURCES:

#7

Ahh,

Then you need to remove any other offending ruby libraries that do not
reside in /opt/local/lib

Next time try not to find ancient arcane bugs that make me think your
running panther… :slight_smile:

FYI, it’s usually just in /usr/lib (libruby??.dylib??)


#8

Thomas Gallaway wrote:

Processor Speed: 2.7 GHz
Number Of CPUs: 2
L2 Cache (per CPU): 512 KB
Memory: 6 GB
23" Cinema Display

:wink: I love my G5. How is the 8-core Mac Pro?
It seem to not feel as “creative” when working on my Intel Macbook vs.
The PPC.
Or rather when I start a project on the Macbook nothing works ever heh :wink:
And I don’t think it’s the screen.

Everything works just fine on my MacBook with measly 2GB memory …
running
Linux :-D. You can draw your own conclusions ;-).


#9

Scott M. Likens wrote:

Ahh,

Then you need to remove any other offending ruby libraries that do not
reside in /opt/local/lib

Next time try not to find ancient arcane bugs that make me think your
running panther… :slight_smile:

FYI, it’s usually just in /usr/lib (libruby??.dylib??)
yeah okay I guess your right (just they where hiding in /usr/lib).

libruby.1.dylib:
/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current
version 1.8.2)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.1.11)
lhc:/usr/lib atom$ otool -L libruby.dylib
libruby.dylib:
/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current
version 1.8.2)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.1.11)

cause I looked in /opt/local/lib
lhc:/opt/local/lib atom$ otool -L libruby.1.8.dylib
libruby.1.8.dylib:
/opt/local/lib/libruby.dylib (compatibility version 1.8.0, current
version 1.8.7)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.1.11)

so I just removed the 2 in /usr/lib and put the original gems back and
the json
gem did not produce the violation anymore.

Sometimes the all mighty google is just not as mighty when researching
this. :wink:
I wonder if the daley lama gives coding advice now?


#10

Thomas Gallaway wrote:

Scott M. Likens wrote:

Ahh,

Then you need to remove any other offending ruby libraries that do not
reside in /opt/local/lib

I ran into this too… running out the door but I will look in a few
hours.
Mac Ruby comes with its own gems in /Library, and /usr/bin/gem won’t
delete
them, but it won’t tell you that, either. So if you somehow got that
into
your gempath, and/or if you somehow run /usr/bin/gem or /usr/bin/ruby
sometimes instead of /opt/local/bin/ruby… it gets very very confusing.

More later.


#11

Glad to hear it.

It’s amazing the kind of things you can find in the weirdest places, I
ran into this and was able to reproduce it on Tiger quite well as it’s
a bit easier to escape that problem on Leopard it’s just not as 100% :frowning: