Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] An FYI on starter.cxx


Hi,

Yes, the case is regularly reproducible for me, or was until I changed the starter. However, it's reproducible with our launchers, and of course our tools. (It's our simulator that would not die.)

I'm not quite sure how you could reproduce it given all the dependencies on Tensilica stuff. Contact me off line if you are really motivated. I think Sebastien has a copy of our mutual NDA -- that's a reasonable first step.

Thanks!
-Chris
songer@xxxxxxxxxxxxx

At 02:21 PM 3/26/2003 -0500, Alex Chapiro wrote:
I'd rather try to understand why CloseHandle hangs the system. I tried to find something about this sort of CloseHandle misbehavior, but found nothing. Is it possible to reproduce the case?
Of course, we can run close block in a separate thread with time-out and then kill "bad" process in case of close failure.
 
Alex Chapiro
----- Original Message -----
From: Chris Songer
To: cdt-dev@xxxxxxxxxxx
Sent: Wednesday, March 26, 2003 12:15 PM
Subject: [cdt-dev] An FYI on starter.cxx



Hi!

I found a case where on Windows2000 calling Spawner::destroy() would end up hanging the thread calling it. The case was a little confusing but basically a launcher was spawning a windows app that caught CTRL_C_EVENT and ignored. That meant that the TerminateProcess call was the thing actually killing the process. Quoting from the windows docs on TerminateProcess:

Use it only in extreme circumstances. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess.

The lockup happened when Spawner.destroy() went to close stderr. iostreams::SpawnerInputStream_close0 hung under CloseHandle(). The handles were all correct, nothing had been corrupted, I can only assume that what the quote above warned about actually happened.

To fix my case, I added a GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, 0 ) to the existing CTRL_C_EVENT in starter.exe to send a signal that the app was not catching and ignoring. The lockup went away. Clearly this would not be a fix if the spawned application were also catching CTRL_BREAK_EVENT, so it's not a generic solution.

Probably the "right" fix is a two stage shutdown where you try a signal first, if that works you know you can close the file descriptors safely. If it does not, you expressly ask for TerminateProcess and shut the filedescriptors with an awareness that the call to Spawner*Stream.close() may hang. A return from Spawner.raise(x,TERM) indicating if TerminateProcess had to be used would also work.

I'm not advocating all that work -- it's surely not worth it unless someone actually comes up with the case. Just an FYI.

Thanks,
-Chris

Back to the top