I'm not using Xlib directly. Who does, these days? Barbarella uses gtk2 for its widget set.
Sounds reasonable!
Actually that's how I do it. The command is stored in a buffer, parsed to create an array of arguments, and then passed to execvp.
It would be useful to know about that, but as I am using a higher level widget set, I don't actually know whether the mouse is being grabbed or not. All I know is that the gtk_button widget picks up a gdk click event and emits a "clicked" signal, which my program responds to. I suppose I could look at the gtk2 source, but I doubt if I would understand much. My knowledge of C is pretty elementary.
Wow, that's useful! Far easier than writing a program to do it.
That's also good advice. Presumably, if they are closed, they won't be open in any of the launched programs either. istr that file descriptors survive fork/exec, although streams don't.
I'm using startx, but I could put that bit of code in if I understood it! "exec <&-" What precisely does that do? And what's a SAK event?

PS: Maybe one of the mods could move this thread to programming. I think it would be more useful there.

exec <&- is a redirection that closes stdin.

SAK is the "secure attention key". It's a magic-sysrq kernel sequence that kills everything on the tty it's entered on. altgr-sysreq k
Don't run it on tty1 on Slackware as it'll kill most of the daemons that rc.S/M start. It's fine to use on the other ttys and can sometimes unlock a locked up X environment.

I started work on making tty1 SAK proof which is why I created this rc.4.local, but there's so much system stuff left attached to tty1 in one form or another on slackware that it became not worth the effort. Especially as I follow the current branch which means my changes get overwritten frequently.


I like playing with Xlib, and Motif and other old toolkits. GTK seems to be a constantly moving target, Qt is C++ and I'm a C kind of guy, so neither of those really appeal to me.

Appendix: I've just done an ls -l fd on one of my barbarellas (there are four instances altogether because I have a different selection of programs on each desktop) and it gives me
So input has been closed (not by me! gtk must have done it) and both outputs go to tty1. The socket connection I assume to be to X. I have no idea what the other one is.

Does that mean that any programs launched by barbarella will try to take their input from /dev/null?

Yes, that's what I'd expect, so I wouldn't expect a normal program to block on a read of it. But then vim/view is a ncurses tty program and is probably getting up to all manner of shenanigans, so who knows.

again, you can use (for example) pstree to check which process started which one. Also you can check the same way the fd of any other processes (like view), so just start it again and check. I'm really interested.

OK, Pan, so here's what happens. I use barbarella to launch view and most of X goes dead. But not quite all of it. For example, I can move my mouse but not click it. I can use the keyboard to change consoles but not to write.

I went to console 2, logged in, and did a ps. I found that all the graphical stuff including the barbarellas was in state "T". And so was view. I'm not sure what that state is, but you can't kill them with a SIGTERM. You have to use SIGKILL (kill -9) and then those processes become zombies.

I checked the file descriptors for view and it just had the three standard channels, all going to /dev/tty1, which is odd when you consider that barbarella, the parent of view, has stdin set to /dev/null and not /dev/tty1.

I killed view to see if that cleared the block. It didn't. I killed the barbarellas with killall -9. Still blocked. I killed fluxbox and X went down, which cleared everything.

Any explanations?

PS: I find that state T means stopped. Just like a background job gets stopped when it tries to use the console. And I bet that's because the console belongs to X.

This quick test seems to suggest that view is using stderr to find its terminal, or at least it errors out with exit 1 when it can't access stderr. The second example has to be killed.



Quick trace shows this:
It looks like vim tries to dup() stderr if it can't use stdin. As I mentioned earlier, Shenanigans!

Still doesn't explain why your X input is getting locked out, or the stopped processes.

did you try pstree? Do you know what is the parent of that view process?
I told you already view inherited stdin/out from X, not from barbarella or any other process.

Here's the relevant part of pstree. You can see that programs launched by barbarella are children of barbarella and grandchildren of fluxbox.

|-bash---startx---xinit-+-Xorg
| `-fluxbox-+-barbarella---xterm---bash---pstree
| |-barbarella---claws-mail
| |-3*[barbarella]
| `-fbsetbg

This is just a hunch, but try including a setpgid(0,0); after you fork() and just before you exec() in order to move the forked process into its own process group. It's possible that vim/view is generating a SIGTTIN for the entire process group when trying to read the console. That would explain your 'T' process state.

vim/view is still being naughty by duplicating stderr to stdin rather than just erroring out, but at least it'll be its only victim by doing the above.


edit: ok according to the fork() manpage the child process should get a new pgid anyway, so I'm back to scratching my head and looking confused
scratch that last bit, I misread the fork manpage.

setsid() might even be a better choice than setpgid() if you want to disassociate from the controlling terminal, which might make sense for an X11 application.

1 members found this post helpful.

GazL, you nailed it! Thank you! I put setpgid into the barbarella program and now it launches view without anything seizing up. Of course view is invisible as it hasn't got a terminal, and ps shows it as "T" aka "stopped", but nothing else is affected. Just out of interest, here are view's file descriptors:
I still think this thread should be transferred to programming.

1 members found this post helpful.

You're welcome. It was interesting, if initially confusing, and gave me an opportunity to look into an area I'd not studied in much detail before.

that still not explain how and why /dev/tty1 is used.

Presumably it's used because X uses it and therefore fluxbox uses it. And everything that runs in X is a descendent of the window manager. Remember, this is Slackware so I'm starting X with startx (which is my preferred method anyway).

But that's not really the core of the problem, is it. The real problem is how X can be seized up by a trivial bug in a graphical application. That oughtn't to happen.

In Windows, if a program does something illegal, the whole system crashes and you get the blue screen of death. I read somewhere that early UNIX systems were like that too: if a program did something silly with a pointer and wrote into a major component's address space, it could bring that component down. It could even bring down the kernel and crash the whole system. That doesn't happen with Linux. So how come a program I wrote could effectively crash X?

This is not good.

I'd be interested to see the output of
ps -u $LOGNAME -o pid,ppid,sess,pgid,tty,cmd as I have some suspicions about this, but don't want to jump the gun.

Also, can you say whether you start 'barbarella' from xinitrc, or the fluxbox 'startup' file.