This is the mail archive of the mailing list for the Cygwin 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]

Cygwin / pthreads / stdio problem

    Hi all,

  I've been having massive trouble getting the simplest of multithreaded
code to run successfully under cygwin without crashing and memory
corruption.  I've now got a cut down testcase that as far as I can see shows
the problem to be in cygwin / stdlib / libpthread rather than in my code.

  The testcase is very simple: main spawns two threads, each of which does
nothing apart from spit out single chars to stdout at regular intervals.
The idea is for the foreground to then wait for a crlf from stdin (using
scanf) and set a global flag that causes the threads to exit.

  But what actually happens is a SEGV in memcpy (which appears to have got
there via a call to fread that is in turn called from the scanf function).
This doesn't occur until just after you've pressed CR, i.e. at the point
when scanf is scanning the input line and assigning the scanf-format fields.

  Relevant data:
    1)  According to all the docs I could find, the stdlib f- I/O calls are
all *supposed* to be MT-safe.
    2)  I'm compiling with -D_MT -D_REENTRANT -lpthread, among others.  I'm
not sure if the preprocessor symbols are vital or not; there's a serious
lack of documentation for all those magic preprocessor symbols that gcc
    3)  Bug occurs at -O0 and -O2, so it doesn't seem to be optimisation
    4)  In one run out of maybe every 20 or 30, something goes wrong even
before you press enter; somehow, a corrupt cursor-up character or two get
output, meaning that the single letters being spit out from the thread
functions end up climbing a line or two up the screen and overwriting the
earlier output.  See the final example in the attached cyg-bug.txt file.
This is consistent with the bugs that were occurring in the code I'm
actually working on at the moment, that prompted me to make this cut-down
testcase: in that code, I often saw parts of whole lines of output being
printed twice to the screen, which really screams out 'unsafe use of stdio
buffers' to me.
    5)  Nope, I don't have two conflicting versions of the dll.  And yes,
I'm up-to-date with the current released versions of everything.

    Source file mttest1.c, makefile used to build it, cygcheck-out.txt dump
from cygcheck, cyg-bug.txt showing the test program executing and crashing
both under gdb and standalone, and the .stackdump file from a crash.

    If I've just forgotten or left out something obvious that I should have
spotted myself, but I did google for it and nothing obvious came up.... At
the same time, I don't quite see how the threading support could be so
seriously buggy and other people wouldn't have come across it also, so I
just don't know.

    Thanks for any help anyone can offer,


Attachment: mttest1.c
Description: Text document

Attachment: makefile
Description: Binary data

Attachment: cygcheck-out.txt
Description: Text document

Attachment: cyg-bug.txt
Description: Text document

Attachment: mttest1.exe.stackdump
Description: Binary data

Unsubscribe info:
Problem reports:

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