This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Spurius results for cygwin selftest.exp(was Re: [RFC] fix annoying completion bug on directories)


On Wed, Jul 09, 2008 at 12:16:04AM +0200, Pierre Muller wrote:
>> >   I ran the testsuite on cygwin, and found one
>> > change, but in gdb.gdb/selftest.
>> >   FAIL (timeout) xgdb is at prompt
>> >
>> >   I suspect that this is due to a problem with the
>> > [New thread %s] output, that are now default.
>> > Because this output appears right after the gdb prompt,
>> > and thus the match with a gdb prompt exactly at the end
>> > is not found.
>> 
>> In these cases, in addition to analising the log file, please
>> rerun the test to confirm it was spurious.  Cygwin testing
>> is indeed flackier than linux.
>
>  This is indeed a spurious FAIL that has to do with that
>third thread that start on cygwin right after the command prompt is
>printed out.
>  Does anyone know why there is a third thread starting?
>Debugging threads under cygwin is quite difficult, you never really know
>where they are coming from...

Cygwin starts a signal thread during process creation and, if you are
running with CYGWIN=tty will start a couple more threads to deal with
tty I/O.  If the process is using select() or poll() it will start
threads for that too.  It should not start extra threads when using ptys
however.

The test suite isn't setting CYGWIN=tty somewhere is it?  It used to be
necessary that you set CYGWIN=tty in order to use ptys and sometimes
people still insist that it is required.  If is is set somewhere that
could account for extra, unneeded, threads.

Cygwin 1.5.x it may also start a thread-per-fd to deal with pipe I/O.
I've removed that annoyance from the not-yet-released 1.7.x version.  (I
introduced another pipe problem in the process of doing that but hey,
that's software)

Does debugging the process cause an extra thread to be created by
Windows, too?  I don't remember.  I know it creates a thread when you
attach to a process but I don't know if it does just in a standard
debug when a process started via CreateProcess.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]