search

microsoft / mssql-docker

Official Microsoft repository for SQL Server in Docker resources
MIT License
1.72k stars 759 forks source link

mssql linux container stops during table creation activity with reason 0x00000001 #389

Open rayabueg opened 5 years ago

rayabueg commented 5 years ago

using 18.03.1-ce-mac65 pulled mcr.microsoft.com/mssql/server latest container crashes with the following during initial table creation activity

  This program has encountered a fatal error and cannot continue running.
  The following diagnostic information is available:

   Reason: 0x00000001
   Signal: SIGSEGV - Segmentation fault (11)
   Stacktrace: 0000563a312e5369 00007fbe1f151390 00007fbe1c80f087
           00007fbe1e721570 00007fbe1e719cdc 0000563a3132ef09
           0000563a31346088 0000563a31345673 0000563a312dc6c0
           0000563a312dc34f
   Process: 7 - sqlservr
   Thread: 111 (application thread 0x1190)
   Instance Id: 9c37021d-0f89-4ca2-85cf-6e55a152b61e
   Crash Id: e84dec90-0234-4fbc-b30b-d990f483c1d3
   Build stamp: 1dc223c2c297541dfebf5ce3265c3e74bbe289d287259e15dd32bd77f11bc1bd

Unfortunately I'm not able to show you the exact sql to repro as I'm installing off the shelf tibco software whose installer includes the sql which in a nutshell creates tables under an existing database. Below is how I repro the issue:

1) docker pull mcr.microsoft.com/mssql/server 2) docker run --memory="4096m" -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MySecret" -e "MSSQL_PID=Developer" --cap-add SYS_PTRACE -p 1401:1433 -d mcr.microsoft.com/mssql/server 3) connect to mssql: sqlcmd -S 192.168.100.100,1401 -U SA -P 'MySecret' 4) create db: create database myDB 5) run tibco installer against myDB, which quickly results in the above error

twright-msft commented 5 years ago

Anything in the logs at /var/opt/mssql/log/errorlog? You'll probably want to mount that directory using -v so that the logs are persisted to the host.

rayabueg commented 5 years ago

@twright-msft nothing interesting in the errorlog. It did capture a paldumper debug log. 2018-11-06 15:43:19.84 spid52 Starting up database 'tibco'. 2018-11-06 15:43:20.00 spid52 Parallel redo is started for database 'tibco' with worker pool size [2]. 2018-11-06 15:43:20.01 spid52 Parallel redo is shutdown for database 'tibco' with worker pool size [2].

~/docker_exports/tibco_sql/core.sqlservr.11_06_2018_15_44_05.8.d  ll log total 7528 -rw-r--r-- 1 rayabueg staff 0B Nov 6 09:44 dmesg.tail.txt -rw-r----- 1 rayabueg staff 24K Nov 6 09:44 errorlog -rw-r----- 1 rayabueg staff 0B Nov 6 09:44 errorlog.1 -rw-r--r-- 1 rayabueg staff 13K Nov 6 09:44 filelist.txt -rw-r--r-- 1 rayabueg staff 2.2M Nov 6 09:44 info.log -rw-r--r-- 1 rayabueg staff 17B Nov 6 09:44 journalctl.sql.txt -rw-r--r-- 1 rayabueg staff 17B Nov 6 09:44 journalctl.tail.txt -rw-r--r-- 1 rayabueg staff 973K Nov 6 09:44 paldumper-debug.log -rw-r----- 1 rayabueg staff 157B Nov 6 09:44 sqlagentstartup.log -rw-r--r-- 1 rayabueg staff 481K Nov 6 09:44 thread_information.log

rayabueg commented 5 years ago

One thing I should note is that my colleague is running on fedora and is able to proceed successfully; I'm running on macOS High Sierra 10.13.6

twright-msft commented 5 years ago

This may have something to do with the file system on macos. It's not as compatible with SQL Server on Linux as a typical Linux server. Can you maybe try again using a VM on Virtual Box or something like that? Another option is to open a support case. Do you have a means of doing that via an enterprise support agreement or something like that?

rayabueg commented 5 years ago

Good info, thanks! We do have enterprise support so may take that approach at a later time, but in the meantime will move onto a linux VM. Thanks again for your help