On Wed, Jul 10, 2019 at 10:28:15PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > I *think* I can now recreate the crash on demand.
Excellent! My prayers that you'd get more crashes have been answere... ... that came out wrong... This is interesting: > pri= 8 (+0) win 0x1000003:'aumix' > basepri=8 > pri=14 (+6) win 0x1c0037a:'xine: ' > basepri=8 _FULLSCREEN > pri= 8 (+0) win 0x140000d:'xterm' > basepri=8 > pri= 8 (+0) win 0x120000d:'xterm' > basepri=8 > pri=14 (+6) win 0x1c00301:'xine Panel' > basepri=8 _FULLSCREEN > transient for 0x1c0037a:xine: In all the cases I've managed to pull it off, it's been because the window was up where it should be, and the transient was still in the middle of the list where it blew things up. You've got the _transient_ moved to the top, and the main window left in the old location. I tried moving focus to the transient instead in my testing, but didn't manage to provoke a crash. Of course, now that I've read _you_ doing it, it'll probably start happening deterministically for me the next time I try... I think that'll be straightforward to fix. I thought a little about the focus moving to the transient when I wrote the patches, and figured it would probably work out less than optimally but would be correct, and slotted it as a cosmetic issue to resolve later. But maybe it _is_ correctness-impaired, and we need to cover that. I have a pretty good idea how to pull it off; with a little luck I can come up with a new try tonite. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
