Re: Res: Res: [Harbour] tipclientsmtp problem with MT
Fernando, I told you to remove the password :-) From your first message: 20100514-10:05:23 :INETSENDALL( pointer, 25, HELO myn...@gmail.comcrlf ) 25 From today message: 20100515-21:31:32 :INETSENDALL( pointer, 35, EHLO fjsiste...@fjsistemas.com.br crlf ) 35 Since EHLO command is sent only from :OpenSecure there should be some parameters of hb_sendmail that toggle it, different from the gmail.prg sample. About the MT problem... when the client connects to a smtp server it must wait for a 220space message that signals the smtp server is ready (5xx messages signal server is not ready). It does it ST mode... In MT it seems the connect - probably due to the ssl library - doesn't get the server reply and that only after sending the QUIT (after the timeout) it gets the 220... I did some changes in sendmail.prg code about it, since it did not respect RFC... I did not check the ssl part since I have openssl installed... I will try to install today. Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
sorry i was search about ssl, openssl uses thread i think that this may confuse MT in harbour It's possible, if you find anything more in this regard, pls tell us about it. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Fernando Athayde wrote: Hi, Przemek, i was think, may be problem is the multithread support of openssl dll´s i was trying build openssl, but without success If non HVM thread tries to access HVM, i.e. to execute some .prg code then it simply GPF so I do not think it's the source o your problem. but if you test gmail.prg with -MT you´ll see the problem Both MT and ST versions returns .T. so they seem to work but valgrind produces for both of them 285KB log with 336 errors: Conditional jump or move depends on uninitialised value(s) inside low level SSL code so there is sth wrong with SSL library or rather with Harbour wrapper to this library (hbssl) and this may cause any unpredictable results depending on values in uninitialised memory. Probably in your MT builds this memory contains data which breaks communication process. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
Hi, Przemek, i was think, may be problem is the multithread support of openssl dll´s i was trying build openssl, but without success If non HVM thread tries to access HVM, i.e. to execute some .prg code then it simply GPF so I do not think it's the source o your problem. but if you test gmail.prg with -MT you´ll see the problem Both MT and ST versions returns .T. so they seem to work but valgrind produces for both of them 285KB log with 336 errors: Conditional jump or move depends on uninitialised value(s) inside low level SSL code so there is sth wrong with SSL library or rather with Harbour wrapper to this library (hbssl) and this may cause any unpredictable results depending on values in uninitialised memory. Probably in your MT builds this memory contains data which breaks communication process. It's possible (and should fixed, just not by my eyes), but my suspect in this case is an MT requirement of OpenSSL, which isn't satisfied in hbssl. See here: http://books.google.hu/books?id=FBYHEBTrZUwCpg=PA74lpg=PA74dq=OPENSSL+multithreadsource=blots=Am7l5e1yJLsig=r7QaLIfah-KE8lQDx4RbSXVPPJIhl=enei=btbuS_vZI-STOO7C8fYHsa=Xoi=book_resultct=resultresnum=8ved=0CDAQ6AEwBw#v=onepageq=OPENSSL%20multithreadf=false I tried, but couldn't adapt the code to Harbour threading API. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Szak�ts Viktor wrote: Hi, It's possible (and should fixed, just not by my eyes), but my suspect in this case is an MT requirement of OpenSSL, which isn't satisfied in hbssl. Yes, but it's important only for concurrent access. It does not change anything when only single thread access SSL code like in gmail.prg so for sure it cannot be source of the problem. See here: http://books.google.hu/books?id=FBYHEBTrZUwCpg=PA74lpg=PA74dq=OPENSSL+multithreadsource=blots=Am7l5e1yJLsig=r7QaLIfah-KE8lQDx4RbSXVPPJIhl=enei=btbuS_vZI-STOO7C8fYHsa=Xoi=book_resultct=resultresnum=8ved=0CDAQ6AEwBw#v=onepageq=OPENSSL%20multithreadf=false I tried, but couldn't adapt the code to Harbour threading API. Seems that it can be done quite easy. I'll look at it in next week but it's completely different thing not related to Fernando problem which probably should be resolved before so we can add some concurrent access tests. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
I don't have openssl installed... is it just ok to install it and point to it and rebuild harbour ? @Fernando: I did try to analyze your logs... are they complete or are some lines missing ? If I telnet to port 465 I receive no data from the server... I also checked with a tcpdump... so it's strange that in what you call the log without error you get a 220 mx.google.com ESMTP x34sm670731qce.15 without first sending some more commands... It may be that some data is sent to the server not using INETSENDALL so it is not logged... I need to install openssl before further investigation Francesco In the meanwhile I found this: 587 uses a TLS encryption connection. 465 uses an SSL encryption connection. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
I will install openssl tomorrow and I will have a look. Anyway, also your ok logs don't show that the message is really sent... Can you please: 1) insert in gmail.prg valid username/password, compile and run it in both ST and MT mode 2) delete username and password from gmail.prg and logs and send to me Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
Hi Przemek, It's possible (and should fixed, just not by my eyes), but my suspect in this case is an MT requirement of OpenSSL, which isn't satisfied in hbssl. Yes, but it's important only for concurrent access. It does not change anything when only single thread access SSL code like in gmail.prg so for sure it cannot be source of the problem. See here: http://books.google.hu/books?id=FBYHEBTrZUwCpg=PA74lpg=PA74dq=OPENSSL+multithreadsource=blots=Am7l5e1yJLsig=r7QaLIfah-KE8lQDx4RbSXVPPJIhl=enei=btbuS_vZI-STOO7C8fYHsa=Xoi=book_resultct=resultresnum=8ved=0CDAQ6AEwBw#v=onepageq=OPENSSL%20multithreadf=false I tried, but couldn't adapt the code to Harbour threading API. Seems that it can be done quite easy. I'll look at it in next week but it's completely different thing not related to Fernando problem which probably should be resolved before so we can add some concurrent access tests. Thank you. As for hbssl existing code, any hints/changes you could make would be great. Current state is the best I could come up with and I could stare at it for an infinite time, for my eyes it looks alright. (I remember having been testing it with valgrind even, at some stage) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
