Segfault appears on MS SQL SERVER queries on Skylake architecture since odbc 1.3.0

[BenoitLondon]

EDIT:

found the cause with R gdb the segfault appears in:

Thread 1 "R" received signal SIGSEGV, Segmentation fault.
0x00007ffff753e930 in __lll_unlock_elision () from /lib64/libpthread.so.0

googling the issue gave me this explanation

and this fix for my OS (OpenSuse) which was to disable hardware lock ellision...

Any input @jimhester on how to go forward (disable what uses hle at the package level or at the user OS level?)

tldr:

SQL SERVER queries segfault inside Gitlab CI (which runs on Intel Skylake) with latest odbc 1.3.0 and work fine in any other configuration (old version of odbc or local docker image with new version of odbc but no Skylake)

I think I isolated the problem to a minimal example failing on SKylake architecture

> query = "SELECT name, time_utc FROM daylight_saving_time"
> 
> conn <- odbc::dbConnect(odbc::odbc(),
+ driver = "/usr/lib64/libtdsodbc.so",
+ server = "test.sql***",
+ database = "***",
+ uid = "***",
+ pwd = "***",
+ port = "***")
> 
> rs <- odbc::dbSendQuery(conn, query)
> res <- odbc::dbFetch(rs)
> res
                            name            time_utc
1    fall_change_backward_na_bst 2018-10-28 01:30:00
2  fall_change_backward_na_bstp1 2018-10-28 02:30:00
3   spring_change_forward_na_bst 2018-03-25 01:30:00
4 spring_change_forward_na_bstp1 2018-03-25 02:30:00
5                         summer 2018-07-01 22:00:00
6                         winter 2018-01-01 22:00:00
> odbc::dbClearResult(rs)

 *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
 1: result_release(res@ptr)
 2: odbc::dbClearResult(rs)
 3: odbc::dbClearResult(rs)
An irrecoverable exception occurred. R is aborting now ...

So the problem lies in dbClearResult where it looks it has already been cleared? Also I don't understand why the traceback indicates two calls to odbc::dbClearResult ?

Issue Description and Expected Result

Database

On MYSQL database it never fails On SQL SERVER database it fails only on Skylake architecture

entry in .odbc.ini file is like this:

[MSSQLTEST]
Driver = /usr/lib64/libtdsodbc.so
Description = Connection to SQL server test
Trace           = Yes
TraceFile       = /tmp/odbctest.trace
Server = test.sql.***
Database = ***
Port = ***
User = ***
Password = ***

Reproducible Example

I can't reproduce the problem without the same context...

gcc -march=native -Q --help=target|grep march
-march=                               nocona

[BenoitLondon]

I managed to reproduce the segfault on a similar VM to where gitlab runs and it could be related to Intel Skylake processor and compiler options

I also tracked it down to this commit as previous version doesn't segfault but this commit causes segfault...

[jimhester]

Could you try a different driver SQL driver, e.g. Microsoft's ODBC Driver for SuSE? (https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver15#suse17)

[BenoitLondon]

Could you try a different driver SQL driver, e.g. Microsoft's ODBC Driver for SuSE? (https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver15#suse17)

Yeah it does not segfault with microsoft driver... but does with freetds 1.1.36

[jimhester]

I would have to guess this is a freetds driver issue then, not knowing what else could cause this.

[BenoitLondon]

fails also with latest freetds 1.2.10 Raised an issue on Freetds...