Re: [Evolution-hackers] Required Evolution-code-help

[Milan Crha]

On Mon, 2013-02-25 at 10:31 +0530, samarjit Adhikari wrote:

> As suggested, I have open a mapi connection using camel services but
> got a crash in g_rec_mutex_lock function.
> 
> Crash debugging attached. it seems the connection has not being
> initialized yet. Any help??

Hi,
CamelMapiStore and CamelMapiTransport are two different objects, you
cannot use CamelMapiStore functions on an instance of
CamelMapiTransport.

With your other changes, you should be touching only
camel-mapi-transport.c, no other file. If you provide *similar* function
implementations for CamelServiceClass, those I wrote about in the
previous email, for CamelMapiTransport, then you can then check of
proper connection status of the CamelMapiTransport, not CamelMapiStore.

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

Re: [Evolution-hackers] Required Evolution-code-help

[samarjit Adhikari]

I am taking about the change #1297-1301

With regards,
Samarjit


On Mon, Feb 25, 2013 at 10:31 AM, samarjit Adhikari <
samarjit.adhik...@gmail.com> wrote:

> hi All,
>
> As suggested, I have open a mapi connection using camel services but got a
> crash in g_rec_mutex_lock function.
> Crash debugging attached. it seems the connection has not being
> initialized yet. Any help??
>
> My latest code changes are present in following branch. i have attached
> modified files as well.
>
> http://bazaar.launchpad.net/~samarjit-adhikari/evolution/evolution-mapi-3.6.2/changes
>
> With regards,
> Samarjit
>
>
> On Fri, Feb 22, 2013 at 5:46 PM, samarjit Adhikari <
> samarjit.adhik...@gmail.com> wrote:
>
>> Hi Milan
>>
>> >Correct way would be to provide
>> >"connect_sync/authenticate_
>> >sync/disconnect_sync" for the
>> >CamelMapiTransport structure, where you get everything, the password and
>> >such, without dealing with evolution internals.
>>
>> I can not follow the sequence of camel service
>> "connect_sync/authenticate_sync/disconnect_sync" as inside that function
>> "mapi_authenticate_sync"
>> following code is present.
>>
>> store->priv->connection = e_mapi_connection_new (
>> e_mail_session_get_registry (E_MAIL_SESSION
>> (camel_service_get_session (service))),
>> profile, password_str, cancellable, &mapi_error);
>>
>> Thus the pointer store->priv->connection will be overwritten during
>> send_to_sync.
>>
>> Only way i found is using "e_mapi_connection_new". Do let me know your
>> view.
>>
>> With regards,
>> Samarjit
>>
>>
>> On Fri, Feb 22, 2013 at 3:39 PM, Milan Crha  wrote:
>>
>>> On Fri, 2013-02-22 at 12:50 +0530, samarjit Adhikari wrote:
>>> > I build it and tried to use it. IT was UNSUCCESSFUL. it was
>>> > NT_STATUS_WRITE_FAULT as follows. I lost in sea.  What to do next i am
>>> > not sure. Any idea??
>>>
>>> Hi,
>>> one of the reasons to reuse already running connections is slowness with
>>> which libmapi/samba connects to the server, it takes around 10 seconds
>>> here, sometimes more, sometimes less.
>>>
>>> The NT_STATUS_WRITE_FAULT is a reason of
>>> > dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
>>> which can happen when a wrong password is used, if I recall correctly,
>>> and you passed no password, which causes the error most likely (unless
>>> you use kerberos login).
>>>
>>> The way you get to registry is also not 100% correct, but I understand
>>> there are not many options for this. I just mean that I'd not agree for
>>> such patch in upstream. Correct way would be to provide
>>> "connect_sync/authenticate_sync/disconnect_sync" for the
>>> CamelMapiTransport structure, where you get everything, the password and
>>> such, without dealing with evolution internals.
>>> 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
>>>
>>
>>
>
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Required Evolution-code-help

[samarjit Adhikari]

hi All,

As suggested, I have open a mapi connection using camel services but got a
crash in g_rec_mutex_lock function.
Crash debugging attached. it seems the connection has not being initialized
yet. Any help??

