Visit of Component failed / value too long for column BINARY VARYING

SonarQube
#1

I’m trying to test scanning a new repo and getting a “Visit of Component failed” error in the background tasks, with what looks like a value too long for column BINARY VARYING error as the root cause:

### Error updating database.  Cause: org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='dto.data', mode=IN, javaType=class java.lang.Object, jdbcType=BINARY, numericScale=null, resultMapId='null', jdbcTypeName='null', expression='null'}. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.h2.jdbc.JdbcSQLDataException: Value too long for column "BINARY VARYING": "313d313b323d313b333d313b343d313b353d313b363d313b373d313b383d313b393d313b31303d31... (1361448)" [22001-210]
### The error may exist in org.sonar.db.measure.LiveMeasureMapper
### The error may involve org.sonar.db.measure.LiveMeasureMapper.insert-Inline
### The error occurred while setting parameters
### Cause: org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='dto.data', mode=IN, javaType=class java.lang.Object, jdbcType=BINARY, numericScale=null, resultMapId='null', jdbcTypeName='null', expression='null'}. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.apache.ibatis.type.TypeException: Error setting non null for parameter #8 with JdbcType BINARY . Try setting a different JdbcType for this parameter or a different configuration property. Cause: org.h2.jdbc.JdbcSQLDataException: Value too long for column "BINARY VARYING": "313d313b323d313b333d313b343d313b353d313b363d313b373d313b383d313b393d313b31303d31... (1361448)" [22001-210]

Versions:
SonarQube 9.4 from docker hub (docker run sonarqube:latest)
SonarScanner 4.7.0.2747-windows

The problematic file is a very large XML file (>160k lines, almost 10MB), and I have no need to include it but adding it to sonar.exclusions has had no effect. Sonarqube still tries to “visit” it despite the exclusion. I have even tried deleting the project and starting from scratch. Previous posts about the “Visit of component failed” error have suggested something corrupt in the database, but this is fresh from docker, so I wouldn’t expect any funny business there. (This will eventually go into a properly hosted enterprise edition, but I’m testing the project settings locally first).

If I “implicitly” exclude the file by instead setting sonar.sources to every folder in the repo except the one where that XML lives, the scan is successful. And of course if I delete it from the repo entirely, the scan is successful. Obviously, neither of these are good solutions.

Any thoughts how to get around this, given that excluding the file doesn’t seem to have worked?

#2

Hi,

Welcome to the community!

Normally I would dig into the DB error, but since it’s H2 (which is only provided for evaluation purposes) I think it’s more useful to get your exclusion working.

Could you share your analysis log?

 
Ann

#3

Is that just the ce.log?

ce.log (16.8 KB)

Some key items from the sonar scannar log: it is picking up *.xml as an excluded source (I also have tried it with the full file name)

14:45:59.257 INFO: Project configuration:
14:45:59.257 INFO:   Excluded sources: node_modules, *.xml
14:45:59.257 INFO:   Excluded sources for coverage: .

but the XML sensor still scans it:

14:46:14.603 INFO: Sensor XML Sensor [xml]
14:46:14.605 INFO: 1 source file to be analyzed
14:46:15.072 DEBUG: 'path/to/large.xml' generated metadata with charset 'windows-1252'
14:46:16.399 DEBUG: Count lines in file:///C:/<root>/path/to/large.xml
14:46:21.422 INFO: 1/1 source file has been analyzed
14:46:21.422 INFO: Sensor XML Sensor [xml] (done) | time=6819ms

and later on it spends about a minute printing blank INFO log lines as it seems to be analyzing the blame info:

14:40:57.678 INFO: SCM Publisher 1 source file to be analyzed
14:40:57.693 DEBUG: Blame file path/to/large.xml
14:41:07.679 INFO:
14:41:17.679 INFO:
14:41:27.680 INFO:
14:41:37.680 INFO:
14:41:47.680 INFO:
14:41:57.681 INFO:
14:41:59.080 INFO: SCM Publisher 1/1 source file have been analyzed (done) | time=61402ms
#4

Hi,

I’m looking not for the ce.log but for the you get when you fire the analysis command.

Those empty INFO lines are odd. Maybe pass in -Dsonar.log.level=DEBUG on the next analysis command line & give me that log so we can see more clearly what’s going on there?

 
Ann

#5

Here’s a complete debug log:

analysis.log (36.4 KB)

#6

Hi,

Thanks for the log. Here’s what I’m seeing (that’s interesting):

10:03:09.270 INFO:   Excluded sources: node_modules, *.key, *.xml
...
10:03:09.428 INFO: 0 files ignored because of inclusion/exclusion patterns

Your XML file isn’t being excluded (as you knew) because your pattern only excludes XML files in project root. Try updating the pattern to:

**/*.key, **/*.xml

The ** means 0-n directories. That will exclude XML files recursively.

 
Ann

#7

That’s annoying, I had suspected that, but actually the error had originally turned up when I was using an explicit path to the single file:

./src/projectxml/large.xml

But now I’m realizing that the scanner doesn’t recognize that path properly, but if I drop the leading ./ it works:

src/projectxml/large.xml

In almost any other context those two patterns are equivalent (given the same working directory), so this is surprising behaviour to me.

#8

Hi,

In fact, I’m a bit surprised that src/projectxml... would work. I guess you’ve set sonar.sources to . (or let it default to .) rather than to src?

 
Ann

#9

I’ve not set sonar.sources explicitly, so yes it is the default.
Same behaviour if I set sonar.sources=. explicitly.

#10

So then the pattern ./src... becomes ../src, right?

#11

No. The directory structure is:

xml-scan-test
|- sonar-project.properties
|- src
    |- projectxml
        |- large.xml

The scan is run from the root xml-scan-test. Relative to the root and the properties file, the path to any file in the src directory would start with ./src/. A pattern starting with ../src would take you out of the xml-scan-test directory entirely.