ruby and rdebug

[barjunk]

I'm running a ruby script like so:

ruby test.rb

and because it has some problems it eventually crashes with

'stack level too deep (SystemStackError)'.

This is a problem I'm looking into, however, if I run the program like
this:

rdebug test.rb

It doesn't crash in the same place. In fact, I haven't been able to
get it to crash at all.

What sort of things could cause this to take place? This happens in
1.8.4 and the latest 1.8.6.

I haven't finished trying to find the reason why my ruby program
crashes in the first place, but it just seems odd that it wouldn't
also crash when using rdebug.

Ideas, suggestions?

Mike B.

 

[Chiyuan Zhang]

It seems to be recursion level too deep. Have you tried to
run ruby in gdb and get a backtrace when the program faulted?
gdb /usr/bin/ruby test.rb

 

[Marc Heiler]

'stack level too deep (SystemStackError)'

I remember that usually when I have that method, there is some recursion
at work (and my fault for invoking it)

The silliest one I ever had was like this:

N = "\n" # use N for newline

variable = N
variable << ' foo'
variable << ' bar'


I am not sure this is exactly what I made wrong, but you basically see
that I somehow appended string data to the constant and then had a huge
string that was growing and growing as it was passed through multiple
methods (I am really not sure that this was the exact error, but I am
100% sure i assigned wrongly somewhere and then had the string grow
hugely)

 

[barjunk]

It seems to be recursion level too deep. Have you tried to
run ruby in gdb and get a backtrace when the program faulted?
gdb /usr/bin/ruby test.rb

Thanks. I have used gdb to trace the problem...I'm still working on
that. However, the curious part is that the error doesn't occur when
using rdebug....which is the part I'm currently trying to understand.

Mike B.

 

[barjunk]

Thanks. I have used gdb to trace the problem...I'm still working on
that. However, the curious part is that the error doesn't occur when
using rdebug....which is the part I'm currently trying to understand.

Mike B.

Further testing shows that using rdebug still fails, it just takes a
few more iterations before it does. It is still wierd that it would
fail in a different spot.

Mike B.

 

[barjunk]

Further testing shows that using rdebug still fails, it just takes a
few more iterations before it does. It is still wierd that it would
fail in a different spot.

Mike B.

Well I never figured out why rdebug behaved differently, but after
removing all my references to rb_warn from my extension...I couldn't
get it to crash.

So for some reason I don't understand at the moment, rb_warn was
causing the errors.

Mike B.

 

[Gerardo Santana Gómez Garrido]

Well I never figured out why rdebug behaved differently, but after
removing all my references to rb_warn from my extension...I couldn't
get it to crash.

Oh, it's an extension. I didn't read that before.

So for some reason I don't understand at the moment, rb_warn was
causing the errors.

Beware, because that can be deceiving. It has all the symptoms of
memory corruption. Being a C extension, it's probably that you have a
lost pointer, or writing on a memory location that you shouldn't.

 

[barjunk]

Oh, it's an extension. I didn't read that before.




Beware, because that can be deceiving. It has all the symptoms of
memory corruption. Being a C extension, it's probably that you have a
lost pointer, or writing on a memory location that you shouldn't.

I'm not sure what you are saying is deceiving? Can you elaborate some
more?

Mike B.

 

[Gerardo Santana Gómez Garrido]

When you notice that a program crashes at random locations, it's
highly probable that it's a problem of memory corruption.

This corruption may occur when you write beyond the limits of a
variable (usually a buffer, hence "buffer overflow"). The problem may
go unnoticed at run time, until the corruption reaches an unhandled
condition or the intent to overwrite the program itself.

 

[barjunk]

When you notice that a program crashes at random locations, it's
highly probable that it's a problem of memory corruption.

This corruption may occur when you write beyond the limits of a
variable (usually a buffer, hence "buffer overflow"). The problem may
go unnoticed at run time, until the corruption reaches an unhandled
condition or the intent to overwrite the program itself.

Thanks for clarifying. In this particular case the crashes weren't
really random...but I still think there were issues with pointers and
such.

Anyway, I appreciate the feedback.

Mike B.