C++ Bug hunt - shared_ptr misuse

No comments

Monday, September 09, 2013

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.
from Bjarne Stroustrup's FAQ: Did you really say that?
I want to share with you a strange bug I’ve been struggling with last week.
I had an application that crashed whenever a user logged out and then logged back. I couldn’t understand why during the 2nd login attempt all hell broke loose – I got the finger equivalent of the C++ world - “corrupted memory” exception.
I had the best minds try and use their debugging powers to try and catch the cause of that memory issue thing but to no avail. That is until a simple breakpoint solved the mystery.

The cast

Due to NDA and time constraint let me simplify the problem- I had two classes:
  1. a Factory of sorts
  2. Some Object created by that factory
The factory definition looks something like this:
#pragma once

#include <memory>
#include "MyObject.h"

class MyFactory
{
public:
    std::shared_ptr<myobject> GetObject();

    //...
};

The “Object” class had many important methods that did interesting stuff to the benefit of the users – however for this example we only care about its constructor:

#pragma once
#include <memory>

class MyFactory;

class MyObject
{
public:
    MyObject(std::shared_ptr<myfactory> factory);
    ~MyObject(void);

    //...
};

And that’s it – see the problem yet?

Obviously this cyclic reference (factory is passed to object that was created by factory)  is asking for trouble  but that’s not the problem (yet).

The problem

Let me show you how GetObject was implemented:

using namespace std;

std::shared_ptr<myobject> MyFactory::GetObject()
{
    return make_shared<MyObject>(shared_ptr<myfactory>(this));
}

Do you see the problem? If not - take a minute to think about it…

In case you’re not familiar with shared_ptr – it’s essentially a smart pointerwhich was introduced in C++ 11 (and before that in Boost):
Manages the storage of a pointer, providing a limited garbage-collection facility, possibly sharing that management with other objects.
from cplusplus.com

The problem is that a misguided soul (read: yours truly) has used it the wrong way.

shared_ptr works by reference counting – each new assignment increase that count and every time the object goes out of scope the count is decreased.
  • When I’ve created a new shared_ptr instance from this it was created with count of one.
  • All was good and well until after MyObject constructor ended in which point the count was decreased.
  • Since  no other shared_ptr objects were holding the pointer – MyFactory desructor was called
  • An exception – not right away (we’re talking C++ here) but most of the time the next time you try and do something with MyFactory
The fix was simple – I’ve changed the c’tor to receive MyFactory as a plain-old-honest-to-god reference.

The lesson learnt

shared_ptr is a great thing – it’s one the useful new gadgets that made it into the new C++ 11.

I’m using it all the time – it help me write simple, elegant C++ code, But like everything else in the C++ world – make sure you understand what you’re doing.


Happy coding…

Doing the RIGHT standup meeting

No comments

Thursday, September 05, 2013

Doing a standup meeting (a.k.a daily SCRUM) meeting should be simple – so how come so many teams are doing it wrong?

I believe that a daily meeting is a good practice – and should be practiced by all development teams – with or without using Scrum or any other agile methodology whatsoever.

And so I bring to your consideration my thoughts on how a standup meeting should be conducted:

 

So what is a standup meeting?

A stand-up meeting (or simply "stand-up") is a daily team-meeting held to provide a status update to the team members.

From Wikipedia

It’s as simple as that – each day the team meets and update each other on the current status of their tasks.

So how come some teams do it wrong?

The fact is that conducting a successful daily meeting requires discipline and following a few simple rules. Because its quite easy to mess things up and instead of a productive and informative meeting – waste everybody time.

The right time

Usually a standup meeting shall be conducted at the morning - the reasoning behind this practice is that is helps “jump start” the day – after the meeting the whole team is synced and focused - problems have been addressed and everybody knows what he’s going to do today.

I have been part of a team that did its standup meeting at the afternoon – because that was the time that most of the team was at the office. It was a good idea and it worked well – because a meeting at the morning with less than half of the team is not as effective as a meeting later with the whole (or most) of the team.

