PothosFlow
PothosFlow copied to clipboard
pothosware
Pothos not cleaning up procs and subprocs.
From @romeojulietthotel on April 14, 2017 18:46
Just discovered that there were four PothosUtil and two PothosGui procs running even though I had exited PothosGui. Two of the PothosUtil procs were marked <defunct>.
This causes lots of problems if it's not known to the user that there are still procs running (well I don't know what they were doing). If I see this again I will try to gather some more info. This is all I have now.
All built from tag pothos-0.4.2 on Linux.
Copied from original issue: pothosware/pothos#116
From @romeojulietthotel on April 16, 2017 20:40
I need to test this but something I just thought of....maybe this problem occurs because I launch pothos from a .sh script and the script uses the full path to launch the gui i.e. /path/to/pothos/bin/PathosGui
From @romeojulietthotel on April 19, 2017 14:25
If there's no device connected and pothos has a few topologies to load and then I exit it seems to show this problem.
The PothosGui began consuming memory as well and I eventually killed the procs.
From @romeojulietthotel on April 19, 2017 14:33
Not sure if this is a feature but I notice that if pothos starts and I have a few topologies saved that pothos looks at them and does "stuff". Sometimes looping over them like in a race condition.
Pothos seems to step on itself, i.e. one thread can access the hardware and another cannot for example.
@romeojulietthotel thanks for reporting
I think you have stumbled on two issues. I think there is some kind of race or cleanup issue in the GUI but I'm not sure as to the reason. I think I have seen it happen even when a tab is closed, so its not strictly the GUI shutting down. Its somewhat random, but something locks up when shutting down, maybe memory is being stepped on. I have had a hard time tracking down precisely the issue.
Pothos seems to step on itself, i.e. one thread can access the hardware and another cannot for example.
Thats true, the process has one handle open to a particular device, it cant be used in another process. This could lead to one open design claiming a device that another might use. A quick fix might involve disabling the block when not using it (short cut is "d"). But automatically not maintaining active blocks in the memory for tabs that are not selected/in-focus may be a possible solution.
From @romeojulietthotel on April 20, 2017 15:3
It seems to me that hardware access may be at the root of these problems. I have found that some apps take and want exclusive control of hardware, usb or audio are the ones I see having contention issues. Have also seen some apps are able to share audio. USB sharing seems to be more complicated. IIRC usb sharing is possible but maybe harder to implement and I don't know if (for Linux) it's a kernel driver issue or usb chipset issue or both.
I will disable all but one block as you suggest. Maybe they should all be disabled on startup but perhaps there's a good reason for parsing them and querying hardware that I am missing. I guess I am used to a GUI app starting and waiting for user input before doing work.
From @romeojulietthotel on April 20, 2017 18:27
Disabling is fine but if I have three tabs, to disable I have to switch to each tab->Select all->disable. Maybe this is nitpicking. I am conditioned to have the app start and do nothing until I activate it. For example Gqrx, URH, Gnuradio, etc.
Did not know that issues could not be moved between projects. Sorry to have made extra work for you. I'm not certain but I think I won't see updates here either since I didn't "open" this now it's moved.
No worries, I was just doing some cleanup for issues. I used this: https://github-issue-mover.appspot.com/ Its basically just making a new issue and replaying the comments. I'm not sure if it subscribes the original participants or not. But you are probably subscribed now because of the new comment.
I've created a completey new environment and rebuilt everything and I no longer see these issues of procs and subprocs running after exiting the application.
I will file separate issue for some audio contention that I'm seeing.
This issue is happening on Win 7 sp1 X64 with PothosSDR-2017.09.10.
Try and quit PothosGUI and the screen clears but the PothosGUI.exe and 2 PothosUtil.exe process are left running on the system.
Jim
Using the currently latest version Pothos-v0.7.0-PothosSDR-2019.06.09-vc14-x64 On Windows 7 Ultimate SP1 x64 running AMD FX-9590 (8 core) CPU.
While trying to find out why using an hackRF with Soapy SDR Source end in crashes, It seems that this issue only occurs when adding the Soapy block. To exclude hackrf driver issues i connected an unconfigured block to an Black Hole. After a while the program crashes with unknown course. When closing, the 3 processes remain and have to be stopped manually.
When adding for example a waveform generator connected to an "black Hole", everything went fine.
Imre
