New snapshot please

[Yaakov (Cygwin/X)]

Could you spin a new snapshot?  I'm having problems with CVS HEAD and
I'm trying to figure out if the problem is with GCC or with Cygwin.

Thanks,


Yaakov

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Device names in /proc/mounts

[Schwarz, Konrad]

> -Original Message-
> From: Christopher Faylor 
> Subject: Re: Device names in /proc/mounts

> The "drive letters" above could be anything that 
> Windows maps to a drive letter.  A drive does not necessarily 
> directly map to a physical device.

That's why the proposal suggests using /dev/sdXY names only when
a driver letter does indeed map to a hard disk.
 
> /cygdrive is a user-settable value.

So use whatever /cygdrive is actually set to.

>  Some users use other 
> values like "/dev" instead of /cygdrive.

How does /dev/ttyS0 resolve in this case?
Those users have already shot themselves in the foot.

> Some people get rid 
> of the /cygdrive entirely and just map to /a.

Which would be a rebind.  /cygdrive (or the user's
selected replacement) still exists, right?

>  We're not 
> going to introduce this level of recursive confusion to the 
> mount table handling.

The proposal is sound.  It works on Linux, after all.

> Please give it a rest.  We're not changing the mount table for you.

Ok.

Can you answer the following question:

Given a volume label, how does one figure out where the corresponding
volume has been mounted into the Cygwin namespace?

Thanks,

Konrad Schwarz

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Slow performance Win7/64

[Heiko Elger]

Hello jojelino,

I just rebuild cygwin1.dll latest snapshot. 

> I believe the attached patch workarounds delayed wait_sig problem.
Yes - it works fine!

> This yielded speed improvement. i ran your testcase and same timestamp 
> recorded 35. approx 2x speed.

  XP/32  Win7/64
cygwin snapshot 2011-07-21  34  12
cygwin snapshot 2011-07-21 SIGPATCH 44  37

As you see XP and Win7 now a really faster.
Win7 3x speed - wow.

> but i can't make sure it doesn't include side-effects. please test it on 
> your pc. let's hope it would work.
I will test ist.

I've already recognize one positive side effect:
The CTRL-C Handler works now even faster.
With unpatched cygwin1.dll there was a realy long delay, after pressing CTRL-C.
Can you agree this too?

I'm very interested if this patch will be released or not.
I'm interested in the opionion opinion of C. Vinschen and C Faylor.

best regards

heiko


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Device names in /proc/mounts

[Corinna Vinschen]

On Jul 29 09:45, Schwarz, Konrad wrote:
> > From: Christopher Faylor 
> >  We're not 
> > going to introduce this level of recursive confusion to the 
> > mount table handling.
> 
> The proposal is sound.  It works on Linux, after all.

Ok, so I assume Cygwin should be able to load Linux kernel modules
and provide tools like modprobe and lsmod, right?  After all, it
works on Linux.  It does not really help to drive the compatibility
in with a hammer.

> > Please give it a rest.  We're not changing the mount table for you.

> Ok.
> 
> Can you answer the following question:
> 
> Given a volume label, how does one figure out where the corresponding
> volume has been mounted into the Cygwin namespace?

We're not mounting volumes, we're mounting Win32 paths.  There is no
direct correspondence between volumes and Cygwin mount points.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Slow performance Win7/64

[Corinna Vinschen]

On Jul 29 08:43, Heiko Elger wrote:
> Hello jojelino,
> 
> I just rebuild cygwin1.dll latest snapshot. 
> 
> > I believe the attached patch workarounds delayed wait_sig problem.
> Yes - it works fine!
> 
> > This yielded speed improvement. i ran your testcase and same timestamp 
> > recorded 35. approx 2x speed.
> 
>   XP/32  Win7/64
> cygwin snapshot 2011-07-21  34  12
> cygwin snapshot 2011-07-21 SIGPATCH 44  37
> 
> As you see XP and Win7 now a really faster.
> Win7 3x speed - wow.
> 
> > but i can't make sure it doesn't include side-effects. please test it on 
> > your pc. let's hope it would work.
> I will test ist.
> 
> I've already recognize one positive side effect:
> The CTRL-C Handler works now even faster.
> With unpatched cygwin1.dll there was a realy long delay, after pressing 
> CTRL-C.
> Can you agree this too?
> 
> I'm very interested if this patch will be released or not.
> I'm interested in the opionion opinion of C. Vinschen and C Faylor.

Me too :)

The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition.  Jojelino's patch looks nice, but
it might reintroduce a new race.  Handle with care.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: New snapshot please

[Corinna Vinschen]

