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
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
