WE Standalone fatal error with SSL

Looks like you’re using the MySQL plugin. Is there a way you can disable its use and see if the crash problem goes away?

Sure, I’ll do that later tonight :slight_smile:

If that’s it, do yourself a big favor and switch to the MBS SQL plugin. I’ve seen several similar problems this year. The MBS database middleware solution is way more solid.

Don’t know if it’s related or not, but I built a sample project that reliably crashes with a memory error for me in OS X. It happens only with the SSL socket, and reliably in fairly short order with connections from Chrome, but it can happen with Firefox and Safari it’s just not nearly as often.

<https://xojo.com/issue/31800> ssl errors with chrome

I personally have not been able to use Xojo’s SSL sockets for a while now. I have been using HAProxy in front of my apps even if I don’t really need it, just to prevent Xojo from having to handle SSL. I don’t know for certain it’s an SSL bug, could be a problem with the server socket that is handling ssl socket connections, but it’s also behind on TLS support so that’s another issue.

Brad, I’ve now commented out my MySQL connection code and guess what. The App does not crash any longer. Can’t use it as it needs its database but it does not crash.

What’s wrong with the MySQL plugin? I’ve had no problems with it before starting this project.

Greg, any insight?

[quote=91281:@Albin Kiland]Brad, I’ve now commented out my MySQL connection code and guess what. The App does not crash any longer. Can’t use it as it needs its database but it does not crash.

What’s wrong with the MySQL plugin? I’ve had no problems with it before starting this project.

Greg, any insight?
[/quote]

Hah. I knew it. I could write a dissertation about what’s wrong with Xojo’s database API, plugins, etc. Summary… over many years, it’s just plain unreliable. And right now, in 2014, the MySQL and PostgreSQL plugins are causing developers fits. The best course of action is to switch to using MBS’s database plugin. The API is different. But it’s built on middleware that a couple orders of magnitude more people use, so it’s very well field-tested.

If you value your time at more than a few dollars an hour, you’ll get farther, cheaper, faster switching to MBS than trying to put an actionable Feedback report together on this. This crashing MySQL problem has been discussed numerous times on forums and privately with Xojo in the past 6 months, and if they were interested in actually fixing it, they’d be reaching out to help rather than waiting for people to sink time into actionable Feedback. Time is money.

Doesn’t feel right to have to pay for a plugin for MySQL since I’ve got Pro that includes the database license, does it? :confused:

[quote=91505:@Albin Kiland]Doesn’t feel right to have to pay for a plugin for MySQL since I’ve got Pro that includes the database license, does it? :confused:
[/quote]

Nope. It doesn’t. But it is the shortest, least expensive path to MySQL connectivity that actually works. Therein lies the conundrum. I know that this has turned into an expensive problem for several people this year, one that dwarfed either Xojo’s or MBS’s license price. YMMV.

Thanks Brad. I guess there’s not much I can do.
I’ll have to download the MBS SQL Plugin and try to put some hours to try and implement it into my app and see if it solves this “stupid” annoyance for me.

I’ve put so much effort into creating a secure login system. If I don’t use SSL for it…well…pointless :confused:

Guys! Success! :slight_smile:
I got back to this issue now when I updated the app for another reason for our client.
I went over my code and found a teeny tiny call to Session.xx inside Session itself…as everyone knows this might lead to “hard to find errors”…no shit :stuck_out_tongue:

I might be posting this to early but after I replaced “Session.xx” with “xx”… Success! SSL now works! :slight_smile:

I’ll take that back for now. It worked on the dev server that is a copy of the production server but not on the production server itself.
No idea why.

[quote=116003:@Albin Kiland]I’ll take that back for now. It worked on the dev server that is a copy of the production server but not on the production server itself.
No idea why.[/quote]
Are you using the same certificate on both servers?

Which browser are you testing with?

Also, check the versions of glib2 on both servers.

Instead of using the style in pagesource have you tried using it in the PrepareSession() event HTMLHeader. I’ve used this to overwrite styles to have specific themes based various URL endpoints that come in.

Not that this fixes the bug, but it may get you by in the meantime. Using the page’s style you can choose which pages have which BG image as well.

[quote=116021:@Greg O’Lone]Are you using the same certificate on both servers?

Which browser are you testing with?[/quote]

The Dev server is an exact duplicate of the production server on the same domain. The duplicate was created from a template file of the production server.
I did get the thing to work just now after I got the errors (above) about 20 times (not kidding) relaunching the app.
Different browsers didn’t make a difference.

Puzzled…At least it works now after a huge amount of relaunches.