You don't seem to have the required debug info rpms installed. Please install evolution-data-server, glib2, Orbit2 and libbonobo debug info rpms and try to get better traces. 
More details can be found here:
http://live.gnome.org/GettingTraces

See http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running for details
about how to use gdb. 

Created attachment 130892 [details]
New backtrace with debug info also from libliglib2

Unfortunately I did not find debug versions of ORBit2 or libbbonobo, only libglib2. Hop it still can be uesful.

Terminal output for the second crash:

evolution &
Eplugin starting up ...
evolution-shell-Message: Killing old version of evolution-data-server...
** (evolution:2503): DEBUG: mailto URL command: evolution %s
** (evolution:2503): DEBUG: mailto URL program: evolution
e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results)
e-data-server-ui-Message: Key file does not have group 'Passwords-Mail'

(evolution:2503): e-data-server-ui-CRITICAL **: e_source_combo_box_set_active_uid: assertion `gtk_tree_row_reference_valid (reference)' failed

(evolution:2503): e-data-server-ui-CRITICAL **: e_source_combo_box_set_active_uid: assertion `gtk_tree_row_reference_valid (reference)' failed

(evolution:2503): e-data-server-ui-CRITICAL **: e_source_combo_box_set_active_uid: assertion `gtk_tree_row_reference_valid (reference)' failed

(evolution:2503): Bonobo-CRITICAL **: bonobo_ui_component_set_prop: assertion `BONOBO_IS_UI_COMPONENT (component)' failed

