Help for a total noob trying to debug for the first time

Ruby Development
1

I’m a one-day-old Ruby programmer, with 30 years of Perl programming. I have a MSCS (from FAU go Owls!) and I’ve been a computer professional since my US ARMY COBOL days in the mid 70s.

I need a bootstrap load for Ruby debugging please! At this point I’m stumbling about trying to run debugger on a code base which is largely foreign to me. The code I can figure out- the debugger not so much…

We have Ruby 1.8.6 on linux (we can’t upgrade the version due to SOX and other inhibitors)

Some quandries:

  1. invoking the debugger. Most references tell me to use shell> rdbg , which on our system is an unknown command. I also looked at pry and other options but apparently we need ruby >2.0 for most. I DID get ruby -rdebug to work, which I’m hoping is the functional equivalent of rdgb? Maybe I need an alias? But at least I’m in SOME debugger of some variety? Do I need a require debugger in my source?

  2. I’ve read many debugging guides, most of which look like expanded versions of what “h” provides. But many things don’t seem to work as described or are indeterminant, for example:

i[nfo] if supposed to show variables but instead seems tells me undefined variable “i”
v , same thing, undefined var or method
th same thing (and what is a thread? I know what one is in a “CS” context, but they’re so rarely used, it seems odd they’re so prominent as a debugger term)
Most other help items only result in “undefined var or method” . Luckily, n,s,c,l and b all seem to work almost like Perl dbg so I can at least do basic debugging.

When code execution stops, it eventually tells me a .rb file name and line number it stopped at. But only after a huge list like:

/home/user/me/code …/code/ …/code/ …/code/ …/code/ …/code./ (repeat about 25 more times) …/code/myfile.rb: 55: . I don’t know what that list is even telling me (maybe how many times I descended into a call or loop?) and I certainly don’t want it displayed at every break. Is that in the config (my config command doesnt work) where maybe I can turn it off?

Also, I don’t find in the references some things I need to do:

in perl dbg, R restarts the program from the beginning. I don’t see an equivalent. I tried R and r; R errors, but lowercase r locked up my PUTTY Session so badly, the only escape was to X out of the window! Not a very useful command, that! it’s a bit amazing that no references mention this essential command to restart. Maybe it’s hidden in the frames stuff?

How do I perform a statement, like i++ or something like that? is that “eval” ?

Can I view the stack?

How do I pop out of the current method to the caller?

Finally, I see references to something called “frames”. I don’t know what those are. Maybe scope contexts? I googled “ruby frames” and saw nothing related to coding, but I did see some nice picture frames on etsy! But seriously, if you’re writing a beginners guide, using undecipherable terms like “frame” confounds a reader, particularly when its not a concise CS term, nor can it be referenced on google searches.

If you can spare a few moments to help a Ruby Nuby, it’s greatly appreciated. I’ve made some progress and can navigate through the code a bit, but I’m quite confused about many commands and concepts., particulaly when help says what they do , and they clearly do not do that. It seems like whatever h[elp] says should, as a minimum, do what it says it does?

The CODE side I’m OK, It’s pretty intuitive and the OO syntax is refreshing after Perl.

2

That’s a completely irrelevant info to the question you’ve asked.

This won’t be useful, but coming to the point, Ruby 1.8.6 is completely EOL. I can’t even compile it with the modern compilers and toolchain.

For the (1), you need to install rdbg if it’s not present. You can run gem install rdbg with proper permission.

For (2), the command i should show you the information about current frames. It should show you variables. th shows you the list of threads. And the other stuff are behaving as you expect them to behave. To perform i increment by 1, you do eval i += 1, just normal Ruby syntax.

Note that Ruby Rdbg compatible with Ruby 1.8.6 might have bugs, and it’s not suggested at all to use ancient software, you should migrate.

3

That’s a completely irrelevant info to the question you’ve asked.

not really - on many forums I help on, its useful to understand if the question come from a student, hobbiest, professional, etc. It frames the entire context of the reply.

4

Yes , tell SOX for us won’t you? But I’ll push the issue. The answer so far is “We can’t make OS or interpreter/compiler changes due to SOX requirements”… I won’t even TELL you our linux version you’d be shocked!

5

This is telling you “Line 55 of the file myfile.rb”. That’s the line in that file that executed something that eventually caused the stop. You’ll see more files and line numbers, representing the call Stack.

Of all those files, I’ll ignore anything that is not in my control (libraries, frameworks), and focus on files in my code base. Go directly to that line of code a see what’s there.

What is SOX?

6

It’s great to see your enthusiasm for learning Ruby. Given that you’re using Ruby 1.8.6, the debugging options are limited. Here are some answers to your questions:

  1. You can use ruby -rdebug to invoke the debugger. You don’t need to add require 'debugger' in your source code.

  2. For displaying variables, use var local instead of i or v.

  3. Threads in the debugger refer to Ruby threads. You can ignore them if you’re not working with multi-threaded code.

  4. The long list of paths you mentioned seems to be a backtrace. To disable it, you can try setting $VERBOSE = nil in your code.

  5. To restart the program, you’ll need to exit the debugger and run the command ruby -rdebug again. Ruby 1.8.6 doesn’t have a built-in restart command.

  6. To evaluate an expression, use eval expression, e.g., eval i += 1.

  7. To view the stack, use the where or backtrace command.

  8. To return to the caller method, use the finish command.

  9. “Frames” refer to the stack frames or call stack. You can navigate through them using the up and down commands. Frame 0 is the current context, and higher numbers represent previous contexts.

Keep in mind that Ruby 1.8.6 is quite outdated, and upgrading to a newer version would provide you with better debugging tools like pry and byebug. However, I understand that upgrading is not an option for you due to SOX and other inhibitors. Good luck with your Ruby journey!

7

robert-b TYVM for this kind replyl after being verbally assaulted by the first reply, I had reservations about returning, but you restored my faith in this community :eyes:

I’m doing my best to convince our team that we need to update Ruby. Perhaps you can add some ammo to my fight.

Their response was “we tried to move from 1.8 to 2.7, when all the code broke, and needed a complete rewrite”…

Which seemed sort of amazing to me having lived through many many Perl updates and generally found code still ran. At most , we were advised about deprecated objects. Does that seem right to you? Would that migration normally mean a complete code rewrite?

TYVM I’ve added your text to our Ruby JIRA to assist the team.

One more question please. Our debugger (-rdebug) halts on like every warning. One happens at a line like

93: text.chomp!()

announcing that “private method chomp!” is undef. The text we’re reading in is like 25000 lines, so I have to manually step over this warning 25,000 times to get where I need to debug.

First, I’d think that chomp is NOT private but instead built-in. But I don’t know why the ! is there?
Second, can I configure debug to NOT halt on every warning?

8

SOX is some government requirement that we maintain strict control over our code and enviromments.

9

I’m glad you found my response helpful! Regarding the migration from Ruby 1.8 to 2.7, while it’s true that there might be deprecated methods and syntax changes, it shouldn’t require a complete rewrite. Some adjustments and code refactoring would be necessary, but it’s definitely worth the benefits of using an updated version.

About the debugger issue, chomp! is indeed a built-in method and should not be considered private. The exclamation mark at the end of the method (chomp!) indicates that the method modifies the object it’s called on, instead of returning a new object with the modifications.

To prevent the debugger from stopping on warnings, you can add this line at the beginning of your code:

$VERBOSE = nil

This will disable the verbose mode and should prevent the debugger from stopping on warnings. However, if you still want to see the warnings without stopping the debugger, you can try using the catch off command in the debugger to disable stopping on exceptions.

Keep in mind that turning off these warnings might make it harder to catch potential issues in your code, so use this approach cautiously.

Good luck with your Ruby debugging and the potential migration to a newer version!

10

indeed we will sir, and the time you’ve taken to explain things to me is most appreciated. I noticed a Logger setting in the code that has tracing on - I’m thinking THAT might be why Im seeing more detail than I prefer. $VERBOSE=nil seemed to help.

I’ve proposed to the team that we build another VM box with Ruby > 2.0 with the codebase there to evaluate what we need to change to migrate. As an alternative though, can we set up ONE box with two Ruby versions and perhaps use “ruby” to run 1.8 and “ruby2” to run the new one? Then we could selectively run code on one or the other?

In Perl, generally, we get several versions which will support deprecated code , with warnings, so we fix those BEFORE they go unsupported. However in our special case here, I recognize being like 12 years past its release, things may have long since gone unsupported?

TYVM you are too kind!

11

You’re most welcome! I’m glad I could help.

Regarding your question about setting up one box with two Ruby versions, yes, it is possible to have multiple Ruby versions installed on a single machine. One way to achieve this is by using a Ruby version manager such as RVM (Ruby Version Manager) or rbenv. These tools allow you to have multiple Ruby versions installed side by side and easily switch between them.

For example, using RVM, you can install Ruby 1.8 and Ruby 2.x on the same machine. Once you have both versions installed, you can set a specific Ruby version to be used for a particular project or even within the same project by specifying it in a configuration file or by running a command to switch between the versions.

To install and use RVM, follow these steps:

  1. Install RVM:
rl -sSL https://get.rvm.io | bash -s stable
  1. Load RVM into the current session:
source ~/.rvm/scripts/rvm
  1. Install Ruby 1.8.7 and Ruby 2.x:
rvm install 1.8.7
rvm install 2.x.x (replace x.x with the specific version you want to install)
  1. Set the default Ruby version for your system:
rvm use 1.8.7 --default
  1. To switch between the installed Ruby versions, use the rvm use command:
rvm use 1.8.7
rvm use 2.x.x

Regarding deprecated code and warnings, Ruby does issue warnings for deprecated features, but it’s essential to keep in mind that many things might have changed or become unsupported since Ruby 1.8.7 was released. Your plan to evaluate the codebase on a newer Ruby version is a good approach to identify and fix any potential issues before fully migrating to a newer Ruby version.

I hope this helps! If you have any other questions, feel free to ask.