[
https://issues.apache.org/jira/browse/TINKERPOP-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122065#comment-18122065
]
ASF GitHub Bot commented on TINKERPOP-3283:
-------------------------------------------
Cole-Greer commented on PR #3688:
URL: https://github.com/apache/tinkerpop/pull/3688#issuecomment-5959545636
VOTE +1
> loops() quietly overflows
> -------------------------
>
> Key: TINKERPOP-3283
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3283
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.7.6, 3.8.1
> Reporter: Cole Greer
> Priority: Major
>
> The `loops()` step is ultimately backed by a `LabelledCounter`, which tracks
> the loop count as a `short`
> (https://github.com/apache/tinkerpop/blob/519a7be1576c6ccc7f028382c108f02933b1140b/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/util/LabelledCounter.java#L30).
> There is no overflow protection on this count, which can lead to some
> undesirable behaviours around the boundary of 32767 (short max):
> {code:java}
> gremlin> g.inject(0).repeat(loops()).emit().times(32767).count()
> ==>32767
> gremlin> g.inject(0).repeat(loops()).emit().times(32768).count()
> //hung, as the loop counter overflows before reaching 32768
> gremlin> g.inject(0).repeat(addV('TestNode').
> property(id, constant('TID-').concat(loops().asString())).
> property('rid', loops()).
> property('series','M').
> property('uuid', 'ab0ae056-5d59-48df-a582-92c7c1bb9fcc')).
> times(80000).iterate()
> Vertex with id already exists: TID-0
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> g.V()
> ==>v[TID--25318] // writes vertices with negative value ids after loops()
> overflows
> ==>v[TID--25319]
> ==>v[TID--15991]
> ==>v[TID--15992]
> ==>v[TID--15990]
> ==>v[TID--25310]
> {code}
> The silent overflow leads to really unintuitive results and should be
> considered a bug. This could be solved by adding some smart overflow
> detection (either resulting in a clear exception or expansion to a new
> long-counting traverser), or we could simply globally expand the counter to
> be a long, and suffer the impact from the increased memory consumption. These
> options should each be evaluated before implementing any fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