My latest code changes are present in following branch. i have attached
modified files as well.
http://bazaar.launchpad.net/~samarjit-adhikari/evolution/evolution-mapi-3.6.2/changes

With regards,
Samarjit


On Fri, Feb 22, 2013 at 5:46 PM, samarjit Adhikari <
samarjit.adhik...@gmail.com> wrote:

> Hi Milan
>
> >Correct way would be to provide
> >"connect_sync/authenticate_
> >sync/disconnect_sync" for the
> >CamelMapiTransport structure, where you get everything, the password and
> >such, without dealing with evolution internals.
>
> I can not follow the sequence of camel service
> "connect_sync/authenticate_sync/disconnect_sync" as inside that function
> "mapi_authenticate_sync"
> following code is present.
>
> store->priv->connection = e_mapi_connection_new (
> e_mail_session_get_registry (E_MAIL_SESSION
> (camel_service_get_session (service))),
> profile, password_str, cancellable, &mapi_error);
>
> Thus the pointer store->priv->connection will be overwritten during
> send_to_sync.
>
> Only way i found is using "e_mapi_connection_new". Do let me know your
> view.
>
> With regards,
> Samarjit
>
>
> On Fri, Feb 22, 2013 at 3:39 PM, Milan Crha  wrote:
>
>> On Fri, 2013-02-22 at 12:50 +0530, samarjit Adhikari wrote:
>> > I build it and tried to use it. IT was UNSUCCESSFUL. it was
>> > NT_STATUS_WRITE_FAULT as follows. I lost in sea.  What to do next i am
>> > not sure. Any idea??
>>
>> Hi,
>> one of the reasons to reuse already running connections is slowness with
>> which libmapi/samba connects to the server, it takes around 10 seconds
>> here, sometimes more, sometimes less.
>>
>> The NT_STATUS_WRITE_FAULT is a reason of
>> > dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
>> which can happen when a wrong password is used, if I recall correctly,
>> and you passed no password, which causes the error most likely (unless
>> you use kerberos login).
>>
>> The way you get to registry is also not 100% correct, but I understand
>> there are not many options for this. I just mean that I'd not agree for
>> such patch in upstream. Correct way would be to provide
>> "connect_sync/authenticate_sync/disconnect_sync" for the
>> CamelMapiTransport structure, where you get everything, the password and
>> such, without dealing with evolution internals.
>> 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
>>
>
>


sendto_sync_crash
Description: Binary data
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Required Evolution-code-help

[samarjit Adhikari]

Hi Milan

>Correct way would be to provide
>"connect_sync/authenticate_
>sync/disconnect_sync" for the
>CamelMapiTransport structure, where you get everything, the password and
>such, without dealing with evolution internals.

I can not follow the sequence of camel service
"connect_sync/authenticate_sync/disconnect_sync" as inside that function
"mapi_authenticate_sync"
following code is present.

store->priv->connection = e_mapi_connection_new (
e_mail_session_get_registry (E_MAIL_SESSION
(camel_service_get_session (service))),
profile, password_str, cancellable, &mapi_error);

Thus the pointer store->priv->connection will be overwritten during
send_to_sync.

Only way i found is using "e_mapi_connection_new". Do let me know your view.

With regards,
Samarjit


On Fri, Feb 22, 2013 at 3:39 PM, Milan Crha  wrote:

> On Fri, 2013-02-22 at 12:50 +0530, samarjit Adhikari wrote:
> > I build it and tried to use it. IT was UNSUCCESSFUL. it was
> > NT_STATUS_WRITE_FAULT as follows. I lost in sea.  What to do next i am
> > not sure. Any idea??
>
> Hi,
> one of the reasons to reuse already running connections is slowness with
> which libmapi/samba connects to the server, it takes around 10 seconds
> here, sometimes more, sometimes less.
>
> The NT_STATUS_WRITE_FAULT is a reason of
> > dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
> which can happen when a wrong password is used, if I recall correctly,
> and you passed no password, which causes the error most likely (unless
> you use kerberos login).
>
> The way you get to registry is also not 100% correct, but I understand
> there are not many options for this. I just mean that I'd not agree for
> such patch in upstream. Correct way would be to provide
> "connect_sync/authenticate_sync/disconnect_sync" for the
> CamelMapiTransport structure, where you get everything, the password and
> such, without dealing with evolution internals.
> 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
>
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Required Evolution-code-help

