Getting a Debugger set up for Ruby

I am building a Ruby C Extension in XCode. It is working, but there are some annoying EXC_BAD_ACCESS errors that I am finding really difficult to see where it is coming from.

XCode debugger gives me just this information:

    0x1003cce9a <+0>:  pushq  %rbp
    0x1003cce9b <+1>:  movq   %rsp, %rbp
    0x1003cce9e <+4>:  movslq %esi, %rax
    0x1003ccea1 <+7>:  movq   0x378(%rdi), %rcx
->  0x1003ccea8 <+14>: movq   (%rcx,%rax,8), %rax  CrBrowserMain (1): EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    0x1003cceac <+18>: popq   %rbp
    0x1003ccead <+19>: retq   

using lldb, I have done a backtrace with the following results (back to 15 frames only):

thread #1, name = 'CrBrowserMain', queue = '', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00000001003ccea8 SketchUp`CComponentDefinition::GetInstance(int) + 14
    frame #1: 0x00000001004c96f9 SketchUp`___lldb_unnamed_symbol7166$$SketchUp + 86
    frame #2: 0x0000000100e01ebe Ruby`vm_call_cfunc + 302
    frame #3: 0x0000000100de7bed Ruby`vm_exec_core + 13725
    frame #4: 0x0000000100dfc19e Ruby`vm_exec + 142
    frame #5: 0x0000000100df1eef Ruby`rb_funcallv + 559
    frame #6: 0x000000010054f030 SketchUp`___lldb_unnamed_symbol8556$$SketchUp + 262
    frame #7: 0x0000000100c989b3 Ruby`rb_protect + 339
    frame #8: 0x000000010054eec2 SketchUp`protect_funcall(unsigned long, unsigned long, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> > const&) + 255
    frame #9: 0x000000010054ec76 SketchUp`protect_funcall(unsigned long, unsigned long, int, ...) + 305
    frame #10: 0x0000000100523b4a SketchUp`sketchup::api::ruby::NotificationQueue::DispatchNotification(sketchup::api::ruby::RubyApiNotification const&) + 152
    frame #11: 0x0000000100523cfc SketchUp`sketchup::api::ruby::NotificationQueue::Dispatch() + 152
    frame #12: 0x0000000101deceb0 libCommonUtils.dylib`CNotificationCenter::SendNotification(char const*, void*) + 278
    frame #13: 0x00000001003bc4ab SketchUp`sketchup::api::SendTransactionEnd() + 39
    frame #14: 0x000000010048ac74 SketchUp`CUndoManager::CommitCurrentOperation(unsigned int, bool) + 572
    frame #15: 0x00000001004f92c9 SketchUp`___lldb_unnamed_symbol7728$$SketchUp + 168

None of the debug information that I am getting is pointing to where in my code the error is coming from. I know it is coming from my code, most likely in my ruby code, as the C errors are proving much easier to debug.

My first questions is, with errors like these, is there a debugging solution that I should be aware of? I have noticed that the XCode breakpoints in my ruby scripts don’t seem to work - the only debugging information I can get from Ruby are custom messages output with puts, and some of the common Exception Errors that the Sketchup Ruby API put out.

If the answer to the above is “yes”, then where do you recommend I look? I’ve looked at these topics without much luck on my part:

…maybe I just need to go RubyMine:?

Many thanks

Saw this …

  • Is EXC_BAD_ACCESS and How to Debug It - Code Tuts
    At one point or another, you will run into a crash caused by EXC_BAD_ACCESS . In this quick tip, you will learn what EXC_BAD_ACCESS is and what it is caused by. I will also give you a few tips to fix bugs that are caused by EXC_BAD_ACCESS.

… via a Google Search on: “EXC_I386_GPFLT”

I don’t code for Mac but it sounds like the author knows what they’re talking about.

CrBrowserMain references Chrome Browser embedded in SU.

it’s been causing odd issues on mac since day one…

you may need to point to it in Xcode or maybe turn off anything that uses it DC, TC…


1 Like

Yes, that page did help me in my early experiences with the error. However, it is limited with my particular case, where the EXC_BAD_ACCESS is happening deep within Sketchup’s own functions.

That’s a good tip. I was wondering what a Chrome Browser was doing in there - DC maybe the issue…

To answer my own question. I found that using the ruby debugger on lldb allowed me to do backtraces when things went wrong.

This article tells you how it’s done:

1 Like

When working with Ruby C Extensions it can be challenging to debug since the Ruby Debugger only works for .rb sources and your C/C++ debugger won’t give you all Ruby info you need.

I find VSCode easier and faster to set up. (And it’s free.)

Oh, that’s interesting! Probably not something that would work on Windows though… (?)

Actually, reading this closer - it looks like it sets up lldb to be able to eval Ruby code while debugging to inspect Ruby data. But that’s so much easier to do with the Ruby debugger gem:

I’d originally thought it was to aid in Ruby C extension territory.

That’s a good tip. Will try to get that running.

As an update, I am actually resolved that the error was in fact in the dynamic components extension (after one of my observer callbacks).

1 Like