[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[tcf-dev] Possible issue with symbols proxy
|
Hi,
I think that I found an issue with the symbols proxy (C code), but as I am not
sure to understand completely the code, I prefer to send an email first than to
create a bugzilla.
My system has three contexts:
P2 (process, symbol context)
|_ P2.1 (thread)
|_ P2.2 (thread)
The code searches a symbol by address, and between the command sent and the
reply received, a runcontrol context is removed.
<--- C 129 Symbols findByAddr "P2.1" 1628750159
<--- E None RunControl contextRemoved ["P2.2"]
---> R 129 None "@S3.73.BA634B.533E91BA.13CC.0.0.-1.0.0.0.P2"
From the symbols proxy code:
find_symbol_by_addr() links the associated pending cache to the 'flush_rc'
linked list, with an update_policy set to UPDATE_ON_EXE_STATE_CHANGES.
When the context P2.2 is removed, the listener event_context_exited() is called.
In that case, cached data associated with the context P2.2 for all policies
would be flushed ("flush_syms(ctx, ~0)").
The core routine to check if a cached data has to be flushed is check_policy(),
which in the example will return '1' (mode is 0xffffffff, P2.1 and P2.2 share
the same symbol context group P2). I don't think this is correct, as the cache
is associated with P2.1 and not P2.2, so it should not be flushed.
Moreover, the routine free_find_sym_cache() checks (asserts) that the data
cached to be flushed is not a pending data.
I am wondering if the check_policy() code is correct. Should it be instead:
static int check_policy(Context * ctx, int mode, Context * sym_grp, Context *
sym_ctx, int policy) {
if ((mode & (1 << policy)) && sym_ctx == ctx) return 1;
if (mode & (1 << UPDATE_ON_MEMORY_MAP_CHANGES)) {
- if (context_get_group(sym_ctx, CONTEXT_GROUP_SYMBOLS) == sym_grp) return 1;
+ if (context_get_group(sym_ctx, CONTEXT_GROUP_SYMBOLS) == ctx) return 1;
}
return 0;
}
Regards,
Benoit
--
Benoit Perrin, Senior Member of Technical Staff, Wind River
direct +33 297.427.375