On Jul 29 02:04, Yaakov (Cygwin/X) wrote:
> Could you spin a new snapshot?  I'm having problems with CVS HEAD and
> I'm trying to figure out if the problem is with GCC or with Cygwin.

Hang on, please.  I'm just looking into a socket problem which needs
some more debugging.  I will probably apply another patch today and then
generate a new snapshot (with your 4.5.3, btw.  I have no problems to
build Cygwin CVS with it).


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Slow performance Win7/64

[jojelino]

On 2011-07-29 오후 6:26, Corinna Vinschen wrote:

I've already recognize one positive side effect:
The CTRL-C Handler works now even faster.
With unpatched cygwin1.dll there was a realy long delay, after pressing CTRL-C.
Can you agree this too?


I agree sincerely.


The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition.  Jojelino's patch looks nice, but
it might reintroduce a new race.  Handle with care.


The process are failing to fork with rare rate. (with make -j 10 command)
although i'm using cygwin with CFLAGS=-O4 -fomit-frame-pointer and 
disabling all {cygheap,}_CFLAGS. but in most occasions it works fine.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: mc-4.7.5.3-1

[Marco atzeri]

Version 4.7.5.3-1 of Midnight Commander
has been uploaded for cygwin

CHANGES
This is an new upstream release.

For the full upstream changes
http://www.midnight-commander.org/wiki/NEWS-4.7.5.3

CYGWIN CHANGES
The closure of the subshell is now handled.

DESCRIPTION
GNU Midnight Commander is a visual file manager. It's a feature rich
full-screen text mode application that allows you to copy, move and
delete files and whole directory trees, search for files and run
commands in the subshell. Internal viewer and editor are included.


HOMEPAGE
http://www.midnight-commander.org/


Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the 
format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Startup Problem

[Daniel Colascione]

On 7/28/11 12:24 PM, Larry Hall (Cygwin) wrote:
> On 7/28/2011 3:01 PM, Ed wrote:
>>
>> Quite often when I open a Cygwin session when it runs a .bashrc script it
>> will show errors of basic commands not found. For example pwd or ls  returns
>> command not found when I type it at the command prompt. When I reboot the XP
>> PC everything is fine for a couple of days.
> 
> Sounds like it could be BLODA. 
> 
> Otherwise, read and follow the problem reporting guidelines found
> here:
> 
> 
> 


Is there some test suite that can detect the bugs commonly introduced by BLODA?
 Pinpointing problems, e.g., "CreateFile doesn't properly interpret
FILE_FLAG_OVERLAPPED pipes", would be useful not only for users trying to run
reliable systems, but for developers trying to make sure their programs don't
interfere with the rest of the system.



signature.asc
Description: OpenPGP digital signature

Re: Slow performance Win7/64

[Heiko Elger]

Hello,

Corinna Vinschen writes:
> 
> The slowdown of the code was the result of a patch which was supposed
> to fix a potential race condition.  Jojelino's patch looks nice, but
> it might reintroduce a new race.  Handle with care.
Oops - what king of race condition do you mean.

OK - that's a new information for me.
So the current slow implementation is a workaround for another race condition.

So - is there no other way for fixing that race contion!

Is there another implememtaion for fixing the slow signaling without getting a
new race condition.

Heiko




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Slow performance Win7/64

[Christopher Faylor]

On Fri, Jul 29, 2011 at 12:52:47PM +, Heiko Elger wrote:
>Hello,
>
>Corinna Vinschen writes:
>> 
>> The slowdown of the code was the result of a patch which was supposed
>> to fix a potential race condition.  Jojelino's patch looks nice, but
>> it might reintroduce a new race.  Handle with care.
>Oops - what king of race condition do you mean.
>
>OK - that's a new information for me.
>So the current slow implementation is a workaround for another race condition.

The signal startup has been very carefully crafted.  Starting wait_sig
asynchronously could create inability to send signals.

I can't check this right now.  I should be back near my Windows system on the
weekend.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Device names in /proc/mounts

[Schwarz, Konrad]

> > Can you answer the following question:
> > 
> > Given a volume label, how does one figure out where the 
> corresponding 
> > volume has been mounted into the Cygwin namespace?
> 
> We're not mounting volumes, we're mounting Win32 paths.  
> There is no direct correspondence between volumes and Cygwin 
> mount points.

When a person inserts removable media (USB memory stick, optical disk, ...),
Windows assigns a more-or-less random drive letter.
Cygwin automatically makes this drive letter available
under /cygdrive/ (or whatever the user has renamed /cygdrive to).

Given a (unique) volume label or disk UUID, blk_id(8) on
both Linux and Cygwin tells you the disk and partition
in /dev/sdXY format.

