Brent Roman wrote:
> Daz,
> 
> In our labs, we have tried controlling the instrument with an x86
> laptop running a reasonably recent 2.6 Linux kernel. 
> All our "custom hardware" interfaces to the host via three RS-232 serial
> ports, so replacing the ARM with an X86 box is quite straightforward
> in the lab (where we have the required power and space for it).
> But, alas, the same Segfault occured in this configuration as well. 
> 
> So, I believe the problem is unlikely to be particular to the ARM
> gcc compiler or its optimization settings. 
> However, I did try reducing the optimization from
> -O2 to -Os.  -Os is the optimization level used to compile
> ARM Linux kernels.  Needless to say, this had no effect.
> 
> What optimization level would you suggest?
> -O1 or -O0   ?!
> 
> Better yet:
> Are there specific optimization flag(s) that have proven troublesome
> for ruby 1.6.8?
> 
> Note that we're using GCC 3.4.5 for the embedded ARM
> (with soft-floats)
> 
> and GCC 3.3.5 or GCC 3.4.4 for our x86 laptops
> 
> - brent
> 
>> Brent Roman wrote:
>>> Help!
>> Maybe you've tried already but, if you can afford the reduced 
>> performance, compiling ruby with less optimisation might help
>> until a more suitable solution can be found?
>>
>> daz
>>
>>
>>   
> 


After posting, I found a response from Paul to your earlier thread ...
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/11224

I'd always try no optimization to start with.
(It's Od for my compiler.)

I was just jumping in with something fairly easy to try but none
of my experiences were with such complex tasks as yours.

My most annoying experience was with adding fprintf statements to
home in on a particulary elusive bug. After pruning, I was left
with three fprintf's and the bug has never surfaced again.
I learned nothing about the bug except that, if I removed those
redundant statements, it would crash.

As has been said, I read on here that many GC bugs have been tackled
and traps built into the core for others, since 1.6.8, but I can't
recommend anything more highly than biting the bullet on an upgrade.

The performance improvement would be a bonus, assuming the bug went.

I know the problems with change management on mainframes and I'd
live by the "If it ain't broke, don't fix it" rule ... until some
authority figure appeared and pointed out to me that it *is* broke.

As I have no authority - I'll exit this thread and wish you well.


daz