Question

I’m getting a seg fault that I do not understand. I’m using the Wt library and doing some fancy things with signals (which I only mention because it has enabled me to attempt to debug this).

I’m getting a pointer to one of my widgets from a vector and trying to call a method on the object it points to. Gdb shows that the pointer resolves, and if I examine the object it points to, it is exactly the one I need to modify. In this instance, the widget is broadcasting to itself, so it is registered as both the broadcaster and the listener; therefore, I was also able to verify that the ‘broadcaster’ pointer and the ‘listener’ pointer are accessing the same object. They do!

However, even though I can see that the object exists, and is initialized, and is in fact the correct object, when I try to call a method on the object, I get an immediate seg fault. I’ve tried a few different methods (including a few boolean returns that don’t modify the object). I’ve tried calling them through the broadcaster pointer and the listener pointer, again, just to try to debug.

The debugger doesn’t even enter the object; the segfault occurs immediately on attempting to call a method.

Code!

/* listeners is a vector of pointers to widgets to whom the broadcasting widget
 * is trying to signal.
 */
unsigned int num_listeners = listeners.size();
for (int w = 0; w < num_listeners; w++)
{
    // Moldable is an abstraction of another widget type
    Moldable* widget = listeners.at(w);

    /* Because in this case, the broadcaster and the listener are one in the same, 
     * these two point to the same location in memory; this part works. I know, therefore,
     * that the object has been instantiated, exists, and is happy, or we wouldn't
     * have gotten to this point to begin with. I can also examine the fields with gdb
     * and can verify that all of this is correct.
     */
    Moldable* broadcaster_debug = broadcast->getBroadcaster();

    /* setStyle is a method I created, and have tested in other instances and it
     * works just fine; I've also used native Wt methods for testing this problem and
     * they are also met with segfaults. 
     */
    widget->setStyle(new_style); // segfault goes here!
}

I have read since researching that storing pointers in vectors is not the greatest idea and I should look into boost::shared_ptr. That may be so, and I will look into it, but it doesn’t explain why calling a method on an object known to exist causes a segfault. I’d like to understand why this is happening.

Thanks for any assistance.

Edit:
I have created a gist with the vector operations detailed because it was more code than would comfortably fit in the post.
https://gist.github.com/3111137

I have not shown the code where the widgets are created because it’s a recursive algorithm and in order to do that, I would have to show the entire class decision tree for creating widgets. Suffice to say that the widgets are being created; I can see them on the page when viewing the application in a browser. Everything works fine until I start playing with my fancy signals.

Moar Edit:
When I take a look at the disassembly in instruction stepping mode, I can see that just before the segfault occurs, the following operation takes place, the first argument of which is listed as ‘void’. Admittedly, I know nothing about Assembly much to my chagrin, but this seems to be important. Can anyone explain what this instruction means and whether it might be the cause of my woes?

 add $0x378,%rax //$0x378 is listed as 'void'

Another Edit:
At someone’s suggestion, I created a non-virtual method that I am able to successfully call just before the seg fault, meaning the object is in fact there. If I take the same method and make it virtual, the seg fault occurs. So, why do only virtual methods create a seg fault?

I’ve discovered now that if in the calling class, I make sure to specify Moldable::debug_test (and Moldable::setStyle), the seg fault does not take place. However, this seems to have a similar effect as const bubbling — every virtual method seems to want this specifier. I’ve never witnessed this behaviour before. While i’m willing to correct my code if that’s REALLY how it’s supposed to be, I’m not sure if the root problem is something else.

Getting there!

Answer 1

Well, I figured out the problem, though I’m sad to say it was a totally newbish mistake that due to the nature of the project was super difficult to find. I’ll put the answer here, and I’ve also voted to close the question as too localized. Please feel free to do the same.

The BroadcastMessage class had a __broadcaster field (Moldable* __broadcaster;). When passing in the pointer to the broadcaster into the BroadcastMessage constructor, I forgot to assign the inbound pointer to that field, meaning __broadcaster was not a fully realised instance of the Moldable class.

Therefore, some methods were in fact working — those that could be inlined, or my dummy functions that I created for testing (one of which returned a value of 1, for instance), so it was appearing that there was a full object there when in fact there was not. It wasn’t until calling a more specialized method that tried to access some specific, dynamic property of the object that the segfault occurred.

What’s more, most of the broadcast message lifespan was in its constructor, meaning that most of its purpose was fulfilled without issue, because the broadcaster was available in the local scope of the constructor.

However, using Valgrind as suggested, I did uncover some other potential issues. I also pretty much stripped-down and re-built the entire project. I trashed tons of unnecessary code and it runs a lot faster now as a side effect.

Anyway, thanks for all the assistance. Sorry the solution wasn’t more of a discovery.