In Linux, you can look up the mount point for device /dev/sdXY
in /proc/mounts or in the output of mount(8).  Thus, given
a volume label, you can figure out where to access the files
on the volume.

How do you do that in Cygwin?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin Startup Problem

[Larry Hall (Cygwin)]

On 7/28/2011 4:03 PM, Daniel Colascione wrote:

On 7/28/11 12:24 PM, Larry Hall (Cygwin) wrote:

On 7/28/2011 3:01 PM, Ed wrote:


Quite often when I open a Cygwin session when it runs a .bashrc script it
will show errors of basic commands not found. For example pwd or ls  returns
command not found when I type it at the command prompt. When I reboot the XP
PC everything is fine for a couple of days.


Sounds like it could be BLODA.

Otherwise, read and follow the problem reporting guidelines found
here:





Is there some test suite that can detect the bugs commonly introduced by BLODA?
  Pinpointing problems, e.g., "CreateFile doesn't properly interpret
FILE_FLAG_OVERLAPPED pipes", would be useful not only for users trying to run
reliable systems, but for developers trying to make sure their programs don't
interfere with the rest of the system.



No, there's nothing like that currently.  It would probably be a good
chunk of work to make a nice, useful diagnostic tool here.  Could be
helpful.  I suppose one could argue that any effort would be better
spent on exploring new ways of avoiding these issues than tools to
recognize them.  But one may lead from the other so I certainly wouldn't
discourage anyone from efforts either way. :-)

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/date differs 10-12 minutes from Windows time

[Larry Hall (Cygwin)]

On 7/29/2011 3:28 AM, Voelker, Bernhard wrote:

I'm experiencing windows time (which is right) being constantly
10-12 minutes behind GNU's time:

   $ cmd.exe /c time /t ; /bin/date
   09:21
   Fri Jul 29 09:33:22 WEDT 2011

I've seens this for several weeks on this PC now.

Why is that? If it were 1 or 2 hours, I'd say it a TZ issue ...


Not sure.  I don't see that but I'm also in a different TZ.  Perhaps
you should look at your cygcheck output for clues or compare the
configuration of this machine with others that don't show this problem.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/date differs 10-12 minutes from Windows time

[Thorsten Kampe]

* Voelker, Bernhard (Fri, 29 Jul 2011 09:28:42 +0200)
> I'm experiencing windows time (which is right) being constantly 10-12
> minutes behind GNU's time:
> 
>   $ cmd.exe /c time /t ; /bin/date
>   09:21
>   Fri Jul 29 09:33:22 WEDT 2011
> 
> I've seens this for several weeks on this PC now.
> 
> Why is that? If it were 1 or 2 hours, I'd say it a TZ issue ...

Probably http://www.cygwin.com/ml/cygwin/2011-03/msg00838.html

Thorsten


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Pthread error?

[Jan Chludzinski]

The code below appears to have incorrect behavior.  The output is:

$ ./a.exe
Enter Testcase - ./a
Create/start threads
Thread 009e0290 : Entered
Thread 009f0320 : Entered
Thread 009f03a8 : Entered
Thread 18dbce64 : INITIALIZE RESOURCE
Wait for the threads to complete, and release their resources
Thread 009f0430 : Entered
Thread 00a104f8 : Entered
Thread 009e0290 0001: resource is>>> 0
Thread 009e0290 002a: The resource is 0
Thread 009f0320 002a: The resource is 0
Thread 009f03a8 002a: The resource is 0
Thread 009f0430 002a: The resource is 0
Thread 00a104f8 002a: The resource is 0
Main completed

If I understand pthread_once(...) correctly, the output should be:

Thread ... ...: The resource is 42

for all threads.  The really strange thing is the printf(...) in
initFunction().  This should print "resource is>>> 42" but I get:
"resource is>>> 0".

What's up?

I'm using Cygwin 1.7 on Windows 7 with gcc (GCC) 4.3.4 20090804 (release) 1.

---John




#include 
#include 
#include 
#include 

#define checkResults(string, val) { \
 if (val) { \
   printf("Failed with %d at %s", val, string); \
   exit(1); \
 }  \
}

#define NUMTHREADS   5
pthread_once_t  oneTimeInit = PTHREAD_ONCE_INIT;
int initialized = 0;
int resource    = 0;

void initFunction(void)
{
   printf("Thread %.8x %.8x: INITIALIZE RESOURCE\n");
   initialized = 1;
   resource = 42;
   printf("Thread %.8x %.8x: resource is>>> %d\n",
     pthread_self(), resource);
}

