perhaps that would help with the 64-bit stuffs?
If not then you may want to open a bug report there--they were speedy
to look at my last one, and they do advertise 64-bit compatibility and
seem to expect it.
Thanks for your help.
-=R
On Nov 3, 11:03 pm, spicyj <spicyjalap...@gmail.com> wrote:
> perhaps that would help with the 64-bit stuffs? > If not then you may want to open a bug report there--they were speedy > to look at my last one, and they do advertise 64-bit compatibility and > seem to expect it. > Thanks for your help.
Hm interesting. :) Thanks for contacting the tcmalloc team Roger. I guess I should take a look at this again.
That said, I still don't have stable access to a Mac. Does anybody have a 64-bit OS X server and can provide me with SSH access? Preferably something that I can have access to for a long time, so that I don't have to keep asking for OS X access. :)
-- Phusion | The Computer Science Company
Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
> > perhaps that would help with the 64-bit stuffs?
> > If not then you may want to open a bug report there--they were speedy
> > to look at my last one, and they do advertise 64-bit compatibility and
> > seem to expect it.
> > Thanks for your help.
> Hm interesting. :) Thanks for contacting thetcmallocteam Roger. I
> guess I should take a look at this again.
> That said, I still don't have stable access to a Mac. Does anybody have
> a 64-bit OS X server and can provide me with SSH access? Preferably
> something that I can have access to for a long time, so that I don't
> have to keep asking for OS X access. :)
Thanks for another great release. Have you had the time to take a look
at 64-bit tcmalloc whilst improving Mac OS X support? What are the
specific issues to get 64-bit tcmalloc to work with REE?
Roderick van Domburg wrote: > Thanks for another great release. Have you had the time to take a look > at 64-bit tcmalloc whilst improving Mac OS X support? What are the > specific issues to get 64-bit tcmalloc to work with REE?
Yes I had. Tcmalloc fails to compile on 64-bit platforms. It requires libunwind, but I wasn't able to compile libunwind on any 64-bit platform that I've tried.
-- Phusion | The Computer Science Company
Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
> Roderick van Domburg wrote: >> Thanks for another great release. Have you had the time to take a >> look >> at 64-bit tcmalloc whilst improving Mac OS X support? What are the >> specific issues to get 64-bit tcmalloc to work with REE?
> Yes I had. Tcmalloc fails to compile on 64-bit platforms. It requires > libunwind, but I wasn't able to compile libunwind on any 64-bit > platform > that I've tried.
Minutes ago I successfully compiled libunwind-0.98.6 on 64-bit CentOS 5.2. This is with gcc 4.1.2 and glibc 2.5.
I'm running Ruby Enterprise Edition on a vanilla 64-bit installation
of Intrepid (Ubuntu 8.10 - 2.6.27-10-generic #1 SMP Fri Nov 21
19:19:18 UTC 2008 x86_64 GNU/Linux). I patched the installer to
remove the 64-bit check and fixed the hack to the include paths.
tcmalloc builds just fine without libunwind, and REE is working great
with tcmalloc:
> > Roderick van Domburg wrote:
> >> Thanks for another great release. Have you had the time to take a
> >> look
> >> at 64-bit tcmalloc whilst improving Mac OS X support? What are the
> >> specific issues to get 64-bit tcmalloc to work with REE?
> > Yes I had. Tcmalloc fails to compile on 64-bit platforms. It requires
> > libunwind, but I wasn't able to compile libunwind on any 64-bit
> > platform
> > that I've tried.
> Minutes ago I successfully compiled libunwind-0.98.6 on 64-bit CentOS
> 5.2. This is with gcc 4.1.2 and glibc 2.5.
> I'm running Ruby Enterprise Edition on a vanilla 64-bit installation
> of Intrepid (Ubuntu 8.10 - 2.6.27-10-generic #1 SMP Fri Nov 21
> 19:19:18 UTC 2008 x86_64 GNU/Linux). I patched the installer to
> remove the 64-bit check and fixed the hack to the include paths.
> tcmalloc builds just fine without libunwind, and REE is working great
> with tcmalloc:
Nice! I tried to compile tcmalloc on 64-bit Ubuntu 8.10 as well, but it didn't work. I guess it's worth re-investigating.
As for your C_INCLUDE_PATH changes: I just reread the gcc manual and I now doubt whether C_INCLUDE_PATH is the right variable to set. Could you try the following and check whether it works?
Get rid of: ENV['C_INCLUDE_PATH'] = ... ENV['CPLUS_INCLUDE_PATH'] = ...
> Nice! I tried to compile tcmalloc on 64-bit Ubuntu 8.10 as well, but it
> didn't work. I guess it's worth re-investigating.
> As for your C_INCLUDE_PATH changes: I just reread the gcc manual and I
> now doubt whether C_INCLUDE_PATH is the right variable to set. Could you
> try the following and check whether it works?
This also compiles and runs on my OS X 10.5.5 box:
otool -L /opt/ruby-enterprise-1.8.6-20081205/bin/ruby
/opt/ruby-enterprise-1.8.6-20081205/bin/ruby:
/opt/ruby-enterprise-1.8.6-20081205/lib/libtcmalloc_minimal.
0.dylib (compatibility version 1.0.0, current version 1.0.0)
@rpath/libsystem_allocator.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.1)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
On Dec 8, 2:55 pm, Hongli Lai <hon...@phusion.nl> wrote:
We've been using REE 20081205 64bit + Passenger 2.0.5 on Centos 5
systems for a few days without any problems. Compiled just fine.
And... it's about 20% faster!
On Dec 8, 2:26 pm, "set...@sethbc.org" <set...@gmail.com> wrote:
> This also compiles and runs on my OS X 10.5.5 box:
> otool -L /opt/ruby-enterprise-1.8.6-20081205/bin/ruby
> /opt/ruby-enterprise-1.8.6-20081205/bin/ruby:
> /opt/ruby-enterprise-1.8.6-20081205/lib/libtcmalloc_minimal.
> 0.dylib (compatibility version 1.0.0, current version 1.0.0)
> @rpath/libsystem_allocator.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 111.1.1)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 227.0.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> current version 1.0.0)
> On Dec 8, 2:55 pm, Hongli Lai <hon...@phusion.nl> wrote:
> > set...@sethbc.org wrote:
> > > Works fine with the CPATH change.
> > > I'll update my patch on github (it was reversed anyways).
> Alright. Can anybody else who had compilation problems confirm that > this > change works?
+1. I applied the patch and it has been working well on one CentOS 5.2 x86_64 box.
One thing I have noticed - though this may not be exclusive to 64-bit REE+tcmalloc - is that REE segfaults if it tries to run its own installer. Is this a known issue?
On Sat, Dec 13, 2008 at 12:41 PM, Roderick van Domburg
<r.s.a.vandomb...@nedforce.nl> wrote: > +1. I applied the patch and it has been working well on one CentOS 5.2 > x86_64 box.
We're currently testing 64-bit compatibility, but it looks good so far.
> One thing I have noticed - though this may not be exclusive to 64-bit > REE+tcmalloc - is that REE segfaults if it tries to run its own > installer. Is this a known issue?
Some people have reported it, but so far we've been unable to reproduce this problem, and we don't know what's causing this.
-- Phusion | The Computer Science Company
Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
>> One thing I have noticed - though this may not be exclusive to 64-bit >> REE+tcmalloc - is that REE segfaults if it tries to run its own >> installer. Is this a known issue?
> Some people have reported it, but so far we've been unable to > reproduce this problem, and we don't know what's causing this.
Let me know if I can provide any debug information to you.
[root@localhost ruby-enterprise-1.8.6-20081215]# uname -a Linux localhost 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ruby-enterprise-1.8.6-20081215]# ree-version Ruby Enterprise Edition version 1.8.6-20081215
[root@localhost ruby-enterprise-1.8.6-20081215]# gdb ruby GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run -d installer.rb Starting program: /opt/ruby-enterprise-1.8.6-20081215/bin/ruby -d installer.rb Exception `Errno::ENOENT' at ./platform_info.rb:152 - No such file or directory - /etc/lsb-release Welcome to the Ruby Enterprise Edition installer This installer will help you install Ruby Enterprise Edition 1.8.6-20081215. Don't worry, none of your system files will be touched if you don't want them to, so there is no risk that things will screw up.
You can expect this from the installation process:
1. Ruby Enterprise Edition will be compiled and optimized for speed for this system. 2. Ruby on Rails will be installed for Ruby Enterprise Edition. 3. You will learn how to tell Phusion Passenger to use Ruby Enterprise Edition instead of regular Ruby.
Press Enter to continue, or Ctrl-C to abort.
Checking for required software...
* C compiler... found at /usr/bin/gcc * Zlib development headers... [Detaching after fork from child process 19332. (Try `set detach-on-fork off'.)] found * OpenSSL development headers... [Detaching after fork from child process 19337.] found -------------------------------------------- Target directory
Where would you like to install Ruby Enterprise Edition to? (All Ruby Enterprise Edition files will be put inside that directory.)
[/opt/ruby-enterprise-1.8.6-20081215] : -------------------------------------------- Compiling and optimizing the memory allocator for Ruby Enterprise Edition In the mean time, feel free to grab a cup of coffee.
It looks like the source is already configured. Skipping configure script... make libtcmalloc_minimal.la [Detaching after fork from child process 19342.] make: `libtcmalloc_minimal.la' is up to date. mkdir -p /opt/ruby-enterprise-1.8.6-20081215/lib [Detaching after fork from child process 19343.] cp .libs/libtcmalloc_minimal*.so* '/opt/ruby-enterprise-1.8.6-20081215/ lib/' [Detaching after fork from child process 19344.]
Program received signal SIGSEGV, Segmentation fault. 0x0000000000007136 in ?? () (gdb) bt #0 0x0000000000007136 in ?? () #1 0x00002b9248fc999d in malloc (size=24) at src/tcmalloc.cc:2132 #2 0x000000000042f534 in ruby_xmalloc (size=<value optimized out>) at gc.c:117 #3 0x00000000004726dc in st_init_table_with_size (type=0x6c9660, size=11) at st.c:159 #4 0x000000000048288a in rb_ivar_set (obj=300183000, id=4841, val=1) at variable.c:1061 #5 0x000000000045ce14 in rb_waitpid (pid=19344, st=0x7fff61aecd94, flags=0) at process.c:208 #6 0x000000000045ce94 in rb_syswait (pid=19344) at process.c:1436 #7 0x000000000045cfe9 in rb_f_system (argc=1, argv=<value optimized out>) at process.c:1589 #8 0x000000000041aa5a in rb_call0 (klass=296462640, recv=300198560, id=9049, oid=9049, argc=1, argv=0x7fff61aed0d0, body=0x11a9f1a8, flags=<value optimized out>) at eval.c:5870 #9 0x000000000041b768 in rb_call (klass=296462640, recv=300198560, mid=9049, argc=1, argv=0x7fff61aed0d0, scope=1, self=300198560) at eval.c: 6117 #10 0x0000000000416623 in rb_eval (self=<value optimized out>, n=<value optimized out>) at eval.c:3505 #11 0x0000000000416683 in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3434 #12 0x000000000041b2b0 in rb_call0 (klass=300217560, recv=300198560, id=11049, oid=<value optimized out>, argc=0, argv=0x7fff61aeda90, body=0x11a7c860, flags=<value optimized out>) at eval.c:6021 #13 0x000000000041b768 in rb_call (klass=300217560, recv=300198560, mid=11049, argc=1, argv=0x7fff61aeda90, scope=1, self=300198560) at eval.c: 6117 #14 0x0000000000416623 in rb_eval (self=<value optimized out>, n=<value optimized out>) at eval.c:3505 #15 0x0000000000419890 in rb_yield_0 (val=6, self=300198560, klass=0, flags=0, avalue=0) at eval.c:5052 #16 0x00000000004167d2 in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3295 #17 0x000000000041556c in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3685 #18 0x0000000000419890 in rb_yield_0 (val=300184720, self=300198560, klass=0, flags=0, avalue=0) at eval.c:5052 #19 0x000000000040fa5b in rb_ensure (b_proc=0x490b20 <chdir_yield>, data1=140734832241152, e_proc=0x490ae0 <chdir_restore>, data2=140734832241152) at eval.c:5519 #20 0x0000000000490a53 in dir_s_chdir (argc=1, argv=<value optimized out>, obj=<value optimized out>) at dir.c:816 #21 0x000000000041aa5a in rb_call0 (klass=296358320, recv=296358360, id=8593, oid=8593, argc=1, argv=0x7fff61aeed00, body=0x11aa0d00, flags=<value optimized out>) at eval.c:5870 #22 0x000000000041b768 in rb_call (klass=296358320, recv=296358360, mid=8593, argc=1, argv=0x7fff61aeed00, scope=0, self=300198560) at eval.c: 6117 #23 0x00000000004164eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3490 #24 0x00000000004185eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3220 #25 0x000000000041b2b0 in rb_call0 (klass=300217560, recv=300198560, id=11057, oid=<value optimized out>, argc=0, argv=0x7fff61aef6c0, body=0x11a79868, flags=<value optimized out>) at eval.c:6021 #26 0x000000000041b768 in rb_call (klass=300217560, recv=300198560, mid=11057, argc=2, argv=0x7fff61aef6b0, scope=1, self=300198560) at eval.c: 6117 #27 0x0000000000416623 in rb_eval (self=<value optimized out>, n=<value optimized out>) at eval.c:3505 #28 0x00000000004185eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3220 #29 0x0000000000416683 in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3434 #30 0x000000000041b2b0 in rb_call0 (klass=300217560, recv=300198560, id=10801, oid=<value optimized out>, argc=0, argv=0x7fff61af0678, body=0x11a8d4a8, flags=<value optimized out>) at eval.c:6021 #31 0x000000000041b768 in rb_call (klass=300217560, recv=300198560, mid=10801, argc=0, argv=0x7fff61af0678, scope=1, self=6) at eval.c:6117 #32 0x0000000000423d81 in rb_f_send (argc=1, argv=0x7fff61af0670, recv=300198560) at eval.c:6165 #33 0x000000000041aa5a in rb_call0 (klass=296462640, recv=300198560, id=4057, oid=4057, argc=1, argv=0x7fff61af0670, body=0x11ab69e8, flags=<value optimized out>) at eval.c:5870 #34 0x000000000041b768 in rb_call (klass=296462640, recv=300198560, mid=4057, argc=1, argv=0x7fff61af0670, scope=0, self=300198560) at eval.c: 6117 #35 0x00000000004164eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3490 #36 0x00000000004175cb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3051 #37 0x0000000000419890 in rb_yield_0 (val=2765070, self=300198560, klass=0, flags=0, avalue=0) at eval.c:5052 #38 0x0000000000485863 in rb_ary_each (ary=300187040) at array.c:1145 #39 0x000000000041aa5a in rb_call0 (klass=296401160, recv=300187040, id=3841, oid=3841, argc=0, argv=0x0, body=0x11aab0c0, flags=<value optimized out>) at eval.c:5870 #40 0x000000000041b768 in rb_call (klass=296401160, recv=300187040, mid=3841, argc=0, argv=0x0, scope=0, self=300198560) at eval.c:6117 #41 0x00000000004164eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3490 #42 0x00000000004185eb in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3220 #43 0x0000000000417ef1 in rb_eval (self=300198560, n=<value optimized out>) at eval.c:3354 #44 0x000000000041b2b0 in rb_call0 (klass=300217560, recv=300198560, id=5065, oid=<value optimized out>, argc=0, argv=0x7fff61af1f18, body=0x11a957c0, flags=<value optimized out>) at eval.c:6021 #45 0x000000000041b768 in rb_call (klass=300217560, recv=300198560, mid=5065, argc=1, argv=0x7fff61af1f10, scope=0, self=296452920) at eval.c: 6117 #46 0x00000000004164eb in rb_eval (self=296452920, n=<value optimized out>) at eval.c:3490 #47 0x0000000000426f09 in ruby_exec_internal () at eval.c:1642 #48 0x0000000000426f55 in ruby_exec () at eval.c:1662 #49 0x0000000000426f7f in ruby_run () at eval.c:1672 #50 0x000000000040dd63 in main (argc=3, argv=0x7fff61af2518, envp=<value optimized out>) at main.c:48
Roderick van Domburg wrote: > Certainly. The segfault seems to be triggered when the > libtcmalloc_minimal.so files are copied over to their target directory.
> The following output is from a directory of REE sources that was > already built. Using a clean installation directory yields the same > results. > ... > cp .libs/libtcmalloc_minimal*.so* '/opt/ruby-enterprise-1.8.6-20081215/ > lib/' > [Detaching after fork from child process 19344.]
> Program received signal SIGSEGV, Segmentation fault.
Ah so you're running the REE installer in REE. Can you verify that the segfault does not happen if you use /usr/bin/ruby to run the installer?
-- Phusion | The Computer Science Company
Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
Hongli Lai wrote: > Ah so you're running the REE installer in REE. Can you verify that the > segfault does not happen if you use /usr/bin/ruby to run the installer?
Sorry please ignore this message, I haven't slept very well. You were the one who reported that /usr/bin/ruby runs fine in the first place.
I'll fix this problem ASAP.
-- Phusion | The Computer Science Company
Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
> Hongli Lai wrote: >> Ah so you're running the REE installer in REE. Can you verify that >> the >> segfault does not happen if you use /usr/bin/ruby to run the >> installer?
> Sorry please ignore this message, I haven't slept very well. You were > the one who reported that /usr/bin/ruby runs fine in the first place.