Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Possible issue with symbols proxy 
Hi Eugene,
I don't see other problems than this too aggressive symbol flush. But as found it strange, I was thinking of a bug. I agree that the data will be requested the next time. 

Do you want me to create a bugzilla for an enhancement request?

Thanks for the quick reply.

Benoit

On 04/08/2014 9:16 PM, Eugene Tarassov wrote:

Hi Benoit,

Flushing symbol info in this case might be suboptimal - too aggressive, but should not cause problems. The info should be re-requested when the cache item is notified. Do you see any problems beside suboptimal behavior?

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Benoit Perrin
Sent: Tuesday, April 08, 2014 4:15 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [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
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev



--
Benoit Perrin, Senior Member of Technical Staff, Wind River
direct +33 297.427.375

Back to the top