[#5890] - SQLSRV driver unhandled exception
- Closed
- 7 May 2016
- Medium
- Build: master
- # 5890
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.
| Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
| Priority | Urgent | ⇒ | Medium |
By default Joomla doesn't log errors. Suggest to append to libraries/cms.php:
JLog::addLogger(array(), JLog::ERROR, array('deprecated'), true);
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.
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").
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.
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
- 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
- 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.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-07 16:39:12 |
| Closed_By | ⇒ | brianteeman |
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.