This bug is an escalate of Bug 4251 To reproduce, follow the same steps, without the "sleep" argument to the script: Steps to reproduce: 1. wget http://sourceware.org/systemtap/examples/profiling/sched_switch.stp 2. fill in system tap dialog (metadata, login, path to script) ### 3. add ' -c "sleep 1" ' in the arguments field ### 4. launch the script The scripts behave fine when manually run using the crosstap script. We need to find a way to continuously stream the data printed by the script in the Eclipse console.
Hi Adrian, If the host, e.g. 192.168.7.4 is not present in ~/.ssh/known_hosts I found that a hang is due to that I am asked to add the host to the known_hosts. But this appears in the console from which I started eclipse, not a popup or something else. If this is the hang, I won't file a bug for that. If I type Yes then the eclipse continues and gets me the following output which does nothing: ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' /mnt/big/0411-3/poky-systemtap/build /mnt/big/0411-3/poky-systemtap/build /mnt/big/0411-3/poky-systemtap/build bug this is covered in https://bugzilla.yoctoproject.org/show_bug.cgi?id=3672 As for your script. I have the following errors in my output - covered in https://bugzilla.yoctoproject.org/show_bug.cgi?id=4099: [yocto@localhost build]$ crosstap root@192.168.7.4 sched_switch.stp -c "sleep 1" /mnt/big/0411-3/poky-systemtap/build /mnt/big/0411-3/poky-systemtap/build /mnt/big/0411-3/poky-systemtap/build semantic error: not accessible at this address [man error::dwarf] (0xffffffff81070020, dieoffset: 0x88850b): identifier '$p' at /mnt/big/0411-3/poky-systemtap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/tapset/linux/scheduler.stp:257:9 source: task = $p ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff81070020, dieoffset: 0x88850b): identifier '$p' at :258:13 source: task_pid = $p->tgid ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff8169fb86, dieoffset: 0x8809e0): identifier '$prev' at :144:19 source: prev_priority = $prev->prio ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff8169fb86, dieoffset: 0x8809e0): identifier '$prev' at :145:14 source: prev_pid = $prev->tgid ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff8169fb86, dieoffset: 0x8809e0): identifier '$prev' at :147:15 source: prev_task = $prev ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff8169fb86, dieoffset: 0x8809e0): identifier '$prev' at :148:34 source: prev_task_name = task_execname($prev) ^ semantic error: not accessible at this address [man error::dwarf] (0xffffffff8169fb86, dieoffset: 0x8809e0): identifier '$prev' at :149:19 source: prevtsk_state = $prev->state ^ semantic error: unable to find local 'new', [man error::dwarf] dieoffset 0x8809bf in kernel, near pc 0xffffffff8169fb86 in context_switch /mnt/big/0411-3/poky-systemtap/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.8.4+gitAUTOINC+27b63fdbd25ad1a37bacc05f49a205c150d21779_11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc-r4.0/linux/kernel/sched/core.c (alternatives: $next $prev): identifier '$new' at :169:19 source: next_priority = $new->prio ^ semantic error: unable to find local 'new', [man error::dwarf] dieoffset 0x8809bf in kernel, near pc 0xffffffff8169fb86 in context_switch /mnt/big/0411-3/poky-systemtap/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.8.4+gitAUTOINC+27b63fdbd25ad1a37bacc05f49a205c150d21779_11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc-r4.0/linux/kernel/sched/core.c (alternatives: $next $prev): identifier '$new' at :170:14 source: next_pid = $new->tgid ^ semantic error: unable to find local 'new', [man error::dwarf] dieoffset 0x8809bf in kernel, near pc 0xffffffff8169fb86 in context_switch /mnt/big/0411-3/poky-systemtap/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.8.4+gitAUTOINC+27b63fdbd25ad1a37bacc05f49a205c150d21779_11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc-r4.0/linux/kernel/sched/core.c (alternatives: $next $prev): identifier '$new' at :173:34 source: next_task_name = task_execname($new) ^ semantic error: unable to find local 'new', [man error::dwarf] dieoffset 0x8809bf in kernel, near pc 0xffffffff8169fb86 in context_switch /mnt/big/0411-3/poky-systemtap/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.8.4+gitAUTOINC+27b63fdbd25ad1a37bacc05f49a205c150d21779_11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc-r4.0/linux/kernel/sched/core.c (alternatives: $next $prev): identifier '$new' at :174:19 source: nexttsk_state = $new->state ^ Pass 2: analysis failed. [man error::pass2] [yocto@localhost build]$
Hi Alex, I am aware of the known hosts issue as well. We should file a separate bug report for that. You could try verifying the script against an architecture other than x86. This bug is architecture independent, so you should get it on any target that actually runs the script. --Adrian
filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=4307 regarding the known_hosts issue
Hi, I took at look at the issue, and I seem to obtain the error Alex described, but this fails to be displayed on the console, or as a Error dialog due to some waiting mechanisms. When ran from debug mode, if I wait for the error stream to be available, everything works as intended. I will send a patch for this asap.
http://git.yoctoproject.org/cgit/cgit.cgi/eclipse-poky/commit/?h=dylan&id=3d452fc10baf53e94c843a2b5bcd0d2b0ff7e4a3
Hi, The original problem still persists. The commit fixes something else. Here we are talking about a script that is running correctly from the command line, but makes Eclipse hang when run from the plugin: Steps to reproduce: 1. wget http://sourceware.org/systemtap/examples/profiling/sched_switch.stp 2. fill in system tap dialog (metadata, login, path to script) 3. launch the script (without any argument) I suggest you try this on a different target than intel/qemux86, to avoid getting the error messages Alex reported. I ran this on qemuarm as well as a pandaboard real target and had the same behaviour: From command line, the script continuously streamed/printed information in the terminal until it was stopped (Ctrl-C). When run from Eclipse, it just sends Eclipse in a non-responding state.
git commit id: 0006f3194e0050bb69887cece970df7a820b8c30
The commit only partially fixes the issue. Now output is continuously printed in the console window, but we have no way of stopping the script. Pressing Cancel on the Progress Information window doesn't work, and we end up with an unusable Eclipse. Moreover, even if we restart Eclipse, we need to reset the target as well, as the corresponding kernel module gets loaded in the kernel but can't be removed anymore, making it impossible to run the same stap script again.
Hi Adrian, If you run the script from the command line and stop it, how do you perform the kernel module unloading so that the script can run again successfully?
hi Ioana, When you stop the crosstap script (ctrl-c) this stops the stap command running on the remote target, resulting in the module being removed. When Eclipse becomes unresponsive, and you kill it, sometimes (but not always) the script stays running in the background leading to the kernel module being still loaded. I think what we need to do is have the Cancel button in the progress window stop the underlying crosstap script. This should take care of both problems. I'm not sure of how feasible this is implementation-wise, as I'm not a java expert. Best regards, --Adrian
Hi Adrian, The problem that you are seeing is may have two causes: - either the Cancel button's action is not overriden and does nothing - or it fails to kill the underlying process Either way, this is a separate issue that the original one for this bug. Therefore, I will mark this bug as RESOLVED FIXED, and will open a new one for this issue and will investigate it further. Thanks, Ioana
Verified with eclipse Kepler, on master branch commit 2d1660112e54653f7bb763939d0416472c49fe01 Host Ubuntu 14.04 x86_64 Cheers! Andra N.