(evolution:2503): Bonobo-CRITICAL **: bonobo_ui_component_set_prop: assertion `BONOBO_IS_UI_COMPONENT (component)' failed
new dimensions = (48,48)
initial setting of an image.  no scaling
scale = 1

(evolution:2503): e-utils-WARNING **: calling e_icon_factory_get_icon_filename with unknown icon_size value (48)
new dimensions = (48,48)
we need to scale up
scale = 1

(evolution:2503): Gdk-WARNING **: GdkWindow is too large to allow the use of shape masks or shape regions.

The stack trace looks more complete now with the GLib symbols.  Thanks for that.  No need to worry about the Bonobo or ORBit2 symbols.

However your method of capturing stack traces isn't quite right.  You need to wait for the evolution-data-server process to crash before printing the stack trace.  That was we can see where in the program the crash occurred.  Pressing Ctrl+C to get the stack trace just stops the program at a random place, which isn't useful for crash analysis.

Can you please try again?

OK, the stack trace and information give above shows the problems that the address book is no longer available, still the data-server has not crashed! I'll try to make it crash too.

Created attachment 130907 [details]
Backtrace for a real crash

Now the evolution-data server has crashed. How to crash it is written down in the attachment.

(In reply to comment #6)Can there be a race condition causing the data-sever to crash? The computer has four kernels and is clocked at 2.4 GHz. Linux kernel is 2.6.24-1-amd64.
cat /proc/cpuinfo:

processor	: 0-3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
stepping	: 11
cpu MHz		: 1596.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips	: 4800.02
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

> Created an attachment (id=130907) [edit]
> Backtrace for a real crash
> 
> Now the evolution-data server has crashed. How to crash it is written down in
> the attachment.
> 

NEW: evolution-data-server crashes also for 2.26.x!!! Same problems a before, adding a new contact by right-clicking on a received mail and trying to view that contact in the Contact menu makes the data server to crash again. Alternately a new contact is added (you think), but by going to the Contacts the new contact is not there!!

Created attachment 141150 [details]
Console output of evolution.

Created attachment 141151 [details]
gdb output for evo-data-server

This bug report is now half a year old. I have reported to both Debian and here. Nothing happens! What to do to make things progress?? 

Steps to reproduce:
1. Go to mail mode
2. Add a new contact, right-clicking on a a new email contact
3. Access the contacts (evolution-data-server has crashed, not evolution)

Alternate scenario:
evo is silently accepting a new contact, but no new contact has been added! e-d-s (or evo) does not crash in this case!

I tried your steps in recently released 2.28.0 and it works fine for me, contact is added and I can see it. Moving from mailer to contacts doesn't crash neither evo nor eds. It either got fixed meanwhile or I do something wrong.

Could you try with 2.28.0+, please?

I have now tried 2.28.0+ from Debian unstable (even if I have testing
installed). The contacts STILL CRASHES the evo-data-server! This is
really becoming a big problem: Neither of the 2.22.3.1, 2.26.3 or 2.28.0
releases works! Are you running evo on a 4CPU box? I'm thinking there
might be a race condition in the threads!

ii  evolution                            2.28.0-2+b1 groupware suite
with mail client and organizer
ii  evolution-common                     2.28.0-2 architecture
independent files for Evolution
ii  evolution-data-server                2.28.0-2+b2 evolution database
backend server
ii  evolution-data-server-common         2.28.0-2 architecture
independent files for Evolution Data Server
ii  evolution-data-server-dbg            2.28.0-2+b2 evolution database
backend server with debugging symbols
ii  evolution-dbg                        2.28.0-2+b1 debugging symbols
for Evolution
ii  evolution-exchange                   2.28.0-1 Exchange plugin for
the Evolution groupware suite
ii  evolution-plugins                    2.28.0-2+b1 standard plugins
for Evolution
ii  evolution-webcal                     2.26.0-1 webcal: URL handler
for GNOME and Evolution
ii  libebackend1.2-0                     2.28.0-2+b2 Utility library for
evolution data servers
ii  libebook1.2-9                        2.28.0-2+b2 Client library for
evolution address books
ii  libecal1.2-7                         2.28.0-2+b2 Client library for
evolution calendars
ii  libedata-book1.2-2                   2.28.0-2+b2 Backend library for
evolution address books
ii  libedata-cal1.2-6                    2.28.0-2+b2 Backend library for
evolution calendars
ii  libedataserver1.2-11                 2.28.0-2+b2 Utility library for
evolution data servers
ii  libedataserver1.2-9                  2.22.3-1.1+lenny2 Utility
library for evolution data servers
ii  libedataserverui1.2-8                2.28.0-2+b2 GUI utility library
for evolution data servers
ii  openoffice.org-evolution             1:3.1.1-2 full-featured office
productivity suite -- Evolution addressbook
ii  python-evolution                     2.26.0-1 Python bindings for
the evolution libraries

Thanks for a quick reply. I thought it's something in a code, but looking more carefully on your gdb output from eds in comment #10, I see these issues:
> libebookbackend-WARNING **: libdb error: /home/srs/.evolution/addressbook/
> local/system/addressbook.db page 9 is on free list with type 13
>
> libebookbackend-WARNING **: libdb error: PANIC: Invalid argument
>
> libebookbackend-WARNING **: e-book-backend-file.c:227: db->put failed with
> DB_RUNRECOVERY: Fatal error, run database recovery
>
> ...
>
> libebookbackend-WARNING **: libdb error: PANIC: fatal region error detected;
> run recovery
>
> libebookbackend-WARNING **: e_book_backend_file_search: error getting the
> cursor for /home/srs/.evolution/addressbook/local/system/addressbook.db

Thus it claims your /home/srs/.evolution/addressbook/local/system/addressbook.db
being broken and requires recovery, which failed in the runtime.

Please try to do a copy of yours addressbook.db file and run something like db_recover or some other maintenance tool of libdb on the file, it'll fix it hopefully. If something goes wrong return back the copied file and try other tool.

I copied the addressbook.db file to another directory and tried db4.8-verify:
db4.8_verify: Page 18: non-empty page in unused hash bucket 11
db4.8_verify: Page 0: page 9 encountered a second time on free list
db4.8_verify: addressbook.db: DB_VERIFY_BAD: Database verification failed

Then I tried the db4.8-recover on this file. The outcome is that the addressbook.db remains intact and a large log file is created.
ls -l ./test
-rw-r--r-- 1 srs srs    98304 2009-09-29 16:36 addressbook.db
-rw-r----- 1 srs srs 10485760 2009-09-29 16:44 log.0000000001

Why is not the database file changed? How to continue from here?

are you sure the file is the same? it can be with respect of time and size, but it shouldn't with respect of content. Anyway, I have not much idea here, the google search fro db_recover seems to offer that the command recovers what it can when used only with the db file name.

The copied addressbook.db is the same as the file under .evolution/addressbok/... from what I can see, still corrupt. It is not changed by db4.8_recover. That command does not take any file name as argument! I tried it in the same directory as addressbook.db, i.e. test/ with the log file as result.

However I managed to create a new (not corrupt database file) with
cd test/
db4.8_dump ./addresbook.db | db4.8_load ./test.db
(Save away old .evolution/.../addressbook.db)
cp -p test.db .evolution/addressbook/local/system/addressbook.db

The resulting file has a different size than the original (I checked also with a not corrupt addressbook.db on another computer)

Now evo seems to work :) without crashing the e-d-s at least so far. I need some more testing to make sure the problems really are gone.

That sounds good. I'm sorry of not being of a help, as I do not use the db_recover at all. Anyway, good you managed to fix it. Maybe some data got lost from the corrupted record.

I'm closing this. Thanks.