On Wed, Feb 8, 2017 at 9:24 AM Bill Somerville <[email protected]>
wrote:
> When the last process closes it should release and destroy the shared
> memory section, this can go wrong and leave a stale shared memory section
> hanging around.
>
I've noticed issues with wsjtx instances hanging around after I've closed
the window. Seems intermittent: I usually don't notice until I start wsjtx
again and it gives me an error telling me an instance is running, at which
point I have to send it a SIGKILL since it no longer has any windows. I'd
guess that's how the stale shmem was left around in the first place.
After rebuilding without my "fix" (where I just threw a random constant
into the shmem key in main.cpp) the waterfall is working again. I bet it
communicates through the shared memory? Whoops :)
Lastly, the band hopping "Schedule..." button doesn't seem to open any
> window when I click it. I had this problem with the previous build also,
> which I got from a PPA:
>
> This issue has been reported before, it is window manager limitation.
> Does your widow manager have a task bar or equivalent on the desktop, if so
> is there any indication there that the band hopping schedule window is open?
>
I'm using Awesome WM, and it has a list of windows at the top, but does not
show any new window when I click "Schedule..."
But interestingly, I made a debug build and ran it under gdb, and it
worked. Checked that I didn't have any local modifications and remade a
release build, and it stopped working again. Very odd. Is this possibly
related to the shared memory weirdness I've been seeing? I'll keep
investigating, and see if I can reproduce it in the debugger.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
