Sonar cache download fails since update to 2026.5.2-developer

SonarQube Server / Community Build
, ,
1

After the updating sonar from 2026.4.1-developer to 2026.5.2-developer, downloading the analysis cache started to fail with the following exceptions:

java.lang.IllegalStateException: Fail to select cache for branch 14dac0df-52a1-4b6e-b944-6119057b8064
at org.sonar.db.scannercache.ScannerAnalysisCacheDao.selectData(ScannerAnalysisCacheDao.java:77)
at org.sonar.server.scannercache.ScannerCache.get(ScannerCache.java:53)
at org.sonar.server.scannercache.ws.GetAction.handle(GetAction.java:94)
at org.sonar.server.ws.WebServiceEngine.execute(WebServiceEngine.java:115)
at org.sonar.server.platform.web.WebServiceFilter.doFilter(WebServiceFilter.java:84)
at org.sonar.server.platform.web.MasterServletFilter$JavaxFilterAdapter.doFilter(MasterServletFilter.java:194)
at org.sonar.server.platform.web.MasterServletFilter$GodFilterChain.doFilter(MasterServletFilter.java:165)
at org.sonar.server.platform.web.MasterServletFilter$HttpFilterChainAdapter.doFilter(MasterServletFilter.java:208)
at org.sonar.server.platform.web.SonarQubeIdeConnectionFilter.doFilter(SonarQubeIdeConnectionFilter.java:62)
at org.sonar.server.platform.web.MasterServletFilter$JavaxFilterAdapter.doFilter(MasterServletFilter.java:194)
at org.sonar.server.platform.web.MasterServletFilter$GodFilterChain.doFilter(MasterServletFilter.java:165)
at org.sonar.server.platform.web.MasterServletFilter.doFilter(MasterServletFilter.java:126)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.UserSessionFilter.doFilter(UserSessionFilter.java:83)
at org.sonar.server.platform.web.UserSessionFilter.doFilter(UserSessionFilter.java:70)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.CspFilter.doFilter(CspFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.CacheControlFilter.doFilter(CacheControlFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.SecurityServletFilter.doHttpFilter(SecurityServletFilter.java:60)
at org.sonar.server.platform.web.SecurityServletFilter.doFilter(SecurityServletFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.RedirectFilter.doFilter(RedirectFilter.java:56)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.EndpointPathFilter.doFilter(EndpointPathFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.RequestIdFilter.doFilter(RequestIdFilter.java:66)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.sonar.server.platform.web.RootFilter.doFilter(RootFilter.java:100)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:141)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:111)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:165)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:77)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
at ch.qos.logback.access.tomcat.LogbackValve.invoke(LogbackValve.java:294)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:86)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:71)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:347)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:71)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:1307)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:2201)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:74)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:949)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:483)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:74)
at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: org.postgresql.util.PSQLException: ERROR: invalid memory alloc request size 1185917291
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2993)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2656)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:446)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:533)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:449)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:197)
at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:140)
at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
at org.sonar.db.scannercache.ScannerAnalysisCacheDao.selectData(ScannerAnalysisCacheDao.java:70)
... 49 common frames omitted

With various scanners. Ihmo. this is clearly a bug. The size of a cache should not matter. Fetching DB should be able to cope with those limits.

Is this a known issue? Any way to mitigate it without disabling caching? How to check what get’s cached?

2

Did look a bit into the cached data and the most of the space is used by taint analysis

4

Hi @chco,

Thanks for reaching out. I will be looking into that.

I come back to this with more information later today.

Philipp

5

Hi @chco,

This is indeed an unknown issue, so thanks for bringing it to our attention.

You are right that the size of the cache shouldn’t matter. In the logs, it says Caused by: org.postgresql.util.PSQLException: ERROR: invalid memory alloc request size 1185917291 – the requested size is ~1.1 GiB. We seem to overflow a limit from PostgreSQL’s memory allocator that is set as #define MaxAllocSize ((Size) 0x3fffffff).