[Milan Crha]

On Fri, 2013-02-22 at 12:50 +0530, samarjit Adhikari wrote:
> I build it and tried to use it. IT was UNSUCCESSFUL. it was
> NT_STATUS_WRITE_FAULT as follows. I lost in sea.  What to do next i am
> not sure. Any idea??

Hi,
one of the reasons to reuse already running connections is slowness with
which libmapi/samba connects to the server, it takes around 10 seconds
here, sometimes more, sometimes less.

The NT_STATUS_WRITE_FAULT is a reason of
> dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
which can happen when a wrong password is used, if I recall correctly,
and you passed no password, which causes the error most likely (unless
you use kerberos login).

The way you get to registry is also not 100% correct, but I understand
there are not many options for this. I just mean that I'd not agree for
such patch in upstream. Correct way would be to provide
"connect_sync/authenticate_sync/disconnect_sync" for the
CamelMapiTransport structure, where you get everything, the password and
such, without dealing with evolution internals.
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

Re: [Evolution-hackers] Required Evolution-code-help

[samarjit Adhikari]

Hi All,

I have observe that camel-mapi-store open a connection with Exchange server
and put it in "known_connections" list. This mapi-store connection is used
for periodically checking mails and updating inbox folders. If you get
mail, this connection is responsible to download those mails with periodic
polling. While composing a mail and send, function "mapi_send_to_sync"
tries to search all "known_connections" list and will pick the same
connection to send mail which one was used for downloading mails.

[code]
static gboolean
mapi_send_to_sync (CamelTransport *transport,
   CamelMimeMessage *message,
   CamelAddress *from,
   CamelAddress *recipients,
   GCancellable *cancellable,
   GError **error){

..
conn = e_mapi_connection_find (profile);
..
}

This could lead to MAPI RESOLVE NAME ISSUE. Thus i have decided to create a
new connection while sending mail and then dispose off the connection. i
did the required code modification in "mapi_send_to_sync" function as
follows.

conn = e_mapi_connection_new (e_mail_session_get_registry
  (E_MAIL_SESSION
(camel_service_get_session (service))),
   profile, NULL, cancellable, &mapi_error);

I build it and tried to use it. IT was UNSUCCESSFUL. it was
NT_STATUS_WRITE_FAULT as follows. I lost in sea.  What to do next i am not
sure. Any idea??
-
Starting GENSEC mechanism spnego
Starting GENSEC submechanism ntlmssp
 negotiate: struct NEGOTIATE_MESSAGE
Signature: 'NTLMSSP'
MessageType  : NtLmNegotiate (1)
NegotiateFlags   : 0x60088205 (1611170309)
   1: NTLMSSP_NEGOTIATE_UNICODE
   0: NTLMSSP_NEGOTIATE_OEM
   1: NTLMSSP_REQUEST_TARGET
   0: NTLMSSP_NEGOTIATE_SIGN
   0: NTLMSSP_NEGOTIATE_SEAL
   0: NTLMSSP_NEGOTIATE_DATAGRAM
   0: NTLMSSP_NEGOTIATE_LM_KEY
   0: NTLMSSP_NEGOTIATE_NETWARE
   1: NTLMSSP_NEGOTIATE_NTLM
   0: NTLMSSP_NEGOTIATE_NT_ONLY
   0: NTLMSSP_ANONYMOUS
   0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
   0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED
   0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL
   1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN
   0: NTLMSSP_TARGET_TYPE_DOMAIN
   0: NTLMSSP_TARGET_TYPE_SERVER
   0: NTLMSSP_TARGET_TYPE_SHARE
   1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
   0: NTLMSSP_NEGOTIATE_IDENTIFY
   0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY
   0: NTLMSSP_NEGOTIATE_TARGET_INFO
   0: NTLMSSP_NEGOTIATE_VERSION
   1: NTLMSSP_NEGOTIATE_128
   1: NTLMSSP_NEGOTIATE_KEY_EXCH
   0: NTLMSSP_NEGOTIATE_56
