Hi, Bernd,
Thanks for the report and detailed explanation of issue. I am
adopting a minimalist change right now, to remove the comparison
invovling aggr_[j]. This should fix the problem with invalid read
accesses.
Regarding the issue of not showing duplicate variables in the select
clause, I would treat it as a silly crook of FastBit code for the moment.
Thanks again.
John
PS: The updated code is checked into the SVN repository as revision
719 if you have the time to try it out.
On 4/25/14, 2:59 AM, Bernd Jaenichen wrote:
> Hi,
>
> i found a possible bug in selectClause.cpp of version 1.3.9 when using
> a select-statement with
> duplicate column names i.e. "v_1,v_1,v_2".
>
> I know this is not a valid use-case for a select clause but it may
> lead to
> a segfault so i dug into it.
>
> Explaining the problem is somewhat tricky so i attached a simple testcase
> that shows the issue with verbosity set to 5:
>
> selectClause::fillNames -- select clause internal details:
> low-level expressions (names_[2], aggr_[2], atms_[2]):
> 0: v_1, v_1
> 1: v_2, v_2
> high-level expressions (xnames_[3], xtms_[3]):
> 0: v_1, v_1
> 1: v_1, v_1
> 2: _2, v_2
>
>
> As you can see the size of internal terms-vectors in selectClause.cpp
> differs
> between high- and low-level expressions.
>
> In method ibis::selectClause::fillNames() a loop iterates over xtms_
> vector
> and accesses aggr_ in line 197:
>
> // fill the external names
> for (uint32_t j = 0; j < xtms_.size(); ++ j) {
> if (xnames_[j].empty() && aggr_[j] == ibis::selectClause::NIL_AGGR &&
>
> The test against "aggr_[j] == ibis::selectClause::NIL_AGGR" will
> result in an access out of range
> in the last iteration of the for-loop due to different sizes of aggr_
> and xtms_.
>
> On initial load out of range access at aggr_[j] will access
> null-initialized heap and so the test will
> result in true and bug will not appear but a segfault may be possible.
>
> If memory outside aggr_ allocation is dirty and contains -1 test will
> result in false and leads to
> renaming of the last column in select from "v_2" into "_2".
>
> If the result of that query is stored within in-memory table by
> ibis::table::select() any subsequent
> access to column "v_2" will fail (that's how i came accross the issue).
>
> To fix this i patched selectClause.cpp a bit to avoid duplicate
> columns wihtin high-level expressions.
> (patch is attached also)
>
> But i'm not sure whether that's the correct place to fix it nor if it
> is conceptually correct
> to remove duplicate columns from the select-clause.
>
> Could you verify the bug and if so fix it please?
>
>
> Thanks alot,
> Bernd
>
>
>
>
>
> _______________________________________________
> FastBit-users mailing list
> [email protected]
> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
>
_______________________________________________
FastBit-users mailing list
[email protected]
https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
