Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.

Ok, I'll try to make it more formally correct:

Steps to reproduce:

Set up an evo account, add one contact with the birthday field filled out and add it to the category birthday. Check if the addressbook is set up to be used for Birthday and Anniversary Calendar. Enable Birthday and Anniversary calender in calendar overview. Browse to the month the birtday should occour. 

Expected result: 

Birthday event should show up on the given date (in Evo as well as in gnome-shell-calendar).

Unfortunately it does not show up, neither on my normal account nor on clean test accounts.

Versions I can reproduce this bug: 3.3.90, 3.3.91.

I know it worked for git builds I did in January, for February I am not really sure since I did not have set up an birthday event for that month and so I did not check if it works. Last known released version that worked for sure was 3.3.4.

If you tell me how to debug the contacts calender backend, I'll do so. For now that is all what I can say about this.

Bug is still present in 3.3.92. If you need more information, please tell me how to obtain it. There are no obvious crashes, no errors are shown neither on command line nor in the logs.

Seems like I've finally found the commit causing the breakage:

all builds of eds >= commit 604f474ac69f311dd7c82abe860838d3c2f6e25d (3.3.3.x cycle) are showing this behavior. When reverting calendar/backends/contacts/e-cal-backend-contacts.c to the state before this commit, evolution is showing my birthday events (from local addressbook) again (gnome-shell-calendar is not, no idea why).

The commit was meant as a fix for bug #592906.

Hopefully that is enough information to get this fixed soon.

As there is additional information now, I'm going to mark the bug as unconfirmed again.

Maybe I'm wrong, but the longer I try to understand the changes made in commit 604f474ac69f311dd7c82abe860838d3c2f6e25d, the more I wonder if br->book_view is ever holding a value...

I can confirm this bug in Evolution 3.4.1 running on ArchLinux. There is a forum discussion about this at https://bbs.archlinux.org/viewtopic.php?id=140305
I cross checked it with Fedora 16 Live running Evolution 3.2 and birthdays are shown fine in that version.

*** Bug 673638 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> The commit was meant as a fix for bug #592906.
> 
> Hopefully that is enough information to get this fixed soon.

Thanks for a bug report. Pointing out in bug #592906 that the commit has regression would make this being worked on sooner. I wasn't aware of it since borschty told me.

The problem here is that book_client_opened_cb gets called before add_source
gets called. So there is nothing in priv->addressbooks at the time which
results in br being NULL and thus causing a return before any real work gets
done.

Created attachment 214082 [details] [review]
proposed eds patch

for evolution-data-server;

This should make it. It ensures the priv->addressbooks is filled before the callback for "opened" is called, and it also guards 'addressbooks' and 'credentials' with a mutex, because these can be accessed from multiple threads. It seems to work for me.

I'm sorry for a breakage, I didn't notice it when testing the aforementioned change.

Sebastian, could you give this a try, please?

Works for me as well.

Thanks for a quick test. I made it into sources:

Created commit 3fe1b49 in eds master (3.5.2+)
Created commit 02898f3 in eds gnome-3-4 (3.4.3+)