DomainNameLen: 0x0009 (9)
DomainNameMaxLen : 0x0009 (9)
DomainName   : *
DomainName   : 'WORKGROUP'
WorkstationLen   : 0x0009 (9)
WorkstationMaxLen: 0x0009 (9)
Workstation  : *
Workstation  : 'localhost'
../librpc/rpc/dcerpc_util.c:140: auth_pad_length 0
Got challenge flags:
Got NTLMSSP neg_flags=0x62898205
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_NTLM2
  NTLMSSP_NEGOTIATE_TARGET_INFO
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x60008205
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED
Failed to bind to uuid 1544f5e0-613c-11d1-93df-00c04fd7bd09 for
1544f5e0-613c-11d1-93df-00c04fd7bd09@ncacn_ip_tcp:casarray1.hp.com[60052,print]
NT_STATUS_NET_WRITE_FAULT
Failed to connect to remote server: ncacn_ip_tcp:casarray1.hp.com[print,]
NT_STATUS_NET_WRITE_FAULT
--


With regards,
Samarjit


On Fri, Feb 22, 2013 at 4:59 AM, Zan Lynx  wrote:

> On Thu, 2013-02-21 at 10:26 +0100, Milan Crha wrote:
> > > 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.
>
> I would like to offer a hint here. I have done this in the past and I
> recommend using a test user account with only a very few test emails in
> it.
>
> When I at

Re: [Evolution-hackers] Required Evolution-code-help

[Zan Lynx]

On Thu, 2013-02-21 at 10:26 +0100, Milan Crha wrote:
> > 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.

I would like to offer a hint here. I have done this in the past and I
recommend using a test user account with only a very few test emails in
it.

When I attempted to run valgrind evolution on my own email account it
never actually managed to load. I killed it after several minutes.
Valgrind slows everything down.
-- 
Knowledge Is Power
Power Corrupts
Study Hard
Be Evil

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Required Evolution-code-help

[Milan Crha]

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

Re: [Evolution-hackers] Required Evolution-code-help

[Adam Tauno Williams]

On Wed, 2013-02-20 at 22:31 +0530, Samarjit Adhikari wrote:
> Hi,
> Hopefully i am putting my question in right mailing list.

Yep! :)

> 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.After doing a
> lot of R&D my intuition says that it is a memory corruption issue. I
> looked into the openchange code (specially libmapi code1.0.4) and
> found that function 
> "nspi_ResolveNamesW"  is returning a NT_STATUS not actually the
> MAPISTATUS. Thus we were getting some VAGUE pop up. I am investigating
> further.
> While doing investigation i reached to the mapi function, named
> "e_mapi_connection_init". After that i am not able to search who is
> the caller of that function. I did not found and dlopen/close thing as
> well.
> Thus it would be really helpful if you give some pointer regarding the
> caller of that function.

Can you set a breakpoint and generate a backtrace (gdb)?




I've never done it with Evolution / MAPI code.  But generally that is
what I would do to discover
"how-the-*@&^&*&@-did-i-end-up-in-this-function".

-- 
Adam Tauno Williams  GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Required Evolution-code-help

[Samarjit Adhikari]

Hi,

Hopefully i am putting my question in right mailing list.

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.After doing a lot of
R&D my intuition says that it is a memory corruption issue. I looked
into the openchange code (specially libmapi code1.0.4) and found that
function 
"nspi_ResolveNamesW"  is returning a NT_STATUS not actually the
MAPISTATUS. Thus we were getting some VAGUE pop up. I am investigating
further.

While doing investigation i reached to the mapi function, named
"e_mapi_connection_init". After that i am not able to search who is the
caller of that function. I did not found and dlopen/close thing as well.

Thus it would be really helpful if you give some pointer regarding the
caller of that function.

With regards,
Samarjit
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers