JInspector improvements

[faustus123]

Ran into several issues trying to use the built-in JInspector tool from gdb. These were done using the JTest plugin that comes with JANA2. I tried ran it like this:

gdb --args jana -Pplugins=JTest -Pjana:timeout=600 -Pnthreads=1
(gdb) break JTestTracker::Process
Function "JTestTracker::Process" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (JTestTracker::Process) pending.
(gdb) run

1. If debug symbols are not present, then aEvent is optimized out. The real issue here is whether debug symbols should be included in the default JTest plugin and any plugins created with jana-generate.py. At least for JTest, having them there by default avoids having to document in the tutorial how to re-build JANA with them in the section on running with gdb.

2. Even with debug symbols turned on, the JEvent::Inspect() method is inlined so gdb can't call it.

3. Calling aEvent->mInspector.Loop() directly works, but not quite. The initial call to PrintEvent() seems to work before entering the loop and the "JANA:" prompt is printed. Then it seems to revert to printing the ticker line while not responding to any commands. Some temporary print statements seem to indicate it is stalling on the "std::getline(m_in, user_input)" call. Why that frees up the heartbeat thread is unclear. Why it does not accept a command after typing and hitting return is also unclear.

[nathanwbrei]

1. Running gdb on a program without debug symbols is an exercise in frustration. Also, CMake doesn't like it when you override the debug symbols and optimization level for an individual target. There's a CMake flag to compile the whole project as either "Debug", "Release", or "RelWithDebInfo". 2. I wonder if there is a way to force the compiler to not inline JEvent::Inspect(). I hope so. 3. When using the Inspector I always turned off the heartbeat and the ticker (note these are separate things) Nathan

…

________________________________ From: David Lawrence ***@***.***> Sent: Friday, June 24, 2022 3:23 PM To: JeffersonLab/JANA2 ***@***.***> Cc: Subscribed ***@***.***> Subject: [EXTERNAL] [JeffersonLab/JANA2] JInspector (Issue #112) Ran into several issues trying to use the built-in JInspector tool from gdb. These were done using the JTest plugin that comes with JANA2. I tried ran it like this: gdb --args jana -Pplugins=JTest -Pjana:timeout=600 -Pnthreads=1 (gdb) break JTestTracker::Process Function "JTestTracker::Process" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (JTestTracker::Process) pending. (gdb) run 1. If debug symbols are not present, then aEvent is optimized out. The real issue here is whether debug symbols should be included in the default JTest plugin and any plugins created with jana-generate.py. At least for JTest, having them there by default avoids having to document in the tutorial how to re-build JANA with them in the section on running with gdb. 2. Even with debug symbols turned on, the JEvent::Inspect() method is inlined so gdb can't call it. 3. Calling aEvent->mInspector.Loop() directly works, but not quite. The initial call to PrintEvent() seems to work before entering the loop and the "JANA:" prompt is printed. Then it seems to revert to printing the ticker line while not responding to any commands. Some temporary print statements seem to indicate it is stalling on the "std::getline(m_in, user_input)" call. Why that frees up the heartbeat thread is unclear. Why it does not accept a command after typing and hitting return is also unclear. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_JANA2_issues_112&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=zkOjmyxOjaybvirsgX3fR2-3ovs5Qvp--DHtSiBhcckII8_X3JQS9_hVwzgCBBvz&s=FfZFJkqt92BOgkgB8GdU_J7eNjedo_HcYR1QBROa9VE&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAOMGEGV2HNRWPF6OYA36MLVQYDKTANCNFSM5ZYYSDZQ&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=zkOjmyxOjaybvirsgX3fR2-3ovs5Qvp--DHtSiBhcckII8_X3JQS9_hVwzgCBBvz&s=-XpOLVK3AlsKPPdJZDteXWVqBYe2MB5KQG4xtML26p8&e=>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[faustus123]

For 3. I think the problem isn't really the ticker lines (though we should probably disable them while in the inspector loop). This real issue is that it is not accepting commands. What I expect to see is the command and its output interspersed with the ticker lines. I see no indication it ever returns from the getline call.

[faustus123]

I take that back. It does seem to be responding to the commands. Somehow fooled myself before.

[nathanwbrei]

You might not have been hallucinating. I have a healthy fear of doing I/O from multiple threads concurrently when they themselves call sleep() and there's both an OS scheduler and JANA scheduler to worry about. I know there's a right way to do it but I'm fuzzy on what the right way is. On top of that, TTYs are weird in their own right, and within gdb makes them even weirder. It's possible a thread woke up wrong and somebody didn't give it its tty back.

…

________________________________ From: David Lawrence ***@***.***> Sent: Friday, June 24, 2022 3:35 PM To: JeffersonLab/JANA2 ***@***.***> Cc: Nathan Brei ***@***.***>; Comment ***@***.***> Subject: [EXTERNAL] Re: [JeffersonLab/JANA2] JInspector (Issue #112) I take that back. It does seem to be responding to the commands. Somehow fooled myself before. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_JANA2_issues_112-23issuecomment-2D1165878064&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=vuBNGIdsElZdulm18u0_xgiI8muv6nktbFEhDfQVtp1kPgGbW82ZJ80wWEyA_dvl&s=mtufDz6hWDcDfX2JdCq5fEPHfJb8QWj7riDDUwEZKX4&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAOMGEFFYON7WTKCCB3FUQLVQYEYFANCNFSM5ZYYSDZQ&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=vuBNGIdsElZdulm18u0_xgiI8muv6nktbFEhDfQVtp1kPgGbW82ZJ80wWEyA_dvl&s=TQ55aYaPIY5515L4I37MpACM3oEOLyqJcG07eApXmXc&e=>. You are receiving this because you commented.Message ID: ***@***.***>

[faustus123]

OK. I think there was some operator error before. I seem to have it working now. At least if I call aEvent->mInspector.Loop(). I have modified the Loop routine to turn off both the timeout check and ticker before entering the loop and to turn them back on when leaving. It is not ideal since they should really be returned to whatever state they were in when entering the method. JApplication though does not give access to this info at the moment.

[nathanwbrei]

That's a good idea, we should add that.

…

________________________________ From: David Lawrence ***@***.***> Sent: Friday, June 24, 2022 3:57 PM To: JeffersonLab/JANA2 ***@***.***> Cc: Nathan Brei ***@***.***>; Comment ***@***.***> Subject: [EXTERNAL] Re: [JeffersonLab/JANA2] JInspector (Issue #112) OK. I think there was some operator error before. I seem to have it working now. At least if I call aEvent->mInspector.Loop(). I have modified the Loop routine to turn off both the timeout check and ticker before entering the loop and to turn them back on when leaving. It is not ideal since they should really be returned to whatever state they were in when entering the method. JApplication though does not give access to this info at the moment. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_JANA2_issues_112-23issuecomment-2D1165892564&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=72C_tgjQHAxnz0vhc1foyaI-bphzUmtQcuBYubynzVlr6O_JkCJURPtYpgIPxTU0&s=G-f4ddIuts_lti2O7fKDDxQON3gBEmeBEucBPWKcDsE&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAOMGEHH5ECXU7MKQTUKNSLVQYHLXANCNFSM5ZYYSDZQ&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=xQdTvKDXrDUKgnAFkboV1w&m=72C_tgjQHAxnz0vhc1foyaI-bphzUmtQcuBYubynzVlr6O_JkCJURPtYpgIPxTU0&s=mMBGVq5etyUeJpBhfW7cQZR2iYX04H-D_R5qsj_YzsQ&e=>. You are receiving this because you commented.Message ID: ***@***.***>

[nathanwbrei]

Did we decide we needed to do something to prevent JEvent::Inspect from being optimized out?

[faustus123]

Yes, if it is fairly easy (e.g. #pragma). If not, then we should make it clearer, at least in embedded documentation in the code, how to use it if it has been optimized out.