libc++abi.dylib: terminating with uncaught exception #909
Comments
|
@keithbrinks There is another related issue 25 but for this one you would need to wait for ODBC 17.3 stable release in early 2019. |
|
@keithbrinks according to your original description, you indicated that ODBC driver version was 13.1. But anyway, you might want to try the workaround suggested in issue 25 |
|
@keithbrinks have you tried isolating the causes by running your php script with POST method(s) in a command line without using Apache or Nginx? Also, just so you know, Apache and Nginx might have settings for default languages. |
|
@yitam For now I'm sticking to Apache since it seems to provide the best error message (and I'm assuming the issue, whether I'm using Apache or Nginx, is the same). Anyway, I did throw Laravel, the PHP framework I use, includes a nice command-line tool for testing PHP with. I'm pretty sure this means bypassing Apache. It returns the same error message: The database record IS being created, but whatever is happening inside Laravel's create() method is causing the issues. I also did the next logical thing: Take Laravel out of the equation. I wrote a simple PHP script that connects using the SQLSRV driver and inserts a record. This works without throwing any errors. So I am thinking at this point there's something specific with my MacOS environment that Laravel is not playing nice with. |
|
I think something was just massively wrong with my SQLSRV / ODBC driver installation. I blew everything away (Apache, Nginx, PHP, SQLSRV, ODBC), switched over to MAMP (in an attempt to have a clean web server installation), downloaded the SQLSRV driver via GitHub (instead of PECL), re-ran the Microsoft ODBC installation via Homebrew, and now it's working as expected. I have no idea if something perhaps went awry with the PECL installation? In any case, I do appreciate the help. I'll close the issue. |
|
Hi @keithbrinks, let's continue here unless we are absolutely sure it has something to do with the ODBC driver. Since several issues are referenced, to help us investigate and avoid any unnecessary confusions, please address the followings, assuming you're using macOS 10.14.2:
|
|
Hi @yitam, So I believe I've narrowed this issue down to a specific package that's being used within my project. I created a ticket in their repository here: Essentially, the issue is only occurring when I'm logged in via an LDAP connection between my application and Active Directory. As I posted there, I do not know if the issue in a conflict coming from the packages side or if it's still with the sqlsrv driver. Can you clarify whether or not the error message I'm getting indicates it IS an issue being caused at sqlsrv, or is it possible it's totally unrelated? Here is the complete crash report: |
|
Oh, and to answer your questions: I believe the locale my system is using is For the repro script, see the issue I linked to above. It's definitely a specific scenario. I installed PHP via brew, and I am using Nginx and Laravel. |
|
Thanks @keithbrinks for the crash report. We will start investigating. Please stay tuned. |
|
hi @keithbrinks how did you get our pdo_sqlsrv driver? From GitHub or did you use pecl install? |
|
Hi @yitam, I used |
|
Cool. @keithbrinks please help us troubleshoot by following these steps: At this point, make one small change in a file in pdo_sqlsrv-5.6.1, like this
Then do the following: After this, please run the problematic php script again. Do let us know if this still throws the same exception. |
|
@yitam, it is no longer throwing any errors after following those steps. Everything appears to be working as expected with that. What does that mean? Is it an issue with my system that we're hardcoding something to, or an issue with the driver itself? |
|
@keithbrinks this comment from the related issue 18 explains the problem. I think it's something peculiar in the mac settings that triggers this. The proper fix with try/catch mechanism will be merged in pdo_sqlsrv driver in our next preview. |
|
@yitam Great! I'll be sure to test it when I see it released. Thanks so much for your help! |
|
You're welcome @keithbrinks |
Merged
|
@keithbrinks we have merged the fix but we don't have ETA for a preview yet. We will close this issue for now and please feel free to reopen if you have any related questions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
.+Please check the FAQ (frequently-asked questions) first. If you have other questions or something to report, please address the following:
PHP Driver version or file name
5.3.0
SQL Server version
SQL Server 2017 Express
Client operating system
MacOS 10.14.2
PHP version
7.2.13
Microsoft ODBC Driver version
13.1
Table schema
Problem description
I don't know if this problem is with the PDO_SQLSRV driver or not. But so far I have experienced the same error running PHP 7.2 and 7.3 with both Nginx and Apache, and I tried using MAMP as well.
I have a local web server setup and am able to browse to my Laravel application fine and it's able to pull data from the database (SQL Server is running on a remote server). I am able to perform GET, PATCH, and DELETE requests without any issues. However, when I send a POST request it errors on the response. The data does go through and an update is made to the database, but I get either a 502 Bad Gateway or ERR_EMPTY_RESPONSE error depending on if I"m using Apache or Nginx.
The thing that has me questioning the PDO_SQLSRV driver is the error I'm getting in the error log:
I have no idea what this means and I really can't find anything on it... So I'm just question if SQLSRV uses
libc++abi.dyliband whether or not the error is originating somewhere here.Note that I'm running the same application on both an IIS and Ubuntu server -- in both cases everything is working fine so I don't believe it's an application error... I've spent many hours troubleshooting Apache/Nginx (replicating the Ubuntu server config), but to no avail.
Please let me know if SQLSRV could be the culprit or not, and if so what information I can provide.
Thanks
The text was updated successfully, but these errors were encountered: