Hi, Andreas,
Here is a quick update of what we are able to find out so far.
The 11 errors reported by helgrind are of two different types: one is
about the order of lockers and the other is about unclocking
not-locked locks. The first type can be easily addressed and the
information from helgrind is quite helpful, which makes our job pretty
easy. However, the second type of error is going to take some effort
to figure out. We have heavily instrumented the function calls
involving the particular lock, but so far there is no indication why
helgrind deem it to be faulty. We will let you know as soon as we
find out something more. In the mean time if anyone has some
suggestions for us, please feel free to let us know.
Thanks.
John
On 9/20/2010 6:20 AM, Andreas Streichardt wrote:
> Hi,
>
> as seen in Jans mail we are analyzing fastbits memory usage a bit more in
> depth.
>
> We have a case where we first select a complete partition into memory and then
> conduct several subselects on it.
>
> It seems there are some locking bugs somewhere inside fastbit which result in
> a locked filemanager::clear().
>
> Simplified testcase attached including helgrind logs:
>
> somedata.log:
> x.cc:
>
> in_memory_select=tab->select("a,b,c","c IN (1)");
>
> alldata.log:
> x.cc:
>
> in_memory_select=tab->select("a,b,c","c IN (1,2)");
>
> (will select all rows).
>
> As you can see in alldata.log there are multiple locking errors and the
> "fileManager::clear -- completed with xx" message is completely missing. When
> increasing fastbits loglevel you will see that it is locked (as indicated by
> helgrind).
>
> Any idea what is happening there?
>
> Kind regards,
>
> Andreas Streichardt
>
>
>
> _______________________________________________
> 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
