panic: runtime error: invalid memory address or nil pointer dereference #705
Comments
|
It might be mine SELECT uast_extract(
uast(blob_content, 'csharp', "(//csharp:BinaryExpression_AddExpression/Left/uast:String | //csharp:InterpolatedStringExpression//csharp:InterpolatedStringTextToken[1])[starts-with(normalize-space(@Value), 'SELECT') or starts-with(normalize-space(@Value), 'select') or starts-with(normalize-space(@Value), 'UPDATE') or starts-with(normalize-space(@Value), 'update') or starts-with(normalize-space(@Value), 'DELETE') or starts-with(normalize-space(@Value), 'delete') or starts-with(normalize-space(@Value), 'INSERT') or starts-with(normalize-space(@Value), 'insert') or starts-with(normalize-space(@Value), 'CREATE') or starts-with(normalize-space(@Value), 'create') or starts-with(normalize-space(@Value), 'ALTER') or starts-with(normalize-space(@Value), 'alter') or starts-with(normalize-space(@Value), 'DROP') or starts-with(normalize-space(@Value), 'drop')]"),
'@pos') AS positions,
repository_id,
file_path
FROM (
SELECT f.repository_id,
f.file_path,
b.blob_content
FROM (
SELECT *
FROM refs r
NATURAL JOIN commit_blobs cb
NATURAL JOIN blobs
WHERE r.ref_name = 'HEAD'
AND NOT IS_BINARY(blob_content)
) b
INNER JOIN (
SELECT repository_id, file_path, blob_hash
FROM refs r
NATURAL JOIN commit_files cf
WHERE r.ref_name = 'HEAD'
) f
ON b.blob_hash = f.blob_hash
AND b.repository_id = f.repository_id
WHERE language(f.file_path, b.blob_content) = 'C#'
) t
WHERE positions IS NOT NULL |
|
Appears to be a race condition on go-git lru cache. |
|
It does not happen in v0.19.0-inmemjoin (and probably earlier versions), have we updated go-git since then? |
|
Other option can be that we are hitting more the cache walking commits using the history instead of the packfile. |
|
I've run go-git test (master): |
|
It seems that it's trying to insert in the cache an object bigger than the max size. This should not happen but it's the only explanation I have. @smacker can you check if there's a blob bigger than 512 Mb? |
|
Also, can yo do an fsck to the repositories? Some of them may contain a broken object that is causing this. |
|
@jfontan do you need it to be run on the version that panics or an older one that works? on |
|
Result of fsck (with removed names): |
|
Related issue: src-d/go-git#1071 |
|
I've not been able to reproduce the error with git objects. Adding objects with bogus data to the cache I could make it crash in the same place. Hopefully the check I've added is enough. |
|
It's not about data race (because LRU cache is thread-safe). last := c.ll.Back()
lastObj := last.Value.(plumbing.EncodedObject) <--- panic
lastSize := FileSize(lastObj.Size())in a meantime someone changed the reference of that object. |
|
@kuba-- yes, the test does just that. Change the size of one object in cache: o := NewObjectLRU(9 * Byte)
a1 := newObject(s.aObject.Hash().String(), 9*Byte)
a2 := newObject(s.aObject.Hash().String(), 1*Byte)
b := newObject(s.bObject.Hash().String(), 1*Byte)
o.Put(a1)
a1.SetSize(-5)
o.Put(a2)
o.Put(b) |
|
@ajnavarro Is this a regression since v0.18.0? |
|
@smola yes. |
gitbase v0.19.0-beta4
query:
Traceback:
The text was updated successfully, but these errors were encountered: