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

2013-02-25 Thread 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

2013-02-24 Thread 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 mc...@redhat.com 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

2013-02-24 Thread 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 mc...@redhat.com 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

2013-02-22 Thread 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

2013-02-22 Thread 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 mc...@redhat.com 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

2013-02-21 Thread 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 RD 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

2013-02-21 Thread Zan Lynx
On Thu, 2013-02-21 at 10:26 +0100, Milan Crha wrote:
  After doing a lot of RD 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

2013-02-21 Thread 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 zl...@acm.org wrote:

 On Thu, 2013-02-21 at 10:26 +0100, Milan Crha wrote:
   After doing a lot of RD 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 

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

2013-02-20 Thread 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 RD 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)?

http://www.cs.cmu.edu/~gilpin/tutorial/
http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf

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