On Tue, May 11, 2010 at 04:32:43PM -0700, Omar Zakaria wrote: > I know. That's what makes this so weird.
Run strace with "strace -f -eopen $some_program" -- check to see on each kill/restart cycle if it's reading in any settings files somewhere which it's either expecting to find and isn't -- but more liklely creating each time it runs? Bit of a long shot, but I suppose it's possible. > When the program hangs, I suspend it (ctrl-z) and then send "kill -9" to the > parent process. As you say, that should kill all child process etc., so the > next run should be like the last. However, it's not. Bah. -9 indeed. Don't be so rude to your processes, as this could affect the state of your program when you next run it (stale lock files, pid files, corrupt data, etc., etc.) Be more gentle -- signal 15 should be fine. > > So at this point, I am wondering whether you're killing what you think you > > are, because in my mind, what you've described here suggests that some > > process of this application is still running, and by you starting it a > > second time, after you "think" you've killed it, is actually forcing it to > > Do The Right Thing (tm) -- whatever that might be. > > Hrm. Makes sense. Let me check... > > Alright. I just ran a few tests using "ps ax" and the program. For future > reference and simplicity, the program is called Foresite and we launch > it using a perl script that sets a few things up for us. The script is called > fstePacific. > > Before launching the script, I ran "ps ax" to see what was running on the > machine. After launching the fstePacific script -- which subsequently > launched Foresite -- I ran "ps ax" again to see what had fired up. I then > suspended (ctrl-z) the fstePacific script and killed it using "kill -9 %1" > which should kill the suspended process. I then ran "ps ax" again to > see what had been killed. > > I repeated this twice more until Foresite was able to launch correctly. > The file are all attached in a zip file in case you wan to see the raw > output yourself, but to summarize: Thanks, but it's not interesting to me. I care more about what this process is doing internally -- i.e., the calls it's making to map windows, etc. I assume that it's via some FFI to some SmallTalk wrapper which talks XLib (or seemingly XCB)? > I can't see any differences aside from program running times between > the end of one run and the end of another. Also, I don't see any > differences in the process list while the script and the smalltalk app > are running. Finally, the kill -9 %1 command seems to kill all sub- > processes cleanly. > > Yes, this makes very little sense. Hopefully my strace suggestion might help, but it's just another heuristic; hardly very scientific I am afraid to say. > Yes, sorry about that. I didn't have the debugging vm available until > just now. Please find a more complete stack trace attached as well. > It's much longer because of all the assert statements the debugging > environment adds. Frame #9 looks like a good point to start from. If you could analyse that -- print out the contents of "ev", that would be useful. > I'm working on that smalltalk app for you. I hope the above > information is good enough to get you started, though. Yes and no. I would still need to see the application doing this, so I can then see what FVWM is doing (if anything) at the point the MapRequest comes through for the window. -- Thomas Adam