Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQLSRV driver unhandled exception #5890

Closed
JeremyLC opened this issue Jan 26, 2015 · 8 comments
Closed

SQLSRV driver unhandled exception #5890

JeremyLC opened this issue Jan 26, 2015 · 8 comments

Comments

@JeremyLC
Copy link

JeremyLC commented Jan 26, 2015

In libraries\joomla\database\driver\sqlsrv.php lines 663-665

// Throw the normal query exception.
JLog::add(JText::sprintf('JLIB_DATABASE_QUERY_FAILED', $this->errorNum, $this->errorMsg), JLog::ERROR, 'databasequery');
throw new RuntimeException($this->errorMsg, $this->errorNum);

This is exception isn't being handled at all. This causes Joomla to crash, which causes the browser's connection to reset. No error is displayed or logged.

Steps to reproduce the issue

Pass a bad query to execute() and you'll experience it every time.

Expected result

The user should see an error message detailing what went wrong during the failed query.

Actual result

Nothing. ERR_CONNECTION_RESET and no diagnostic information in any logs anywhere. (no PHP logs, no Joomla logs, no IIS logs, no Windows Server logs. ZIP)

System information (as much as possible)

Windows 2012 R2, Datacenter (Version 6.3, build 9600)
IIS 8.5.9600.16384
PHP 5.5.19
Joomla 3.3.6

Additional comments

This is exposed by bug #5850 as well.

@brianteeman
Copy link
Contributor

Resetting priority according to our standards https://docs.joomla.org/Priority


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5890.

@sovainfo
Copy link
Contributor

sovainfo commented Jun 4, 2015

By default Joomla doesn't log errors. Suggest to append to libraries/cms.php:

JLog::addLogger(array(), JLog::ERROR, array('deprecated'), true);

@JeremyLC
Copy link
Author

JeremyLC commented Jun 4, 2015

The problem isn't just the lack of an error message or logging, the problem is that it hard crashes PHP and nothing gets rendered. There needs to be a catch somewhere to actually catch said exception or it still won't get logged.

@mbabker
Copy link
Contributor

mbabker commented Jun 4, 2015

There are a lot of exceptions still going uncaught in the app (there's easily a dozen PRs just for database related errors right now). Even uncaught it should be hitting our global handler and displaying an error page, and if that throws an error should give an "Error displaying the error page" message. If it's crashing PHP, then a PHP Fatal Error somewhere along the way; an uncaught exception shouldn't do that with our code (and with the right error reporting level, the message would be "Uncaught exception").

@JeremyLC
Copy link
Author

JeremyLC commented Jun 4, 2015

I do know from researching this that I am not the only one who experienced this particular crash, nor was it limited to a specific version of PHP. The end result, for me, was that I couldn't use Joomla for what I wanted to use it for because I couldn't install the modules I needed ( http://forum.joomla.org/viewtopic.php?f=728&t=871724 ) and I couldn't count on the SQLSRV driver not to blow up unexpectedly.

@alikon
Copy link
Contributor

alikon commented Jun 10, 2015

@JeremyLC can you test #7145 should let you install modules

@JeremyLC
Copy link
Author

This still won't let me install the modules I want because they only provide installation scripts for MySQL. Further, barring some major changes to Joomla, the backend still won't bother to check which DBMS a given module was designed for, and still WILL send the wrong SQL to the DBMS you're using. (see this thread here http://forum.joomla.org/viewtopic.php?f=728&t=871724 ) Finally, though, I gave up on being able to use Joomla for my project. I was losing too much time to troubleshooting and debugging.

The way I see it, the solution to my particular problem is to either

  1. Actually use the DBMS-specific SQL scripts included in module packages (if they're included at all), giving a warning if there are no scripts for the DBMS your particular installation is using.

or

  1. Add yet-another-meta-language of some kind that describes the tables and data structures a module needs in the DBMS that is then left to the back-end driver to actually implement.

(or 3. Drop the charade of "support" for non-MySQL DBMSs, when it's clear that it only works reliably and as-expected on MySQL)

tl;dr: No NULL or NOT NULL checking will allow MS SQL server to execute SQL code written for MySQL. Joomla needs to not send MySQL code to NOT-MySQL DBMSs.

@alikon
Copy link
Contributor

alikon commented Jun 14, 2015

@JeremyLC i know that there are some lines of code mysql-centric written
the #7145 is only a temporary & dirty fix to let install quite a bit of extensions on mssql and/or not to crash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants