Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Query partitioning return false results #9942

Open
llooFlashooll opened this issue Mar 10, 2023 · 0 comments
Open

[BUG] Query partitioning return false results #9942

llooFlashooll opened this issue Mar 10, 2023 · 0 comments
Labels
Milestone

Comments

@llooFlashooll
Copy link

We discovered a bug that Query partitioning return false results.

  • OrientDB version: 3.2.14

  • Operating system: macOS 13.2.1

  • API/Driver: Java

  • Expected behavior:
    We construct the following scenario: we split a given query Q into three derived sub-queries, in which the predicate is evaluated to TRUE, FALSE, and IS NULL, respectively. The union of the three derived result sets should be equal to the result set of query Q.
    We generate graph schema and data based on random strings and values. Here is one of our examples that triggered the bug.

  1. g.V().has('vp0',0.3792261648797388).count() returns 0
  2. g.V().has('vp0',0.3792261648797388).has('vp0', outside(0.8780335669045662,0.18019845106122412)).count() returns 1
  3. g.V().has('vp0',0.3792261648797388).has('vp0', not(outside(0.8780335669045662,0.18019845106122412))).count() returns 0
  4. g.V().has('vp0',0.3792261648797388).hasNot('vp0').count() returns 0
    We can see that sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0
  • Actual behavior:
    The sum of sub-queries 2, 3, 4 results: 1 + 0 + 0 != 0

  • Steps to reproduce:
    We are developing a fuzzing technique to test your GraphDB. We create a graph with 10 nodes and 20 edges. And try to make it clear to reproduce the bugs, hope to not cause much inconvenience to your reviewing, but we believe the problem does exist.
    Following the following graph data generation query, we can reproduce the bugs:

  • Create schema

Vertex:
g.addV('vl1').property('vp4','true').property(T.id,#279:220)
g.addV('vl0').property('vp1','0.8462989406043159').property(T.id,#253:256)
g.addV('vl0').property('vp0','0.8462989406043159').property(T.id,#254:254)
g.addV('vl2').property('vp0','0.8462989406043159').property(T.id,#240:136)
g.addV('vl1').property('vp1','0.010441589333040624').property('vp3','-3726525007738557113').property('vp2','-940269383540698765').property(T.id,#280:217)
g.addV('vl0').property('vp0','0.8462989406043159').property(T.id,#255:253)
g.addV('vl1').property('vp4','true').property(T.id,#281:215)
g.addV('vl0').property('vp2','1434644853551499038').property(T.id,#256:251)
g.addV('vl1').property('vp2','4790214198589554588').property(T.id,#274:224)
g.addV('vl2').property('vp0','0.3792261648797388').property(T.id,#241:135)

Edge:
g.V(#240:136).as('#240:136').V(#256:251).as('#256:251').addE('el0').from('#240:136').to('#256:251')
g.V(#240:136).as('#240:136').V(#253:256).as('#253:256').addE('el0').from('#240:136').to('#253:256')
g.V(#240:136).as('#240:136').V(#240:136).as('#240:136').addE('el2').from('#240:136').to('#240:136')
g.V(#240:136).as('#240:136').V(#255:253).as('#255:253').addE('el0').from('#240:136').to('#255:253')
g.V(#256:251).as('#256:251').V(#274:224).as('#274:224').addE('el1').from('#256:251').to('#274:224')
g.V(#241:135).as('#241:135').V(#254:254).as('#254:254').addE('el0').from('#241:135').to('#254:254')
g.V(#255:253).as('#255:253').V(#279:220).as('#279:220').addE('el1').from('#255:253').to('#279:220')
g.V(#240:136).as('#240:136').V(#241:135).as('#241:135').addE('el2').from('#240:136').to('#241:135')
g.V(#240:136).as('#240:136').V(#254:254).as('#254:254').addE('el0').from('#240:136').to('#254:254')
g.V(#256:251).as('#256:251').V(#279:220).as('#279:220').addE('el1').from('#256:251').to('#279:220')
g.V(#241:135).as('#241:135').V(#240:136).as('#240:136').addE('el2').from('#241:135').to('#240:136')
g.V(#254:254).as('#254:254').V(#281:215).as('#281:215').addE('el1').from('#254:254').to('#281:215')
g.V(#256:251).as('#256:251').V(#280:217).as('#280:217').addE('el1').from('#256:251').to('#280:217')
g.V(#241:135).as('#241:135').V(#253:256).as('#253:256').addE('el0').from('#241:135').to('#253:256')
g.V(#241:135).as('#241:135').V(#255:253).as('#255:253').addE('el0').from('#241:135').to('#255:253')
g.V(#254:254).as('#254:254').V(#280:217).as('#280:217').addE('el1').from('#254:254').to('#280:217')
g.V(#254:254).as('#254:254').V(#279:220).as('#279:220').addE('el1').from('#254:254').to('#279:220')
g.V(#255:253).as('#255:253').V(#280:217).as('#280:217').addE('el1').from('#255:253').to('#280:217')
g.V(#256:251).as('#256:251').V(#281:215).as('#281:215').addE('el1').from('#256:251').to('#281:215')
g.V(#241:135).as('#241:135').V(#241:135).as('#241:135').addE('el2').from('#241:135').to('#241:135')
@tglman tglman added the bug label Mar 14, 2023
@tglman tglman added this to the 3.2.x milestone Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants