macOS Objective-C++ Memory Problems

[sfurlani]

Hello,

I'm having memory woes.

I've got a C++ Library (Equalizer from Eyescale) and they use the Traversal Visitor Pattern to allow you to add new functionality to their classes.

I've finally figured out how it works, and I've got a Visitor that just returns the properties from one of the objects. (since I don't know how they're allocated).

so.

My little code does this:

VisitorResult AGLContextVisitor::visit( Channel* channel ) 
{ 
  // Search through Nodes, Pipes until we get to the right window. 
  // Add some code to make sure we find the right one? 
 
  // Not executing the following code as C++ in gdb? 
  eq::Window* w = channel->getWindow(); 
  OSWindow* osw = w->getOSWindow(); 
  AGLWindow* aw = (AGLWindow *)osw; 
  AGLContext agl_ctx = aw->getAGLContext(); 
  this->setContext(agl_ctx); 
 
  return TRAVERSE_PRUNE; 
}

So here's the problem.
eq::Window* w = channel->getWindow();
(gdb) print w
0x0

BUT If I do this:
(gdb) set objc-non-blocking-mode off
(gdb) print w=channel->getWindow()
0x300effb9

It returns an honest memory location, and sets w as verified in the Debugger window of XCode.

It does the same thing for osw.

I don't get it. Why would something work in (gdb) but not in the code?

The file is completely a cpp file, but it seems to be running in objc++, since I need to turn blocking off.

Help!? I feel like I'm missing some memory-management basic thing here, either with C++ or Obj-C. The code works fine when compiled in a c++ only application.

How can I set objc-non-blocking-mode off in the compiler?

Thanks,

Stephen Furlani

 

[Sander]

What happens if you NSLog() the values and run the program normally..? I assume you got a crash at this point and that's the reason you're in the debugger in the first place, but just in case you were using the debugger to step through the code to understand it: I've noticed that variables were shown having the wrong values when doing Obj-C++ debugging, while the "real" run had no problems. This had me waste considerable time chasing bugs in the wrong place...

 

[sfurlani]

When I build the release version and run it without breakpoints...

Program received signal: “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all

I get that lovely error code. Mainly because w is 0x0 (after channel->getWindow() returns 0x0), so when I try to do w->getOSWindow() I get some bad memory.

Can I "set objc-non-blocking-mode off" as default for the app?

-S!

 

[Sander]

I could only find this when Googling for this. I think this objc-non-blocking-mode is a gbd feature, not a compiler thing.

Could it be some timing issue, where when you run it "for real" some code isn't initialized yet, and in the debugger it is? Is 0 a valid return value for Channel::getWindow()? Is Channel a C++ object too or is it an Objective-C object?

 

[sfurlani]

No, Channel::GetWindow() is supposed to return a valid memory location for the window I can see. after discussing it with the developer of Channel::GetWindow() I've become aware that what I'm trying to do is not thread-safe and is just not going to work.

Which is a shame because now I have to code the solution from the ground up and sift through 10,000s of lines of code to figure out how the original program renders.

Btw, Sander, I loved the article on C# (I programmed with rusty nails for so long...) and the iPhone article is really, really informative and I'll take it to heart.

thanks for the help. Sorry I haven't replied sooner - working on a grant.

-S!

 

[Sander]

No, Channel::GetWindow() is supposed to return a valid memory location for the window I can see. after discussing it with the developer of Channel::GetWindow() I've become aware that what I'm trying to do is not thread-safe and is just not going to work.

Can't you put a big lock around the legacy code to force single-thread access? If it's not performance-critical, maybe that'll do.

Glad you liked the articles.