Ok, I've been able to reproduce this. I've filed https://issues.apache.org/jira/browse/ORC-569 .
.. Owen On Fri, Nov 8, 2019 at 1:30 PM Owen O'Malley <owen.omal...@gmail.com> wrote: > Andrew, > For bugs or feature requests, please file a jira: > http://orc.apache.org/jira > > If the positions list is empty, that is a bug. Can you describe how you > generated the ORC file? Which version of the software was used? > > Thanks, > Owen > > On Fri, Nov 8, 2019 at 11:59 AM Andrew S. <luvsha...@yahoo.com> wrote: > >> Hi, >> I'm starting to work with the ORC C++ API for a project I'm on. >> In a very basic test, I am seeing an assertion which I think is a bug. As >> I'm not sure where to report bugs (and also, as I'm just started looking at >> this API and maybe I'm misusing the API) I thought I'd post here. >> >> It is easy to reproduce: Take the Filecontents.cpp program which is the >> source for orc-contents example application and add the following code >> right before the while loop that calls rowReader->next(*batch): >> >> rowReader->seekToRow(1000); >> >> Then, using the example file TestOrcFile.testSeek.orc as input to >> orc-contents, this will crash with an assertion because of dereferencing an >> iterator that's pointing to end(). Using other example data files works >> fine in this case. >> >> Looking at PositionProvider::PositionProvider in InputStream.cc, it's >> assigning posns.begin() to the position variable. In this specific case for >> some of these assignments, the posns list is empty, and therefore the >> position variable ends up with an iterator that's pointing to end(). After >> that when it calls seekToRowGroup, it eventually gets to >> SeekableFileInputStream::seek() where it tries to call next() on that >> PositionProvider, tries to dereference the iterator and gives the assertion. >> >> I'm on Win10 using VC 2017. >> >> Any idea if this is a bug, or am I missing something? >> >>
