SQL query error: "Error running query: Worker exited prematurely: signal 6 (SIGABRT)."

Issue Summary

I am attempting to migrate our Power BI dashboards to Redash. Testing in a self-hosted docker container. I am fetching data from an Azure SQL server with a SQL query that I know should return about 100K lines of data. Works fine in SSMS. When running the same query in Redash I get:

Error running query: Worker exited prematurely: signal 6 (SIGABRT).

What might be the reason for this, and how to address the issue? I see several similar posts on the topic, but they are inconclusive and did not help me pinpoint the problem.

Technical details:

  • Redash Version: 8.0.0+b32245 (a16f551e)
  • Browser/OS: Chrome / Win 11
  • How did you install Redash: Docker image built from src

Cheers, Mike

It sounds like your query runner ran out of memory and crashed. Try adding a LIMIT 1000 suffix or TOP 1000 prefix to your query to see if that succeeds (not sure which dialect Azure SQL uses).

Although there’s a lot of common ground between them, Redash isn’t a drop-in replacement for PowerBI or SSMS. 100k lines of data is a lot more than Redash is designed to retrieve. Redash is a tool for visualising results that have already been aggregated by your database.

You can boost the amount of RAM available to your docker containers, which would potentially allow a query with 100k rows to succeed. But the moment you load this in the web application the browser tab will probably crash.

Hi jesse,

Thanks for your reply. I will take into consideration that Redash may not be the best replacement for Power BI.

After writing this post I did manage to retrieve around 100K lines of data with a slightly different query, and it ran reasonably well imbedded in an iframe. So, apparently It’s not a PC hardware limitation or a Redash related software limitation that caused the issue.

I will attempt to assign more CPU and RAM to the Docker environment and see if this helps.

I will post the solution here I if I find it, but please be free to comment if you have experienced something similar.

Cheers, Mike

1 Like

I get this error on some queries, but my query is fast and the results are small. When I run on MSSQL, I get 22 records in 0.333 seconds.

Any other guess as to what could be causing this issue?

There’s not enough info in your post to debug. Not all SIGABRT failures share the same cause. It would be helpful to know your redash version and operating system. Also does this affect all queries or only some? Does it happen in a reproducible way? Or at random? Does it affect all data sources or only one?

  • Environment Details:
    • Redash version: Version: 8.0.0+b32245 (a16f551e)
    • Browser/OS: Chrome / MacOS Monterey
    • Hosting VM Specs:
      • Linux (ubuntu 18.04)
      • 2 vcpus (last 30 days averaged 3% CPU usage with spikes up to 40%)
      • 16 GiB memory (last 30 days averaged 11GB of free RAM with drops down to 9GB)
  • All queries or some: It doesn’t affect all queries, but it nearly always affects the affected queries. Meaning, if a query has the issue, it basically always has the issue. (I have observed some rare situations where the same query works)
  • Reproducible: Because it happens basically every time, it is easy to recreate. I have seen it more often in MSSQL queries that have comments, but that isn’t always true for either success or failure
  • All sources or one: happens mostly on MSSQL sources, but is probably because we have more MSSQL queries and it can happen with any/most

Also, when it fails, it often fails very quickly, which makes me think it isn’t a resources issue, but may be something in how it is parsing the code.

I am providing the current query below in case there is something in the code that is incompatible with Redash.

NOTE: We use Temp Tables to keep the data free and reduce processing time

DECLARE @ReportId varchar(100) = 'ShopCQ_UserDemandLinesSentBySupplierandDate'

	DECLARE @last datetime

	SELECT @last = MAX(ReportDate) FROM dbo.CommonQueries  WHERE ReportId = @ReportId 
    IF OBJECT_ID('tempdb..#SendHistoryTemp') IS NOT NULL DROP TABLE #SendHistoryTemp
    SELECT ReportDate,ServerName,Instance
					,CAST(col1 as date) Period
					,DATEPART(day, CAST(col2 as date)) dayOfMonth
					,col3 Supplier
					,col4 UserNAme
					,CAST(col5 as int) DemandSentCount 
					,ROW_NUMBER() OVER (PARTITION BY Instance,CAST(col1 as date) ORDER BY DATEPART(day,CAST(col2 as date))) SendOrder
			INTO #SendHistoryTemp
	        FROM dbo.CommonQueries 
	        WHERE reportid = @ReportId 
	        	AND ReportDate = @last
	            AND ServerName <>'_Header'
	            AND CAST(col2 as date) >= '2022-01-01'
    IF OBJECT_ID('tempdb..#dailyTemp') IS NOT NULL DROP TABLE #dailyTemp
	SELECT Period,
			,SUM(DemandSentCount) TotalSent
			,COUNT(DISTINCT Instance) NewInstances
			,SUM(COUNT(Instance)) OVER (PARTITION BY Period ORDER BY d.dayOfMonth) MnthProgress
			,SUM(SUM(DemandSentCount)) OVER (PARTITION BY Period ORDER BY d.dayOfMonth) MnthLinesProgress
		INTO #dailyTemp
		FROM (SELECT dayOfMonth FROM #SendHistoryTemp WHERE SendOrder = 1 GROUP BY dayOfMonth) d
			LEFT JOIN #SendHistoryTemp st ON d.dayOfMonth = st.dayOfMonth
		WHERE SendOrder = 1
		GROUP BY d.dayOfMonth,Period
	SELECT a.dayOfMonth
		,COALESCE(c.TotalSent,0) TotalSent
		,SUM(COALESCE(c.TotalSent,0)) OVER (ORDER BY a.dayOfMonth) MonthSent
		,a.NewInstances AvgNewInstances
		,COALESCE(c.NewInstances,0) NewInstances
		,SUM(COALESCE(c.NewInstances,0)) OVER (ORDER BY a.dayOfMonth) MonthEngaged
	FROM (SELECT dayOfMonth
				,AVG(MnthLinesProgress) AvgSent
				,AVG(NewInstances) NewInstances
				,AVG(MnthProgress) AveMonthEngaged
			FROM #dailyTemp
			GROUP BY dayOfMonth	
		LEFT JOIN (SELECT dayOfMonth,COUNT(DISTINCT Instance) NewInstances, SUM(DemandSentCount) TotalSent FROM #SendHistoryTemp WHERE SendOrder = 1 AND Period = DATEADD(d,1,EOMONTH(GETDATE(),-1)) GROUP BY dayOfMonth) c ON a.dayOfMonth = c.dayOfMonth
    IF OBJECT_ID('tempdb..#dailyTemp') IS NOT NULL DROP TABLE #dailyTemp
    IF OBJECT_ID('tempdb..#SendHistoryTemp') IS NOT NULL DROP TABLE #SendHistoryTemp

Thanks for a fullsome bug report :ok_hand:

You’re right that it’s a puzzler. I do wonder if the problem is your usage of DECLARE statements producing unanticipated responses to the cursor. Redash is not built for anything other than SELECT statements, and doesn’t even support multi-statement execution (i.e. multiple queries separated by a semicolon ;).

However if this were a full blocker I’d expect the queries to always fail.

What do you find in your docker logs? Is there a full Python stack trace?

That appears to have been at least part of the cause.

I refactored the code to remove the DECLARE and it failed, then refactored to remove the temp tables, and it failed (maybe because it was still using CTEs, which do work in other queries)

But, when I ported all of that to a SQL view, then queried the view in Redash, it worked!

I don’t know how to check the docker logs. I will have to have my team check it later, but at least it is operational again.

Thanks for your help!

Thank you very much for the detailed report and following up on how it was solved.

I’d like to invest some effort to improve the multi-statement behaviour of our MSSQL connector as I think this is a blocker for adopting Redash for a lot of users. Perhaps I can ping you for your thoughts down the road?

Of course! I am happy to help.