void *theThread(void *parm)
{
  int   rc;
  printf("Thread %.8x %.8x: Entered\n", pthread_self());
  //if (!initialized) {
    rc = pthread_once(&oneTimeInit, initFunction);
    checkResults("pthread_once()\n", rc);
    //}
  printf("Thread %.8x %.8x: The resource is %d\n",
     pthread_self(), resource);
  return NULL;
}

int main(int argc, char **argv)
{
  pthread_t thread[NUMTHREADS];
  int   rc=0;
  int   i;

  printf("Enter Testcase - %s\n", argv[0]);

  printf("Create/start threads\n");
  for (i=0; i http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread error?

[Eric Blake]

On 07/29/2011 10:59 AM, Jan Chludzinski wrote:

The code below appears to have incorrect behavior.  The output is:


Compile with -Wall.


Thread 00a104f8 002a: The resource is 0



printf("Thread %.8x %.8x: resource is>>>  %d\n",
  pthread_self(), resource);


Three uses of %, but only two arguments.  You're reading random stuff 
off the stack because you used printf incorrectly.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread error?

[Jan Chludzinski]

Don't know why all the white space in the code turned intro "?".
Hopefully this is better:

#include 
#include 
#include 
#include 

#define checkResults(string, val) { \
 if (val) { \
   printf("Failed with %d at %s", val, string); \
   exit(1); \
 }  \
}

#define NUMTHREADS   5
pthread_once_t  oneTimeInit = PTHREAD_ONCE_INIT;
int initialized = 0;
int resource= 0;

void initFunction(void)
{
   printf("Thread %.8x %.8x: INITIALIZE RESOURCE\n");
   initialized = 1;
   resource = 42;
   printf("Thread %.8x %.8x: initialized is>>> %d\n",
 pthread_self(), initialized);
}

void *theThread(void *parm)
{
  int   rc;
  printf("Thread %.8x %.8x: Entered\n", pthread_self());
  //if (!initialized) {
rc = pthread_once(&oneTimeInit, initFunction);
checkResults("pthread_once()\n", rc);
//}
  printf("Thread %.8x %.8x: The resource is %d\n",
 pthread_self(), resource);
  return NULL;
}

int main(int argc, char **argv)
{
  pthread_t thread[NUMTHREADS];
  int   rc=0;
  int   i;

  printf("Enter Testcase - %s\n", argv[0]);

  printf("Create/start threads\n");
  for (i=0; i  wrote:
>
> The code below appears to have incorrect behavior.  The output is:
>
> $ ./a.exe
> Enter Testcase - ./a
> Create/start threads
> Thread 009e0290 : Entered
> Thread 009f0320 : Entered
> Thread 009f03a8 : Entered
> Thread 18dbce64 : INITIALIZE RESOURCE
> Wait for the threads to complete, and release their resources
> Thread 009f0430 : Entered
> Thread 00a104f8 : Entered
> Thread 009e0290 0001: resource is>>> 0
> Thread 009e0290 002a: The resource is 0
> Thread 009f0320 002a: The resource is 0
> Thread 009f03a8 002a: The resource is 0
> Thread 009f0430 002a: The resource is 0
> Thread 00a104f8 002a: The resource is 0
> Main completed
>
> If I understand pthread_once(...) correctly, the output should be:
>
> Thread ... ...: The resource is 42
>
> for all threads.  The really strange thing is the printf(...) in
> initFunction().  This should print "resource is>>> 42" but I get:
> "resource is>>> 0".
>
> What's up?
>
> I'm using Cygwin 1.7 on Windows 7 with gcc (GCC) 4.3.4 20090804 (release) 1.
>
> ---John
>
>
> 
>
> #include 
> #include 
> #include 
> #include 
>
> #define checkResults(string, val) { \
>  if (val) { \
>    printf("Failed with %d at %s", val, string); \
>    exit(1); \
>  }  \
> }
>
> #define NUMTHREADS   5
> pthread_once_t  oneTimeInit = PTHREAD_ONCE_INIT;
> int initialized = 0;
> int resource    = 0;
>
> void initFunction(void)
> {
>    printf("Thread %.8x %.8x: INITIALIZE RESOURCE\n");
>    initialized = 1;
>    resource = 42;
>    printf("Thread %.8x %.8x: resource is>>> %d\n",
>      pthread_self(), resource);
> }
>
> void *theThread(void *parm)
> {
>   int   rc;
>   printf("Thread %.8x %.8x: Entered\n", pthread_self());
>   //if (!initialized) {
>     rc = pthread_once(&oneTimeInit, initFunction);
>     checkResults("pthread_once()\n", rc);
>     //}
>   printf("Thread %.8x %.8x: The resource is %d\n",
>      pthread_self(), resource);
>   return NULL;
> }
>
> int main(int argc, char **argv)
> {
>   pthread_t thread[NUMTHREADS];
>   int   rc=0;
>   int   i;
>
>   printf("Enter Testcase - %s\n", argv[0]);
>
>   printf("Create/start threads\n");
>   for (i=0; i      rc = pthread_create(&thread[i], NULL, theThread, NULL);
>     checkResults("pthread_create()\n", rc);
>   }
>
>   printf("Wait for the threads to complete, and release their resources\n");
>   for (i=0; i      rc = pthread_join(thread[i], NULL);
>     checkResults("pthread_join()\n", rc);
>   }
>
>   printf("Main completed\n");
>   return 0;
> }

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread error?

[Jan Chludzinski]

Thanks!

This is an example (from IBM) I cut-and-paste into Emacs to better
understand pthread_once(...).  Didn't notice the two "%.8x" in
printf().

Thanks again, Jan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread error?

[Jan Chludzinski]

Can't blame IBM either.  I had to replace pthread_getthreadid_np() (in
the IBM example code) with pthread_self() because Cygwin doesn't
support/have pthread_getthreadid_np().

And the IBM docs say pthread_getthreadid_np() returns "a structure
containing the hi and low order 4 bytes of the 64bit ID".  The 2
"%.8x" would make sense.

---Jan


On Fri, Jul 29, 2011 at 1:16 PM, Jan Chludzinski
 wrote:
> Thanks!
>
> This is an example (from IBM) I cut-and-paste into Emacs to better
> understand pthread_once(...).  Didn't notice the two "%.8x" in
> printf().
>
> Thanks again, Jan
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

1.7.10s 20110729 - problem listing services in /proc

[David Rothenberger]

With the 20110729 snapshot (and some earlier ones), the following
command terminates early.

% find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
-maxdepth 1 -print

strace lists an exception: "exception C005 at 6100296A". This is
occurring for me in both Win7 x64 and WinXP x86. It doesn't occur in
either environment using 1.7.9.

-- 
David Rothenberger    daver...@acm.org

Mad, adj.:
Affected with a high degree of intellectual independence ...
-- Ambrose Bierce, "The Devil's Dictionary"

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Portable shell code between Cygwin and Linux

[Sebastien Vauban]

Hello,

For every shell code that I write, I'd like it to be portable both to Cygwin
on Windows, and to Ubuntu Linux for example.

It's kinda possible, but am blocked with such a use case:

alias vpnup='exec sudo openvpn --config ~/config/client.vpn --writepid 
/tmp/openvpn.pid &'

While this worked perfectly under Ubuntu, I've had to make up a customized
version for Windows:

alias vpnupwin='cd c:/home/sva/config; openvpn --config client.vpn --writepid 
c:/cygwin/tmp/openvpn.pid &'

Here, I cd first to my config file, as I removed full paths from client.vpn
config file:

,
| ## client.vpn --- client-side OpenVPN config file
| 
| # SSL/TLS parms.
| ca ca.crt
| cert fni.crt
| key fni.key
`

instead of:

,
| ## client.vpn --- client-side OpenVPN config file
| 
| # SSL/TLS parms.
| ca /home/sva/config/ca.crt
| cert /home/sva/config/fni.crt
| key /home/sva/config/fni.key
`

I'm aware of cygpath, but still don't see clearly which are the best trade-off
to be able to write portable shell code -- if possible. Any hint?

Best regards,
  Seb

-- 
Sebastien Vauban


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

socklen_t type

[Eric Blake]

Is there any specific reason why socklen_t on cygwin is int instead of 
uint32_t, like it is on Linux?


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Portable shell code between Cygwin and Linux

[Larry Hall (Cygwin)]

On 7/29/2011 9:42 AM, Sebastien Vauban wrote:




Here, I cd first to my config file, as I removed full paths from client.vpn
config file:





I'm aware of cygpath, but still don't see clearly which are the best trade-off
to be able to write portable shell code -- if possible. Any hint?


Sounds to me like you're using a Windows version of OpenVPN.  You'd need a
version built for Cygwin to make this transparent.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Portable shell code between Cygwin and Linux

[Eliot Moss]

Another way to be portable is to have per-system files
to set up some environment variables and then uniform
portable files that use them. You can do that same
thing *within* a file by writing conditionals or a
case on the result of uname. It's probably best to
segregate per-system stuff in a well-contained file
or section of a file in this way ...

Regards -- Eliot Moss

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Device names in /proc/mounts

[Corinna Vinschen]

On Jul 29 15:34, Schwarz, Konrad wrote:
> > > Can you answer the following question:
> > > 
> > > Given a volume label, how does one figure out where the 
> > corresponding 
> > > volume has been mounted into the Cygwin namespace?
> > 
> > We're not mounting volumes, we're mounting Win32 paths.  
> > There is no direct correspondence between volumes and Cygwin 
> > mount points.
> 
> When a person inserts removable media (USB memory stick, optical disk, ...),
> Windows assigns a more-or-less random drive letter.
> Cygwin automatically makes this drive letter available
> under /cygdrive/ (or whatever the user has renamed /cygdrive to).
> 
> Given a (unique) volume label or disk UUID, blk_id(8) on
> both Linux and Cygwin tells you the disk and partition
> in /dev/sdXY format.

It does?  Interesting.  Where does it get the data under Cygwin?

> In Linux, you can look up the mount point for device /dev/sdXY
> in /proc/mounts or in the output of mount(8).  Thus, given
> a volume label, you can figure out where to access the files
> on the volume.
> 
> How do you do that in Cygwin?

ls /cygdrive.  Insert the disk.  ls /cygdrive again.  There's a new
directory entry now.

Or, open the "Computer" Window on your desktop.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Portable shell code between Cygwin and Linux

[Corinna Vinschen]

On Jul 29 15:42, Sebastien Vauban wrote:
> Hello,
> 
> For every shell code that I write, I'd like it to be portable both to Cygwin
> on Windows, and to Ubuntu Linux for example.
> 
> It's kinda possible, but am blocked with such a use case:
> 
> alias vpnup='exec sudo openvpn --config ~/config/client.vpn --writepid 
> /tmp/openvpn.pid &'
> 
> While this worked perfectly under Ubuntu, I've had to make up a customized
> version for Windows:
> 
> alias vpnupwin='cd c:/home/sva/config; openvpn --config client.vpn --writepid 
> c:/cygwin/tmp/openvpn.pid &'

Don't use Win32 paths.  Use POSIX paths:

  alias vpnupwin='cd /cygdrive/c/home/sva/config; openvpn --config client.vpn 
--writepid /cygdrive/c/cygwin/tmp/openvpn.pid &'


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread error?

[Corinna Vinschen]

On Jul 29 13:29, Jan Chludzinski wrote:
> Can't blame IBM either.  I had to replace pthread_getthreadid_np() (in
> the IBM example code) with pthread_self() because Cygwin doesn't
> support/have pthread_getthreadid_np().

pthread_getthreadid_np is a non-standard IBM extension.  You won't find
it in the POSIX specs.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.10s 20110729 - problem listing services in /proc

[Corinna Vinschen]

On Jul 29 11:58, David Rothenberger wrote:
> With the 20110729 snapshot (and some earlier ones), the following
> command terminates early.
> 
> % find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
> -maxdepth 1 -print
> 
> strace lists an exception: "exception C005 at 6100296A". This is
> occurring for me in both Win7 x64 and WinXP x86. It doesn't occur in
> either environment using 1.7.9.

I can't reproduce this.  Address 6100296A points to a double free on
the cygheap, alternativly an overwritten memeory slot on the cygheap.
Without being able to duplicate the problem it's rather hard to find.
Can you try earlier snapshots to find out in what timeframe this 
problem has been introduced?  An strace might be helpful as well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: socklen_t type

[Corinna Vinschen]

On Jul 29 13:30, Eric Blake wrote:
> Is there any specific reason why socklen_t on cygwin is int instead
> of uint32_t, like it is on Linux?

Other than history?  No, I don't think so.  But I also don't think
it's worth the effort.  All the underlying Windows functions typically
use int rather than uint32_t, and even the Linux man page states:

  The optlen argument of getsockopt() and setsockopt() is in reality an
  int [*] (and this is what 4.x BSD and libc4 and libc5 have).  Some
  POSIX confusion resulted in the present socklen_t, also used by glibc.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Device names in /proc/mounts

