Mail Archives: cygwin/2004/01/06/04:26:49
Hi,
You gotta download the latest cygwin1.dll snapshot, that has
fixes for a lot of those threading problems. There are still heaps of
other problems but these things you are describing have been
previously encountered and resolved.
http://cygwin.com/snapshots/cygwin1-20040103.dll.bz2
Regards
Arash Partow
PS: I've tried your sample program and it
seems to be working without any problems.
__________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net
>> 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
>>
.
_________________________________________________________________
Hot chart ringtones and polyphonics. Go to
http://ninemsn.com.au/mobilemania/default.asp
--
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/
- Raw text -