On Wed, 2013-02-20 at 22:31 +0530, Samarjit Adhikari wrote: > I was trying to look into the root cause of the > BUG(https://bugzilla.redhat.com/show_bug.cgi?id=903166) as i believe > my environment is the best one to reproduce the issue.
Hi, thanks for your help on this. > After doing a lot of R&D my intuition says that it is a memory > corruption issue. valgrind usually helps in such cases. You can run evolution like this: $ valgrind --num-callers=50 evolution &>log.txt and valgrind will check evolution for some memory issues. > "nspi_ResolveNamesW" is returning a NT_STATUS not actually the > MAPISTATUS. Strange, I do not see it there. I've there: status = dcerpc_NspiResolveNamesW_r(nspi_ctx->rpc_connection->binding_handle, mem_ctx, &r); retval = r.out.result; OPENCHANGE_RETVAL_IF(!NT_STATUS_IS_OK(status), retval, NULL); OPENCHANGE_RETVAL_IF(retval, retval, NULL); return MAPI_E_SUCCESS; } thus what is returned is a 'retval' variable, not 'status'. > While doing investigation i reached to the mapi function, named > "e_mapi_connection_init". That's called internally by the GObject system. It's used as an object (structure) initializer. You can check with gdb, as Adam suggested. $ gdb evolution --ex "b e_mapi_connection_init" --ex r Bye, Milan _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers