ARC compatibility and Invalid Email Address crash

[GoogleCodeExporter]

Hi all,
just to let you know that I've updated the SKPSMTPMessage classe and Extensions 
to make
the library compliant to ARC in iOS5.

Also, I happened to track down a bug that caused the application to terminate 
with EXC_BAD_ACCESS.
That only occurred when trying to send emails to invalid addresses (ie: 
yourname.hotmail.com): apparently,
the parser did not enlist the SMTP response code: 501 5.5.4 Invalid Email 
Address as a possibility,
which caused the program to keep running but  without a new StartWatchDog call, 
and a subsequest bad memory access at the end of the run loop when trying to 
deallocate the timer object.
I've changed the code to deal with this event.

If one of the developers could kindly point me towards the best place for me to 
upload the revised files,
I would be happy to share those with people using SKPSMTP under ARC developing.

Original issue reported on code.google.com by mmanni.dev on 21 Dec 2011 at 12:26

[GoogleCodeExporter]

The post should have probably gone under Enhancements, not defect. 

Original comment by mmanni.dev on 21 Dec 2011 at 12:28

[GoogleCodeExporter]

Can you attach it to a comment so I can use it please?

Original comment by DenisO...@gmail.com on 28 Dec 2011 at 2:41

[GoogleCodeExporter]

There you go...you need to replace some of the files provided in the original 
bundle with the ones here attached.
Let me know if you have any problem

Original comment by mmanni.dev on 28 Dec 2011 at 4:28

Attachments:

• [SKPSMTP Classes - ARC.zip](https://storage.googleapis.com/google-code-attachments/skpsmtpmessage/issue-56/comment-3/SKPSMTP Classes - ARC.zip)

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for that. It's implemented fine except the delegate was getting released 
early so I wasn't getting any success or failure messages. I changed it from:

@property (nonatomic, weak) id <SKPSMTPMessageDelegate> delegate;

to 

@property (nonatomic, strong) id <SKPSMTPMessageDelegate> delegate;

and I now get them fine. Let me know if you see any problem with this.

Original comment by DenisO...@gmail.com on 28 Dec 2011 at 4:47

[GoogleCodeExporter]

With ARC, it is good practice to always declare a delegate to be weak in order 
to avoid retain cycles (which happens, for instance, when A retains B and 
vice-versa). Making the delegate strong may be a workaround for your specific 
situation, but be aware that it may leed to memory leaks / objects not being 
deallocated at all. If I were you, I would instead have a look at the reason 
why the delegate is released to early in your specific procedure and tweak the 
code to handle that: it may be due to the customisation of the code to my 
specific needs (have a look at the conentionTimer target method in 
SKPSMTPMEssage.m) to address a BAD_ACCESS problem I had when the timeout method 
tried to reference the  SKPSMTPMessage instance that had already been released 
after the success / failure message. Hope that helps!

Original comment by mmanni.dev on 28 Dec 2011 at 5:24

[GoogleCodeExporter]

Hello Manni,
              Looks like this ARC Code leaks a lot of memory. Could you look into that. The CFHost and streams are getting retained both on the device and simulator. 

Ian, if you are reading this, you help will be appreciated. The current base 
current code "27 ?" seems to crash in you are building in the latest  SDK 
(non-beta).

Thanks 
Real.

Original comment by ireal....@gmail.com on 5 Feb 2012 at 3:14

[GoogleCodeExporter]

Hi there, yes you are right. The one uploaded was a quick beta and it has 
various issues: I will attach the refined version tonight alongside with a 
comment on a single memory leak in one of the CoreFoundation methods I can't 
seem to get rid of.

Original comment by m_mann...@hotmail.com on 5 Feb 2012 at 3:43

[GoogleCodeExporter]

Please find attached the new commit with multiple issues fixed.
There is still one memory leak I am fighting against: if you run the Leaks 
tool, you will notice that the function:

CFStreamCreatePairWithSocketToCFHost

in  NSStream+SKPSMTPExtensions generates a leak. There is also a comment on the 
line explaining why that should not happen, so I will be pleased if you could 
have a look into that and give feedback should you find the solution for the 
problem.
Thanks

Original comment by m_mann...@hotmail.com on 5 Feb 2012 at 4:28

Attachments:

• SMTPSender-ARC.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Manny,
             Thanks for the great wok. 

Sorry for the delay. I did find a few lot of leaks  on this one too. You beat 
me to the bridge_transfer in the NStream extension. I was trying to compile for 
ARC without GC ( Target : IOS 4.3+ ) .  So I had to make the delegate 
unsafe_unretained.  Don't  know if this is done right but do look into this .

I see a lot of bridge_retain with the "write" part. Are you sure yo want to 
retain those? Could you tell me why we need to do that? Im just getting my head 
wrapped around this one.

At this point my code as some good number of leaks but seems to point to 
Security framework the sslOptions do get released. I get feeling he stream is 
not fully release somewhere a thread is probably still running. neat one with 
stopWatchdog call in the dealloc.

Manny, If any of this is wrong please do tell me what is the better option and 
why? Looking forward to head from you on the right and wrong things in that  
code. 

Nagging feeling sslOptions is not getting released or stream is not getting 
releases. Mycode leaks under Security framework. CFhost and the likes disappear 
though.

Really looks forward to be hearing about the next update from you.
regards
Real

Original comment by ireal....@gmail.com on 7 Feb 2012 at 1:36

Attachments:

• SKPSMTPMessage.m

[GoogleCodeExporter]

Hello mmanni,

To start with, forgive my typos in the previous message.
                        Here is my update again on the test of the new code. Did some more tests. This time I took the 
static lib and compiled it in. 

Details: Ran a test agains the code I supplied above along with your changes in 
dealloc and some of my own to SKPSTMP sans the "bridge_rtained" for the streams 
and your cool changes to the Stream additions. At this point the last version 
of SKPSTMP  I sent seems to micmic the static lib of Ian ( 8-9) leaks all in 
Security Framework again - 'mp_init' and 'init'.  Looks like we have nailed it 
- at least for a good bit.  

I still wonder if we can fix that leak? What if something in Ian's original  
code is actually causing the leak? I also wonder why a system framework would 
leak.  


Could you please look at the code and give me some feedback please.

Base SDK 5.0 target mixed use 4.3 and 5.x. 

For the static build I added Ian's NSDATA addtions to the target project and 
added to build targets one for simulator and one for the device.

The scene is cycle root is that it shows a 16 byte item printing to a non-ivar  
of 128 Bytes. Looks to me as if it is from the read operation.

Please advice.

regards
iReal.

Original comment by ireal....@gmail.com on 8 Feb 2012 at 9:52