Hi Chris,
You may be right, but I don't remember ever having to wade through 308K
worth of code to try to figure out a problem. Searching the archives,
I see that you had a program called "ThreadTest" which exposed a stdio
memory leak. I still have that program sitting around and it doesn't
s
On Mon, Jun 06, 2005 at 02:28:45AM +, Arash Partow wrote:
>Hi Chris,
>
>How many times can we do this dance ? he he he he :)
>
>The code given is as simple as its gonna get. This is the same
>code used by Thomas Pfaff and by YOU to fix previous memory
>leaks found in cygwin :)
You may be right
Hi Chris,
How many times can we do this dance ? he he he he :)
The code given is as simple as its gonna get. This is the same
code used by Thomas Pfaff and by YOU to fix previous memory
leaks found in cygwin :)
OK in simple terms this is what I see: I run example1 and
open up my taskmanager and
On Mon, Jun 06, 2005 at 12:37:14AM +, Arash Partow wrote:
>I'm encountering some memory leaks when using pthreads under cygwin.
>As usual the code has been compiled/run on other *nixes (openbsd3.7,
>netbsd2.0 and mandrake10.1) and the leak does not seem to occur.
>
>The system specs are as foll
Hi all,
I'm encountering some memory leaks when using pthreads under cygwin.
As usual the code has been compiled/run on other *nixes (openbsd3.7,
netbsd2.0 and mandrake10.1) and the leak does not seem to occur.
The system specs are as follows:
1.) gcc 3.3.3
2.) cygwin dll, snapshots as of:
3
On Wed, 22 Sep 2004 13:57:26 +0100, Dave Korn wrote:
>> So could someone who got the _successful_ run of sig_bug.exe with recently
>> (>1.5.7-1) releases or snapshots of cygwin1.dll send it
>> (sig_bug.exe) to my personal e-mail?
>
> Well, here you go; source as well, just in case you have mor
> -Original Message-
> From: cygwin-owner On Behalf Of Valery A. Frolov
> Sent: 21 September 2004 22:52
> I've checked it and got the same bad result (crash) on 2000,
> XP and Win98.
>
> I've installed cygwin bundle for compilation of sig_bug.c on XP, compiled
> sig_bug.c to sig_bug.exe
> Maybe the operating system is the essence. I've always tried it on NT 4.0
> WS SP6a+hotfixes. Tomorrow I'll check it (the same executable) on 2000/XP.
I've checked it and got the same bad result (crash) on 2000, XP and Win98.
I've installed cygwin bundle for compilation of sig_bug.c on XP, comp
On Mon, 20 Sep 2004 10:35:48 -0400, Christopher Faylor wrote:
> FWIW, I tried it ten times without error. I have it running in a loop
> now. If it dies, I'll fix the problem.
But I had _no_ one successful run at all.
Maybe the operating system is the essence. I've always tried it on NT 4.0
WS SP
> -Original Message-
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 20 September 2004 15:36
> On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak
> Scott-Thoennes wrote:
> >On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
> >>No SEGV for me. -lpthread didn't seem n
On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak Scott-Thoennes wrote:
>On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
>>No SEGV for me. -lpthread didn't seem necessary. I'm using a version
>>of the cygwin1.dll built from CVS sources on 20041407.
>
>did you try it more than once? I
On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
> No SEGV for me. -lpthread didn't seem necessary. I'm using a version of
> the cygwin1.dll built from CVS sources on 20041407.
Wow, that's a lot more advanced than any snapshot I've seen. I'm
curious to know what version it reports.
> -Original Message-
> From: cygwin-owner On Behalf Of Valery A. Frolov
> Sent: 16 September 2004 20:15
> >> And after while I've got (IMHO) a little test source (attached) to
> >> reproduce the problem.
> >
> > Can anyone confirm this problem?
>
> So, after week of silence I can make th
>> And after while I've got (IMHO) a little test source (attached) to
>> reproduce the problem.
>
> Can anyone confirm this problem?
So, after week of silence I can make the decision that this problem has
been happened only for me (because no one has confirmed it). Anyway,
many many thanks for al
Hello,
On Mon, 30 Aug 2004 13:43:50 +0300, Valery A. Frolov wrote:
> And after while I've got (IMHO) a little test source (attached) to
> reproduce the problem.
Can anyone confirm this problem?
I've tested my testcase source (see previous letter) with cygwin1.dll
1.5.11-1, gcc 3.3.3-3, binutils-
On Fri, Aug 27, 2004 at 09:11:56PM +0300, Valery A. Frolov wrote:
>In short:
>First signal delivery on call of pthread_kill(tid, SIGUSR1) works fine
>but second one delivers signal with _delay_ and _twice_, and then my
>own daemon crash. This is on cygwin1.dll 1.5.10-3 and snapshot of
>2004-08-21.
> Whole trace files (strace7.log & straceB.log) are attached to this letter.
Heh... Forgot attach it.
WBR,
Valery
13:03:41 [main] yolopd 161 sigproc_init: process/signal handling enabled(1)
13:03:41 [main] yolopd 161 wait_for_sigthread: wait_sig_inited 0x54
13:03:41 [main] yolopd 161 subproc_ini
Hello,
In short:
First signal delivery on call of pthread_kill(tid, SIGUSR1) works fine
but second one delivers signal with _delay_ and _twice_, and then my
own daemon crash. This is on cygwin1.dll 1.5.10-3 and snapshot of
2004-08-21. But on cygwin1.dll 1.5.7-1 all works _fine_ and _long_ time.
I
Hi Philippe,
I've tested the latest dll snapshot (12/12), and its still displaying the
problem.
nothing was changed in the signaling or pthreads area that would
effect the problem.
maybe try using the provided snapshot perhaps?
-Marcus
Hi all!
I've tested the latest CVS version (2003-12-12 1
Hi all!
I've tested the latest CVS version (2003-12-12 11:00AM GMT+1), and yes
thinks are better, for me the ThreadTest seems to run correctly.
But I you use the compiled version to rebuild cygwin itself, no chance, make
die. Probably a similar case than my previous post "Bash wait indefinitely".
On Fri, Dec 12, 2003 at 04:04:15AM +, Arash Partow wrote:
>You know all you have to do is send me the exe you build using the
>original ThreadTest. (with debug info if possible) and give me some
>time to disassemble it, this will give you more time to continue on
>with your own development wor
Hi Chris,
btw i've attached my cygcheck, might come in handy
Regards
Arash Partow
__
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://w
Hi Chris,
You know all you have to do is send me the exe you build using the
original ThreadTest. (with debug info if possible) and give me some
time to disassemble it, this will give you more time to continue
on with your own development work and other previously mentioned
things, and hence you w
On Fri, Dec 12, 2003 at 02:43:03AM +, Arash Partow wrote:
>Hi Chris,
>
>Sorry about the late reply, now here is the best I can do with
>the debug 101 skills.
>
>The problem/issue/possible bug that "I" see when I run ThreadTest is the
>following, I run ThreadTest and let it reach about 2k thread
Hi Chris,
Sorry about the late reply, now here is the best I can do with
the debug 101 skills.
The problem/issue/possible bug that "I" see when I run ThreadTest is the
following, I run ThreadTest and let it reach about 2k threads completed.
at that point i hit ctrl+c. I see that the main loop in t
Btw, if someone can figure out precisely what they think is going wrong
with the ostensible problems that people are reporting, I'll be happy to
track this down.
I don't mean vagueness like "I think the signal isn't going to the
thread". I mean something concrete like "The signal handler is not
r
On Wed, Dec 10, 2003 at 05:44:03AM +, Arash Partow wrote:
>I think chris at the moment is far too busy to give it the time it
>requires which is fine. You know with all his development work,
>patronizing and sarcasm, he must be a very busy man ;)
Wow. It's like you know me. When I am not bu
Hi,
look marcus don't worry yourself too much about this issue, I'm sure
in time as more people encounter this problem, or slightly different
forms of the problem begin popping up in different parts of cygwin,
more attention will be spent on resolving it. if however its totally
our mistake where b
On Wed, Dec 10, 2003 at 03:38:44AM +, Marcus Van Der Beek wrote:
>now because you say its working just fine on your system, doesn't
>necessarily mean everything is all good.
No, it means that we'll have people sending email saying "It doesn't
work for me" and people speculating about how softw
chris,
Let me say it again: I don't see the problem either with my changes or
without it. I just didn't see any good reason to go on creating threads
after a signal has been received which the original code did.
I agree with you totally, it would be reasonable for the garbage collector
thing to
On Tue, Dec 09, 2003 at 10:51:48PM +, Marcus Van Der Beek wrote:
>i tried the code you provided, it does resolve the issue, however why do
>we need to change the test?
Let me say it again: I don't see the problem either with my changes or
without it. I just didn't see any good reason to go o
Hi Marcus,
I asked chris the same questions yesterday, i wondered why he felt he
need to change the code in order for it to work with cygwin. Its a shame
though cause i see as time goes by and CPUs become better adapted to
thread processing that people will write new utilities and maybe even
begin
chris,
i tried the code you provided, it does resolve the issue, however why do
we need to change the test? as arash pointed out it seems to work on other
platforms well enough. the modified version arash posted back seems to
demonstrate the problem, and all it seems he has done get rid of delays
Hi Chris,
I forgot to attach the ThreadTestPrototype.cpp file in
my previous post, here it is if you would like to have
a fiddle with it.
Regards
Arash Partow
__
Be one who knows what they don't know,
Instead of being one who knows not what they
Hi Chris,
The ThreadTest was used to demonstrate a deficiency in cygwin's pthreads
implementation, and in doing so was successful in finding 4 serious
problems that ranged from memory leaks, application crashes to improper
handling of context switches in the thread pools. So continue to be
mystifi
On Tue, Dec 09, 2003 at 03:01:56AM +, Arash Partow wrote:
>Hello Sherly,
>
>I haven't tried the ThreadTest on a solaris system however ive e-mailed
>someone that does have access to one, they will try it i'll get the results
>back to you, but out of interest what do you think the solaris system
Hello Sherly,
I haven't tried the ThreadTest on a solaris system however ive e-mailed
someone that does have access to one, they will try it i'll get the results
back to you, but out of interest what do you think the solaris system will
do? and how do you think that behaviour will relate to cygiwn
Hi Chris,
I have to agree with marcus, the dll from the 8th still has the
signalling issue. you have to let the threadtest run for a bit,
meaning let it get to around 3k-4k of threads being created, at
that point the SIGINT does not seem to fire.
Arash
Hi Chris,
I've tried the latest snapshot 8/12/2003, that dll doesn't seem to
have the win32-hndl problem that was seen in previous versions of
the dll, but it is still exibiting the signalling problems.
Marcus
I fixed a handle leak problem last night. I don't suppose that it
occurred to you
Hi,
I've tried the latest snapshot 8th of december, that doesn't seem to show
the handel issue arash was talking about (which i think chris fixed),
however the signal problem with SIGINT is there. The behavior i see is as
follows, after the 1st 700 threads have been created, i press ctrl+c
instant
On Mon, Dec 08, 2003 at 11:09:37PM +, Marcus Van Der Beek wrote:
>I've downloaded the tests and dlls both from you're site and last
>few cygwin snapshots and CONFIRMED your results. There is a major
>bug in both the signaling during threads and also the problem
>of accumulating handles. Just by
hello marcus,
thanx for your confirmation, however i don't think its a good idea to
be blaming anyone for these bugs, they are a natural occurrence during
development and of course addition of new features.
In any case could you please tell me how you ascertained the accumulating
handles count, di
Hi Arash,
I've downloaded the tests and dlls both from you're site and last
few cygwin snapshots and CONFIRMED your results. There is a major
bug in both the signaling during threads and also the problem
of accumulating handles. Just by looking at the various changes
in the snapshots it seems cgf
Hi all,
I've been testing some of the new snapshot dlls etc made
recently (last 1.5 weeks) due to the increase of activity
in the areas of threads and signaling and I think some
of the Pthread and signaling behavior has been broken.
A pthread test case that I had written before, displayed
memory l
Joe Sadusk wrote:
I'm in qa, and I'm attempting to port a filesystem stress test written
for Linux to Windows using cygwin. It uses pthreads to create many
concurrent threads which read files out of a directory in various
patterns. The thing is, I've found that with any more than 55 threads,
I'm in qa, and I'm attempting to port a filesystem stress test written
for Linux to Windows using cygwin. It uses pthreads to create many
concurrent threads which read files out of a directory in various
patterns. The thing is, I've found that with any more than 55 threads,
pthread_join will
46 matches
Mail list logo