[Buchbinder, Barry (NIH/NIAID) [E]]

Schwarz, Konrad sent the following at Friday, July 29, 2011 9:34 AM
>> > Given a volume label, how does one figure out where the
>> corresponding
>> > volume has been mounted into the Cygwin namespace?
>>
>> We're not mounting volumes, we're mounting Win32 paths.
>> There is no direct correspondence between volumes and Cygwin
>> mount points.
>
>When a person inserts removable media (USB memory stick, optical disk,
>...), Windows assigns a more-or-less random drive letter. Cygwin
>automatically makes this drive letter available under /cygdrive/ (or
>whatever the user has renamed /cygdrive to).
>
>Given a (unique) volume label or disk UUID, blk_id(8) on both Linux and
>Cygwin tells you the disk and partition in /dev/sdXY format.
>
>In Linux, you can look up the mount point for device /dev/sdXY in
>/proc/mounts or in the output of mount(8). Thus, given a volume label,
>you can figure out where to access the files on the volume.
>
>How do you do that in Cygwin?

One could use a windows tool to get the volume.  Here is a possible start.

/c> echo '
n' | cmd /c label h:
Volume in drive H: is CIFS.HOMEDIR
Volume label (ENTER for none)?

Delete current volume label (Y/N)? n
/c>

Good luck.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: socklen_t type

