Forum: Typo Cross-thread violation & how I fixed the problem

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? ;-) )

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

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? ;-) )

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

Matijs van Zuijlen wrote:
>(Anybody else 
>> dislike the new intel mac's? ;-) )

No! :)

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

Jay Levitt wrote:
> Matijs van Zuijlen wrote:
>> (Anybody else
>>> dislike the new intel mac's? ;-) ) 
>
> No! :)
>
> Jay Levitt
> 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

;-) 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 
;-)
And I don't think it's the screen.

Thomas Gallaway wrote:
>   Processor Speed:    2.7 GHz
>   Number Of CPUs:    2
>   L2 Cache (per CPU):    512 KB
>   Memory:    6 GB
>   23" Cinema Display
> 
> ;-) 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 ;-)
> 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 ;-).

Hi,

Using Macports or system Ruby?

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:
      - :update_sources => true
      - :verbose => true
      - :benchmark => false
      - :backtrace => false
      - :bulk_threshold => 1000
      - :sources => ["http://gems.rubyforge.org/", 
"http://gems.github.com"]
   - REMOTE SOURCES:
      - http://gems.rubyforge.org/
      - http://gems.github.com
lhc:/var/www/atomlab atom$ port version
Version: 1.710

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... :)

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

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... :)
>
> 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. ;-)
I wonder if the daley lama gives coding advice now?

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.

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% :(