Odd NOE Crash

Hey all,

I’m seeing some strange crashes from some customers for what appears to be an NOE related to an SMTP socket, but there is no SMTP socket relevant to the code executing where the error occurs.

Here is the stack dump:

NilObjectException RaiseNilObjectException Delegate.IM_Invoke%%o<SMTPSocket> AddHandler.Stub.1%% XojoFramework$3117 XojoFramework$3065 XojoFramework$3055 XojoFramework$3053 XojoFramework$3084 XojoFramework$10797 XojoFramework$3744 XojoFramework$4435 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ __CFRunLoopDoTimer __CFRunLoopDoTimers __CFRunLoopRun CFRunLoopRunSpecific CFRunLoopRunInMode RunCurrentEventLoopInMode ReceiveNextEventCommon _BlockUntilNextEventMatchingListInModeWithFilter _DPSNextEvent -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] XojoFramework$1274 -[NSApplication _doModalLoop:peek:] __35-[NSApplication runModalForWindow:]_block_invoke -[NSApplication runModalForWindow:] __19-[NSAlert runModal]_block_invoke -[NSAlert runModal] XojoFramework$523 MessageDialogShowModal MessageDialog.ShowModal%o<MessageDialogButton>%o<MessageDialog> mainWindow.mainWindow.CheckDemoTimer_Action%%o<mainWindow.mainWindow>o<Timer> Delegate.IM_Invoke%%o<Timer> AddHandler.Stub.0%% XojoFramework$10043 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ __CFRunLoopDoTimer __CFRunLoopDoTimers __CFRunLoopRun CFRunLoopRunSpecific CFRunLoopRunInMode RunCurrentEventLoopInMode ReceiveNextEventCommon _BlockUntilNextEventMatchingListInModeWithFilter _DPSNextEvent -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] XojoFramework$1274 XojoFramework$1275 Delegate.Invoke%% Application._CallFunctionWithExceptionHandling%%o<Application>p XojoFramework$9784 XojoFramework$1274 -[NSApplication run] XojoFramework$9786 RuntimeRun REALbasic._RuntimeRun _Main main start

The SMTPSocket message is right at the top:

RaiseNilObjectException Delegate.IM_Invoke%%o<SMTPSocket> AddHandler.Stub.1%% XojoFramework$3117

Nowhere in my entire app am I using AddHandler on an SMTP socket…So I’m not sure what’s going on…

So my parts of the code are in the middle:

MessageDialogShowModal MessageDialog.ShowModal%o<MessageDialogButton>%o<MessageDialog> mainWindow.mainWindow.CheckDemoTimer_Action%%o<mainWindow.mainWindow>o<Timer>

OK, so in that Timer, there is NO smtp socket created nor is there any mention of an SMTP socket.

I’m totally confused… I can’t duplicate this and have no idea what is going on…

I think I may have found this but I’m some what confused… I was able to make the error happen on my machine.

I have a Window that shows up the very first time the user starts the app where they enter their name and email. That then e-mails me from an SMTPSocket. I don’t allow the window to close until that SMTPSocket’s work is complete. But it appears something is still possibly happening with this socket? That’s the only thing I can think of…But I don’t use an AddHandler directive on it…

OK. So I figured out what was causing this but I’m not sure I completely understand why. Something has changed with the SMTPSocket in the framework. Thinking I should file a bug report.

So I have the Socket sending an e-mail. In the MailSent Event for the socket, I close the Window. The window gets destroyed but the socket does not. The socket is still existing. I can see it in the debugger when the program breaks for the exception. The exception is happening in the Xojo framework. There is a WeakRef for the ownerWindow of the socket - it’s NIL. But the socket is still there.

I’ve created a feedback report: <https://xojo.com/issue/44055>

The project is private since it contains a mail server password that I didn’t want to expose to the world.

I’ve just had a very similar problem. Mine was that I was closing the window in the changed event of a listbox and that caused a framework assertion which crashed the application. The workaround is to use xojo.core.timer.calllater(0, addressof ).

@Joe Ranieri created <https://xojo.com/issue/44039>.

Does the SMTPSocket (subclass) own the window being closed in the MailSent event and/or is the SMTPSocket a property of this window?
Do you have a circular reference ownerWindow <-> SMTPSocket?

[quote=268431:@Eli Ott]Does the SMTPSocket (subclass) own the window being closed in the MailSent event and/or is the SMTPSocket a property of this window?
Do you have a circular reference ownerWindow <-> SMTPSocket?[/quote]

The SMTP socket is not subclassed. It’s just a standard SMTPSocket dropped onto the window. So no, there’s no circular references unless the Xojo framework is creating them.

[quote=268404:@Wayne Golding]I’ve just had a very similar problem. Mine was that I was closing the window in the changed event of a listbox and that caused a framework assertion which crashed the application. The workaround is to use xojo.core.timer.calllater(0, addressof ).

@Joe Ranieri created <https://xojo.com/issue/44039>.[/quote]

It must be a similar issue. There’s no reason why you should not be able to close a window from the event in a control. Having to use a timer is a hack, frankly.

I already had a timer in there that I was using to close the window in the event of an SMTPSocket error. So I’m just using that timer after the mail sent event as well.

Could it be that the user is closing the window before all of the events on the socket have finished firing?

The user can’t close the window. Unless some socket event fires after mailsent then no.

See my example in feedback. Stephane quickly closed it as not reproducible but I beg to differ. I know he didn’t even try it out becuase the app sends me an email!

@Jon Ogden: could you do a public example? I’d like to have a look at this, too.

There probably is a disconnect event.

[quote]
See my example in feedback. Stephane quickly closed it as not reproducible but I beg to differ. I know he didn’t even try it out becuase the app sends me an email![/quote]
I suspect he changed the code to email to himself.