It doesn’t matter what hour you choose - make sure to have the meeting at the same time each day – it creates a routine and helps the team fall into the right rhythm.

The right amount

A daily meeting should be conducted every day – no exceptions!

It’s so easy to skip a meeting (or five) when deadlines approaches. The problem is that skipping these meetings make the one you don’t skip less effective.

If you have a meeting once in a blue moon it would be a long and tedious thing (“let me tell you what I did the last two weeks”- unfortunately a real story).

If your team get used to the fact that the meeting tends to be re-scheduled or canceled – they would not show on time (or at all) to the meetings you do decide to have – which brings us to the next point:

The right participants

All your team should be part of the daily meeting. I say should because we live in an imperfect world – people get sick, work out of office, have showstopper bugs to fix and so on. The important thing is to have the standup meeting at the designated time even if some of the participants haven’t shown up yet.

In one of my previous jobs we had a problem – it took forever to get everybody in the same room – Joe would need to fix one last thing and Diana had to get out of the meeting (in 5 min) and so on, the meetings used to start 10-15 min. after the designated time which I felt was unfair for the guys who showed up on time. After a awhile no one would show at the meeting and I had to go and call each member of the team personally a few times to everybody to show up. My solution was simple – I’ve started the meeting on time - without them, the fact that some participants were late didn’t effect the time of the rest of the team – and the late party learns to come on time.

There is no “minimum number” of participant - I did standup meetings with as little as two co-workers (during summer vacation) and it proved useful.

From time to time (read: always) invite testers (if not part of your team) or product/marketing guys (and gals) or your boss’s boss – let them know what you do and what you plan to deliver – just make sure they understand about the “chickens & pigs” beforehand.

The right duration

A stand meeting should be as short as possible – I recommend about 5-15 minutes depending on the number of participants.

This is and important factor effecting the success of the meeting. In case you didn’t know the reason that everybody is standing up is because we want to make this meeting short.

This is one of the more problematic guidelines to follow – I’m not sure why – perhaps there’s a performer in each of us.

In one team we’ve used an hourglass to make sure that the meeting didn’t get out of hand.

2013-09-05 20.23.24

We never actually stopped anyone mid-sentence, but it helped that the speaker knew how much time he has been talking.

Try keeping track of the meeting’s duration and at its end announce how much time it took – I found it helps if your meetings tends to get out of hand and last forever.

The right conduct

The team take turns - each member of the team should answer these three questions:

  1. What I did yesterday
  2. What I’m going to do today
  3. What is preventing me from achieving my goals – roadblocks, impediments etc.

And that’s it no more – no less.

It always amazes me how easily a standup meeting can derail by not following this simple format.

I had a a manager in one of previous jobs use the standup meeting to discuss present and future work with each participant personally – this is a great way to make sure no one pay attention in the meeting – at least not until it’s his turn for this public one-on-one with his manager.

Make sure that only the person updating about his status may speaks, some teams use a “totem” that grants its holder the right of speech (lord of the flies style) some do without it – the important par tis that the meeting is about status update for the whole team not just the manager.

From time to time one of the other participants has something to say – perhaps he want to offer help, ask for short clarification, discuss a possible solution or just argue with the speaker.

This is fine as long as it’s short and to the point (e.c. “I know how to create this script – I’ll show you after the meeting), if it becomes a conversation between tow people - tell them to have another meeting after the daily standup. When such interference happens I would usually let them talk for a minute or two before stopping the conversation and tell them to discuss it after the meeting.

Conclusion

At a typical project meeting most attendees do not contribute, but attend just to hear the outcome. A large amount of developer time is wasted to gain a trivial amount of communication. Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.
Communication among the entire team is the purpose of the stand up meeting.

From extremeprogramming.org

A daily meeting is a good way to keep the team focused and informed and is beneficial with or without practicing SCRUM (or any agile method).

Performing a successful standup meeting is simple – just make sure that you don’t loose sight of the real purpose of the meeting – a semi real-time status update.

Related Posts Plugin for WordPress, Blogger...