has anyone had any success getting ruby-prof working on amd64 linux?
Specifically, has anyone managed to deal with this error, or know what
it is referring to:
/home/dan/ruby$ ruby-prof prime.rb
/usr/local/lib/ruby/gems/1.8/gems/ruby-prof-0.4.1/bin/ruby-prof:154:in load': integer 23456248293192 too big to convert toint’ (RangeError)
from
/usr/local/lib/ruby/gems/1.8/gems/ruby-prof-0.4.1/bin/ruby-prof:154
from /usr/local/bin/ruby-prof:18
(this happens with any ruby script)
There are a couple of people who have mentioned it on the rubyforge
project page but without any apparent resolutions, other than that
nothing on google.
thanks,
Dan
for ref:
/home/dan/ruby$ uname -a
Linux x1-6-00 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16 01:50:50
UTC 2006 x86_64 GNU/Linux
/home/dan/ruby$ ruby -v
ruby 1.8.4 (2005-12-24) [x86_64-linux]
As you probably know, most 64-bit processors use the LP64 model (i.e.
ints are 32 bits, longs and pointers 64 bits). Many things that people
assume are ints on a 32-bit system actually are longs on a 64 bit
system. This is why people should really use the C types properly, in
other words, size_t for lengths and ptrdiff_t for pointer arithmetic,
instead of int. size_t is unsigned on 32-bits, but unsigned long on 64
bits. Also, I think thread ids are 32-bit on 32-bit systems, but 64-bit
on 64-bit systems. Look at the type of pthread_t in sys/types.h on your
AMD-64 system.
So the following code from ruby_prof.c is going to present problems on
64 bit systems:
typedef struct {
/* Cache hash value for speed reasons. /
st_data_t key;
VALUE klass;
ID mid;
int thread_id; / Edwin says: should be pthread_t thread_id*/
… etc …
}
Also, this code could be an issue:
static inline prof_data_t *
stack_push(prof_stack_t stack)
{
if (stack->ptr == stack->end) {
int len, new_capa; / Edwin says: Naughty, naughty - should use
ptrdiff_t len, not int len*/
len = stack->ptr - stack->start; /* Edwin says: result is actually
ptrdiff_t, not int (ptrdiff_t will be unsigned long on LP64)*/
new_capa = (stack->end - stack->start) * 2;
REALLOC_N(stack->start, prof_data_t, new_capa);
stack->ptr = stack->start + len;
stack->end = stack->start + new_capa;
}
return stack->ptr++;
}
Judicious changes of int to a suitable portable data type would most
likely solve these issues.
As you probably know, most 64-bit processors use the LP64 model (i.e.
ints are 32 bits, longs and pointers 64 bits).
Until now, not really
Judicious changes of int to a suitable portable data type would most
likely solve these issues.
Woo-hoo! Yes it does, almost immediately. Thank you so much Edwin,
you’ve been a big help. Oh, look at those pretty call graphs!
For future googlers, here is the diff from changes I made to get
ruby-prof working on amd64, 64bit, after receiving an error like this:
integer 23456248293320 too big to convert to `int’ (RangeError)