It seems that the C/C++ taint analysis’ intermediate representation is causing the increase in cache size here. As a workaround, you can clear the cache and explicitly disable the taint analysis feature using setting the property `sonar.cfamily.taintAnalysis=false`, see Customizing the analysis | SonarQube Cloud | Sonar Documentation for more details. However, not that you will not see any taint-related issues for C and C++ then. Please let me know if this (temporarily) solves the issue for you.

Are you able to share how many translation units your C/C++ analysis run contains? Are you using the C/C++ Cross-Translation-Unit (CTU) symbolic execution in parallel to C/C++ taint analysis?

I will further investigate this and come back to you once I have more details.

6

Hi @pdschbrt,

thanks for confirming the issue. Yes we hit the hard limit of PosgreSQL. Basically caches without taint analysis are around 40-50 MB. With taint analysis the get around 700-800 MB in the DB. Once the data is fetched the size doubles due to PosgreSQL hex encoding. Hence the exception.

For now I went ahead and disable taint analysis, as we weren’t actively using it yet. So yeah this is fine. Alternatively I could disable caching or move the cache to disk, which is not good due to different agents which run the sonar-scanner.

Currently we have around 3000 translation units. We don’t use CTU.

7

We have the same problem on Sonar Enterprise Edition v2026.5.1.
Similar cache sizes, only sonar.analysisCache.enabled=false help.

8

Thanks for the “+1”, @ferbenqdnt.

We’re on it.

I’ll keep you posted.

9

If that is a viable option for you, @ferbenqdnt:

As a workaround, you have two options, and the first one lets you keep everything.

On SonarQube Server you can move the cache off the database entirely by setting sonar.cfamily.analysisCache.mode=fs together with sonar.cfamily.analysisCache.path=<path> – a dedicated path per project, on storage that persists between CI runs. You keep file-level caching and incremental taint analysis, and nothing goes into the database table that’s failing. Both properties are documented under Customizing the analysis.

If a persistent path isn’t practical in your CI setup, the fallback is the one from my earlier message: sonar.cfamily.taintAnalysis=false, which keeps normal file-level caching intact and costs you only the taint-related C/C++ issues. You might need to clean the cache first.

10

Thank you.

I already try theese options, but we definitelly must have taint analysis, and yes I use Sonar in CI, so local filesystem cache is not suitable for me. So disable cache completelly is not best solution, because every run takes ~3 hours instead of half, but we have to accept it now.

This issue start appear after upgrade Sonar to v2026.5.1 from v2026.4.1, no other infra or huge source code changes, so Sonar should fix it.

17

I ran into this exact problem, and I have some questions to this disable taint analysis approach:

  1. Do I have to change my sonar-project.properties on all branches or is enough to do this on the default branch of the repo?
  2. Can I change this maybe in the Web UI?
  3. How can I clear the cache for one project?

We have many feature branches running analysis a given time, and I don’t want to have clear the cache multiple times til all developers have rebased to get the latest properties file.

18

Hi Richard,

  1. you have to disable it an all branches were you do sonar analysis
  2. I don’t know about the UI, hope @pdschbrt can reply to that.
  3. Clearing the cache means truncating the table in your DB. Not 100% sure about it, but I think I recall it was named: scanner_analysis_cache

Cheers

20

Hi @roe85, hi @chco,

Thanks for providing some first few answers, @chco.

Yes, I’m afraid you will need to disable it on all branches on which you conduct sonar analysis.

While you can configure some supported analysis properties directly in the UI, you will need configure the taint-analysis-related properties on the scanner/CI side, rather than in the UI.

I believe you should be able to clear the cache without a direct database modification by using

curl --fail-with-body -u "$SONAR_TOKEN:" -X POST \
  "$SONAR_HOST_URL/api/analysis_cache/clear" \
  --data-urlencode "project=YOUR_PROJECT_KEY"

Clear only one branch by adding:

--data-urlencode "branch=YOUR_BRANCH_NAME"

The project and branch filters are available since 9.7; branch requires project. Omitting both filters clears the cache for the entire instance, so take care. A successful request returns HTTP 204.

In the meantime, I have to ask you to apply one of the workarounds proposed in this thread, while we are working on a proper solution.

Cheers,
Philipp