Crash while running offlineimap

crash report at: http://saturn.flamingspork.com/~stewart/_usr_bin_evolution-2.8.1000.crash

sorry, make that .bz2 as it's a bit smaller then

The permission for that file doesn't seem to be correct, you can also attach the crash file to the bug if you want

gah, sorry about that. It's a 53MB dump, so a bit hard to attach. should be fixed now.

Could you run apport-retrace on the crash file with libglib2.0-0-dbg evolution-data-server-dbg evolution-dbg installed and then attach the stripped version of the crash to the bug page?

The following doesn't really give me much:

$ apport-retrace -s _usr_bin_evolution-2.8.1000.crash
--- stack trace ---
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
--- thread stack trace ---
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

Could this be indicative of the core dump not being complete? the info from the ProcStatus surely indicates so:
VmPeak: 695472 kB
VmSize: 659996 kB
VmLck: 0 kB
VmHWM: 328724 kB
VmRSS: 328724 kB
VmData: 377724 kB

It's only a 200MB core. It also doesn't load into GDB - it gives this error:
"/tmp/foo/CoreDump" is not a core dump: File format not recognized

Evolution routinely for me uses over 200MB of memory (current resident portion is 288m, virt 512m) and that's only using it lightly for a few hours. Usually about 400-500MB resident.

is there some limit somewhere preventing these types of dumps being created properly?

If you don't think it's possible to rescue proper debug information from this crash dump, better close the bug until next time comes along with a proper one.

The coredump are limited to 200M by default probably, can you get that crash reliably? In which case maybe try running evolution with gdb and get the backtrace from gdb directly

As described in the previous comments, your report lacks the information we need to investigate the problem further. We'll close this report for now - please reopen it if you can give us the missing information.