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

Reply via email to