[Yaakov (Cygwin/X)]

On Fri, 2011-07-29 at 22:23 +0200, Corinna Vinschen wrote:
> On Jul 29 13:30, Eric Blake wrote:
> > Is there any specific reason why socklen_t on cygwin is int instead
> > of uint32_t, like it is on Linux?
> 
> Other than history?  No, I don't think so.  But I also don't think
> it's worth the effort.  All the underlying Windows functions typically
> use int rather than uint32_t, and even the Linux man page states:
> 
>   The optlen argument of getsockopt() and setsockopt() is in reality an
>   int [*] (and this is what 4.x BSD and libc4 and libc5 have).  Some
>   POSIX confusion resulted in the present socklen_t, also used by glibc.

FWIW, I am aware of the following packages which are affected by the
difference:

kdebase-runtime
libgcrypt
libunique

But POSIX says[1]:

> The  header shall define the socklen_t type, which is an
> integer type of width of at least 32 bits...
> 
> To forestall portability problems, it is recommended that applications
> not use values larger than 2^31 -1 for the socklen_t type.

That would seem to allow either 'uint32_t' or 'int', so we're not wrong,
and its the aforementioned applications' fault for making Linux
assumptions.


Yaakov

[1]
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.10s 20110729 - problem listing services in /proc

[Yaakov (Cygwin/X)]

On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
> On Jul 29 11:58, David Rothenberger wrote:
> > With the 20110729 snapshot (and some earlier ones), the following
> > command terminates early.
> > 
> > % find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
> > -maxdepth 1 -print
> > 
> > strace lists an exception: "exception C005 at 6100296A". This is
> > occurring for me in both Win7 x64 and WinXP x86. It doesn't occur in
> > either environment using 1.7.9.
> 
> I can't reproduce this.  Address 6100296A points to a double free on
> the cygheap, alternativly an overwritten memeory slot on the cygheap.
> Without being able to duplicate the problem it's rather hard to find.
> Can you try earlier snapshots to find out in what timeframe this 
> problem has been introduced?  An strace might be helpful as well.

I did have C005 exceptions with the 20110729 snapshot with seemingly
all fork() calls, which I don't have with 1.7.9.  I'm running Win7 SP1
x64 with large-address-aware executables and DLLs rebased above
0x8000.  I won't be able to diagnose this further until after the
weekend.


Yaakov



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.10s 20110729 - problem listing services in /proc

[David Rothenberger]

On 7/29/2011 3:36 PM, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
>> On Jul 29 11:58, David Rothenberger wrote:
>>> With the 20110729 snapshot (and some earlier ones), the following
>>> command terminates early.
>>>
>>> % find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
>>> -maxdepth 1 -print
>>>
>>> strace lists an exception: "exception C005 at 6100296A". This is
>>> occurring for me in both Win7 x64 and WinXP x86. It doesn't occur in
>>> either environment using 1.7.9.
>>
>> I can't reproduce this.  Address 6100296A points to a double free on
>> the cygheap, alternativly an overwritten memeory slot on the cygheap.
>> Without being able to duplicate the problem it's rather hard to find.
>> Can you try earlier snapshots to find out in what timeframe this 
>> problem has been introduced?  An strace might be helpful as well.
> 
> I did have C005 exceptions with the 20110729 snapshot with seemingly
> all fork() calls, which I don't have with 1.7.9.  I'm running Win7 SP1
> x64 with large-address-aware executables and DLLs rebased above
> 0x8000.  I won't be able to diagnose this further until after the
> weekend.

For what it's worth, I was also running the 20110729 snapshot on Win7
SP1 x64 with large-address-aware executables and DLLs rebased above
0x8000, and this was the only regular problem I was seeing.

-- 
David Rothenberger    daver...@acm.org

File cabinet:
A four drawer, manually activated trash compactor.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Device names in /proc/mounts

[Christopher Faylor]

On Fri, Jul 29, 2011 at 10:15:56PM +0200, Corinna Vinschen wrote:
>On Jul 29 15:34, Schwarz, Konrad wrote:
>> > > Can you answer the following question:
>> > > 
>> > > Given a volume label, how does one figure out where the 
>> > corresponding 
>> > > volume has been mounted into the Cygwin namespace?
>> > 
>> > We're not mounting volumes, we're mounting Win32 paths.  
>> > There is no direct correspondence between volumes and Cygwin 
>> > mount points.
>> 
>> When a person inserts removable media (USB memory stick, optical disk, ...),
>> Windows assigns a more-or-less random drive letter.
>> Cygwin automatically makes this drive letter available
>> under /cygdrive/ (or whatever the user has renamed /cygdrive to).
>> 
>> Given a (unique) volume label or disk UUID, blk_id(8) on
>> both Linux and Cygwin tells you the disk and partition
>> in /dev/sdXY format.
>
>It does?  Interesting.  Where does it get the data under Cygwin?

Huh.  On my system blk_id(8) says "command not found".  And,

http://cygwin.com/cgi-bin2/package-grep.cgi?grep=blk_id

says "Found 0 matches for blk_id"

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.10s 20110729 - problem listing services in /proc

[jojelino]

Starting program: /usr/bin/find 
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
-maxdepth 1 -print

[New Thread 4648.0xd38]
warning: section .gnu_debuglink not found in 
/cygdrive/d/cygwin/bin/cygwin1.dbg

[New Thread 4648.0x16d8]

Breakpoint 9, fhandler_base::operator= (this=0x612cab6c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612ca914
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cab6c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612ca914
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cae5c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612cab6c
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cb424, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_disk_file *) 0x612cb124
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
(gdb) disp this->value_name
8: this->value_name = 0x0
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 1, fhandler_registry::open (this=0x612cb124, flags=0x30c000,
mode=0x0) at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:824
824   if (flags & O_APPEND)
(gdb) disp this->value_name
9: this->value_name = 0x612cb374 L"services"
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cba5c)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cba5c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_registry *) 0x612cb124
(gdb)
Continuing.

now 0x612cb124->value_name = 0x612cba5c->value_name 0x612cb374 L"services"
owner 0x612cba5c not freed value_name

Breakpoint 2, fhandler_registry::close (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:856
856   cfree (value_name);
(gdb) disp this->value_name
10: this->value_name = 0x612cb374 L"services"
(gdb) c
Continuing.

0x612cb124->value_name = 0x612cba5c->value_name 0x612cb374 L"services"
0x612cb124 freed value_name. but it was not owner.
owner 0x612cba5c not freed value_name

Breakpoint 3, fhandler_registry::close (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:860
860 }
10: this->value_name = 0x0
(gdb)
Continuing.

0x612cb124->value_name = 0
0x612cba5c->value_name 0x612cb374 L"services"
0x612cb124 freed value_name. but it was not owner.
owner 0x612cba5c not freed value_name

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cb124, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_registry *) 0x612cba5c
(gdb)
Continuing.

0x612cb124_2->value_name = 0x612cba5c->value_name 0x612cb374 L"services" 
(freed but known as not freed)


Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cbd94)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cbd94)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cba5c)
at /tmp/winsup/winsup/cygwin/fhandler_re

Re: 1.7.10s 20110729 - problem listing services in /proc

[Christopher Faylor]

On Fri, Jul 29, 2011 at 03:41:46PM -0700, David Rothenberger wrote:
>On 7/29/2011 3:36 PM, Yaakov (Cygwin/X) wrote:
>> On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
>>> On Jul 29 11:58, David Rothenberger wrote:
>>>> With the 20110729 snapshot (and some earlier ones), the following
>>>> command terminates early.
>>>>
>>>> % find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
>>>> -maxdepth 1 -print
>>>>
>>>> strace lists an exception: "exception C005 at 6100296A". This is
>>>> occurring for me in both Win7 x64 and WinXP x86. It doesn't occur in
>>>> either environment using 1.7.9.
>>>
>>> I can't reproduce this.  Address 6100296A points to a double free on
>>> the cygheap, alternativly an overwritten memeory slot on the cygheap.
>>> Without being able to duplicate the problem it's rather hard to find.
>>> Can you try earlier snapshots to find out in what timeframe this 
>>> problem has been introduced?  An strace might be helpful as well.
>> 
>> I did have C005 exceptions with the 20110729 snapshot with seemingly
>> all fork() calls, which I don't have with 1.7.9.  I'm running Win7 SP1
>> x64 with large-address-aware executables and DLLs rebased above
>> 0x8000.  I won't be able to diagnose this further until after the
>> weekend.
>
>For what it's worth, I was also running the 20110729 snapshot on Win7
>SP1 x64 with large-address-aware executables and DLLs rebased above
>0x8000, and this was the only regular problem I was seeing.

I don't see this on either XP x86 or WIN 7 x86_64.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple