This is the mail archive of the cygwin@cygwin.com 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] |
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 uses. 3) Bug occurs at -O0 and -O2, so it doesn't seem to be optimisation dependent. 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. Attached: 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. Apologies: 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, DaveK
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: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |