Subject: Fwd: Re: problems with pthreads && c++ (suspect wait conditions)
From: Max Zaitsev <[email-masked]>
To: Thomas Pfaff <[email-masked]>
Cc: [email-masked]
Date: Fri, 5 Jul 2002 18:59:43 +0200

Hi!

I seem to have sorted the problem myself. Seeing amount of fuss about g++ with 
exceptions and pthreads I've recompiled the source with -fno-exceptions and 
it works now. Gdb still crashes, but mutella at least runs quite reliably.

It would be nice if somebody at cygwin would document such a behavior of gcc, 
that is even if one don't have any try-catch blocks one still have to use 
-fno-exceptions to forbid them completeli kind of...

Another question: all the mutexes appear to be recursive, is it true?

Regards,
Max

----------  Forwarded Message  ----------

Subject: Re: problems with pthreads && c++ (suspect wait conditions)
Date: Thu, 4 Jul 2002 10:20:29 +0200
From: Max Zaitsev <[email-masked]>
To: Thomas Pfaff <[email-masked]>
Cc: [email-masked]

Hi Thomas,

thanks for a quick reply.

>  There has been some changes in the pthread code between 1.3.10 and 1.3.11.
>  Has you tried your program with 1.3.10 ?

I had 1.3.5 I guess, but it's gone now. Mutella used to crash there and even
did not pass statics init in GDB. After I've updated to 1.3.11 it still
crashes but I can reach a breakpoint in main() with GDB.

Before I forget, I do not use exceptions in mutella at all.

>  I will try to run your app as soon as possible.

This describes how to crash the current CVS. The released 0.4 crashes as
 well, but I have not investigated it that well.

I can give you a quick intro and describe a way how to crash mutella-cvs. It
is gnutella client, so once you start it it will try to create a connection
to the gnutella-net. But you probably do not want it... Than in terminal
prompt (it a terminal app) type

set QuietMode 1
exit

and start it again. most likely mutella will hanf on exit, it is also a
 cygwin feature -- for whatever reason wait condition misses the wake-up
 call.

anyway, if you restart mutella after, it will not connect by itself. now we
can type in the crash sequence:

set SharePath /any/non/empty/but/not/too/full/dir/on/your/system
scan
<crash>

file sharing implemented in a separate thread, which communicates by means of
self-written event loop with the rest of the app. scan command issues the
event when share path is not empty. in principle you may use any string
there, but then you'll get error messages... anyways, as I see it on my w2k
box, you may need to repeat scan command several times. (you dont have to
repeat set...)

Thanks for your help,
Max

-------------------------------------------------------

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/