Re: perl - segfault on "free unused scalar"
Igor Pechtchanski wrote: On Thu, 28 Jul 2005, Krzysztof Duleba wrote: I am not. I understand that this is how it should work theoretically, but I've _checked_ that on a couple of Cygwin boxes with different versions of cygwin1.dll and gcc. All of them didn't really care that heap_chunk_in_mb was undefined in the registry. Perl, on the other hand, do care. Actually, you're right. Perhaps it depends on what kind of malloc the program uses (i.e., whether it uses the Cygwin builtin malloc, or something else). That's strange. How could Perl use something essentially different than malloc? I thought it would all come down to brk or sbrk. Krzysztof Duleba -- 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/
RE: ps -p
> That's not good enough for scripting.
An expectation of complete congruence Unix <> Cygwin seems unrealistically
high to me. I've got a few scripts incorporating a branch as follows
#! /bin/sh
if [ -d c:/ ]
then
{Cygwin stuff}
else
{Unix equivalent}
fi
but the number of such scripts is quite tiny, relatively speaking (about 4
in 100).
Fergus
--
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/
Re: perl - segfault on "free unused scalar"
Krzysztof Duleba wrote: Igor Pechtchanski wrote: Actually, you're right. Perhaps it depends on what kind of malloc the program uses (i.e., whether it uses the Cygwin builtin malloc, or something else). That's strange. How could Perl use something essentially different than malloc? I thought it would all come down to brk or sbrk. Perl has its own malloc implementation. Gerrit -- =^..^= -- 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/
Re: perl - segfault on "free unused scalar"
Gerrit P. Haase wrote: Krzysztof Duleba wrote: Igor Pechtchanski wrote: Actually, you're right. Perhaps it depends on what kind of malloc the program uses (i.e., whether it uses the Cygwin builtin malloc, or something else). That's strange. How could Perl use something essentially different than malloc? I thought it would all come down to brk or sbrk. Perl has its own malloc implementation. However, it should automatically undefine usemymalloc for configure if usethreads is defined, I'll need to check this. Gerrit -- =^..^= -- 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/
Re: perl - segfault on "free unused scalar"
Gerrit P. Haase wrote: Gerrit P. Haase wrote: Krzysztof Duleba wrote: Igor Pechtchanski wrote: Actually, you're right. Perhaps it depends on what kind of malloc the program uses (i.e., whether it uses the Cygwin builtin malloc, or something else). That's strange. How could Perl use something essentially different than malloc? I thought it would all come down to brk or sbrk. Perl has its own malloc implementation. However, it should automatically undefine usemymalloc for configure if usethreads is defined, I'll need to check this. Hmmm, no it isn't, see perl -V: ... usemymalloc=y ... Now that I'm thinking about it it is just multiplicity which is defined when building with threads. I'll try to build with the system malloc to see if it makes a difference. Gerrit -- =^..^= -- 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/
Re: suggestions for cygwin developers
Alex Goldman wrote: When Cygwin gets set up, it would be more user-friendly if it placed two icons on the desktop: one should start maximized Rxvt; another should start X with a couple of xterms or whatever. First-time users might think that the MS-DOS terminal is as good as it gets, and this is not good for Cygwin. Others still have to figure out how to start Rxvt automatically and how to configure it to look pretty. Also, it would be neat to be able to keep Cygwin up-to-date automatically. How about a prompt when a new Cygwin DLL version is available: A new version of Cygwin is available. Run setup to install the latest version. This could be included as part of the /etc/profile or something. Chris -- 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/
Re: suggestions for cygwin developers
Chris January wrote:
Alex Goldman wrote:
When Cygwin gets set up, it would be more user-friendly if it placed
two icons on the desktop:
one should start maximized Rxvt; another should start X with a couple
of xterms or whatever.
First-time users might think that the MS-DOS terminal is as good as it
gets, and this is not good for Cygwin. Others still have to figure out
how to start Rxvt automatically and how to configure it to look
pretty.
Also, it would be neat to be able to keep Cygwin up-to-date
automatically.
How about a prompt when a new Cygwin DLL version is available:
A new version of Cygwin is available. Run setup to install the latest
version.
This could be included as part of the /etc/profile or something.
Chris
Checking to see if a new version available assumes an internet connection.
My opinion is that this would play havoc with dial-up users.
If this is something you want, here is a hack to accomplish it.
I'm sure there are better, cleaner ways to do this and it will break
as soon as something in the package list changes, but it's 5 am
and I am not ready to think yet.
#!/bin/bash
#Igor's whichpkg
function whichpkg() {
wget -qO- "http://cygwin.com/cgi-bin2/package-grep.cgi?grep=$1"; | \
sed -ne '/Cygwin Package List/,${s###g;p}'
}
LATEST=`whichpkg cygwin | grep "emulation" | tail -1 | awk -F "-"
'{print $2}'`
CUR=`uname -a | awk '{print $3}' | awk -F"(" '{print $1}'`
if [ $CUR != $LATEST ]; then
echo "new cygwin dll version "$LATEST" available"
else
echo "Your cygwin dll is current"
fi
--
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/
RE: GConf2 and clear fork bomb on x64
> -Original Message- > From: Gerrit P. Haase [mailto:[EMAIL PROTECTED] > Sent: 28 July 2005 00:26 > To: Oliver Walsh > Cc: cygwin@cygwin.com > Subject: Re: GConf2 and clear fork bomb on x64 > > Oliver Walsh wrote: > > > Hi all, > > > > On Windows Server 2003 64bit, clear.exe and gconftool-2.exe are fork > > bombing. I downloaded and installed cygwin yesterday. > > > > If I build the executables from source (on XP 32bit, cygwin > > 1.5.12-1) then they both run fine. > > > > Any ideas about what's going on? > > What is the actual error message? Probably a rebase problem? Have you > tried to run rebaseall? > > > Gerrit > -- > =^..^= There is no error, it fork bombs ie I get 4000 gconftool-2 processes. strace doesn't output anything Ollie -- 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/
Re: GConf2 and clear fork bomb on x64
Oliver Walsh wrote: tried to run rebaseall? ? There is no error, it fork bombs ie I get 4000 gconftool-2 processes. strace doesn't output anything The same with clear? Interesting ;) Would you please attach the output of cygcheck -svr? Gerrit -- =^..^= -- 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/
Re: rebaseall failure?
Doug, Please keep your replies on-list. On Wed, Jul 27, 2005 at 05:16:06PM -0400, Doug Philips wrote: > On Wednesday, July 27, 2005, at 04:50PM, Jason Tishler indited: > >Either restored the symlink or change the trigger line to: > > > >#!/bin/ash > > Huh? Sorry, my information is a little dated -- I'm still using grep-2.5-1. > [snip] > > Is this a bug in setup, the grep package, or ??? ??? See above. :,) Anyway, see my next post... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: rebaseall failure?
On Wed, Jul 27, 2005 at 09:52:40PM +, Eric Blake wrote: > > The sleep gave the sh.exe process time to exit. You "fixed" it but > > in an open-loop way that is still prone to failure. > > Why not patch rebaseall to invoke 'grep -E' instead of 'egrep'? Yes. Just to be safe, I'll take care of the zcat reference too. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
Doug, On Wed, Jul 27, 2005 at 10:38:44PM -0400, Douglas Philips wrote: > On Jul 27, 2005, at 7:29 PM, Christopher Faylor wrote: > >semaphore::_trywait doesn't have anything to do with pthread > >mutexes, AFAIK. > > I don't know. When I saw the Python message it seemed plausible. > > The real issue is that Python broke with 1.5.18, either because of > the pthread change or not. > Be that as it may, should I report this bug in another forum? No, this is the right mailing list. However, you can increase the probability of it getting fixed by helping to isolate the problem. Besides submitting a patch, a minimal C test case is the best way to go. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: rebaseall failure?
On Wed, Jul 27, 2005 at 06:45:29PM -0400, Igor Pechtchanski wrote: > No bug. It *is* a script (at least in binary tarball of grep). I > don't know where Jason's symlink came from. An older grep package. > Jason, is your "grep" package up-to-date? No. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
OT: seeking opinions
I'm moving from a very technical slot to a unix manager slot. I have done the tech thing for so long I know how to find answers and put solutions together to make things work. I'm seeking everyone's opinion on getting a laptop for this new slot. The laptop would run windoze (must communication with the rest of the company) and is for the purpose of tracking documents, proposals, notes, tasks, ideas, schedules. Also for preparing all of the above things. Oh, and taking notes in meetings, etc. I would also use it to search through the documents for things. I think I would rather use a wiki than word :(, but must still communicate with the rest of the company. I would also load all of cygwin on it so I still have my dev tools that I am most comfortable with, and so I can reach the unix servers. It would have wireless so I can move about the house, to the library, etc., to get things done. Does this make sense what I'm trying to achieve? Is a laptop reasonable for this (though expensive, ~$900 USD), or should I keep with my desktops at home and work? Mike -- 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/
Re: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
On Jul 28, 2005, at 8:48 AM, Jason Tishler wrote: Doug, I don't know. When I saw the Python message it seemed plausible. The real issue is that Python broke with 1.5.18, either because of the pthread change or not. Be that as it may, should I report this bug in another forum? No, this is the right mailing list. However, you can increase the probability of it getting fixed by helping to isolate the problem. That's why I culled down my large application to a small Python script which exhibited the bug and which I submitted to the list, along with my cygcheck -srv and the error messages that Python gave me. Besides submitting a patch, a minimal C test case is the best way to go. ??? A minimal C test case for a python bug... I'm confused. I will submit my tbp (in a different form) to the official python release for inclusion in their self-tests, and hopefully that'll prevent _this_ bug from showing up further, whether on Cygwin or some other platform... --Doug -- 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/
Re: suggestions for cygwin developers
On Thu, 28 Jul 2005, Ken Dibble wrote:
> Chris January wrote:
>
> > Alex Goldman wrote:
> >
> > > When Cygwin gets set up, it would be more user-friendly if it placed
> > > two icons on the desktop:
> > > one should start maximized Rxvt; another should start X with a
> > > couple of xterms or whatever.
> > > First-time users might think that the MS-DOS terminal is as good as
> > > it gets, and this is not good for Cygwin. Others still have to
> > > figure out how to start Rxvt automatically and how to configure it
> > > to look pretty.
> > >
> > > Also, it would be neat to be able to keep Cygwin up-to-date
> > > automatically.
> >
> > How about a prompt when a new Cygwin DLL version is available:
> >
> > A new version of Cygwin is available. Run setup to install the latest
> > version.
> >
> > This could be included as part of the /etc/profile or something.
> >
> > Chris
>
> Checking to see if a new version available assumes an internet
> connection. My opinion is that this would play havoc with dial-up users.
Agreed. I would guess it could be a small service (a nice implementation
would even put an icon in the system tray).
> If this is something you want, here is a hack to accomplish it.
> I'm sure there are better, cleaner ways to do this and it will break
> as soon as something in the package list changes, but it's 5 am
> and I am not ready to think yet.
While the effort of actually writing code at 5am is commendable
(especially since you said "yet" -- the only time you'd see *me* writing
code at 5am is if I'd been doing it all night :-) ), the code below does
do some wasteful things.
> #!/bin/bash
>
> #Igor's whichpkg
> function whichpkg() {
> wget -qO- "http://cygwin.com/cgi-bin2/package-grep.cgi?grep=$1"; | \
>sed -ne '/Cygwin Package List/,${s###g;p}'
> }
You could also simply 'wget -qO- "http://cygwin.com/packages/cygwin";' and
find the last line that starts with "cygwin". That would be *wa-ay*
faster.
> LATEST=`whichpkg cygwin | grep "emulation" | tail -1 | awk -F "-" '{print
> $2}'`
Even if you do use the "whichpkg" above, it's probably better to search
for 'cygwin1\.dll'... :-)
Besides, this would lose the Cygwin-specific release number.
> CUR=`uname -a | awk '{print $3}' | awk -F"(" '{print $1}'`
CUR=`uname -r | awk -F"(" '{print $1}'`
or
CUR=`cygcheck -cd cygwin | sed -ne 's/^cygwin\s\+// p'`
Both will not do the right thing if you have a snapshot installed. You'll
have to think about what exactly the "right thing" is in this case.
> if [ $CUR != $LATEST ]; then
> echo "new cygwin dll version "$LATEST" available"
> else
> echo "Your cygwin dll is current"
> fi
Again, you need to also deal with snapshots.
But if this were written in C, run as a service, and extended to all
installed packages, it could be the beginning of something useful. :-)
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
--
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/
RE: suggestions for cygwin developers
Original Message
>From: Ken Dibble
>Sent: 28 July 2005 11:48
> Checking to see if a new version available assumes an internet connection.
> My opinion is that this would play havoc with dial-up users.
Besides, who wants cygwin to phone home? That's waaay too much like
windoze!
> If this is something you want, here is a hack to accomplish it.
> I'm sure there are better, cleaner ways to do this and it will break
> as soon as something in the package list changes, but it's 5 am
> and I am not ready to think yet.
>
> #!/bin/bash
>
> #Igor's whichpkg
> function whichpkg() {
> wget -qO- "http://cygwin.com/cgi-bin2/package-grep.cgi?grep=$1"; | \
> sed -ne '/Cygwin Package List/,${s###g;p}'
> }
>
> LATEST=`whichpkg cygwin | grep "emulation" | tail -1 | awk -F "-"
> '{print $2}'`
> CUR=`uname -a | awk '{print $3}' | awk -F"(" '{print $1}'`
> if [ $CUR != $LATEST ]; then
> echo "new cygwin dll version "$LATEST" available"
> else
> echo "Your cygwin dll is current"
> fi
Here's my hack, which extracts LATEST from the cygwin.com frontpage list
of dll release announcements:
LATEST=`wget -q -O - http://cygwin.com/ | grep "New Cygwin DLL" | sed -e
's/^.*New Cygwin DLL \([0-9.-_]*\).*$/\1/' | head -1`
...after that you'd set CUR and compare them in the same way.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
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/
Bug identified [was RE: perl - segfault on "free unused scalar"]
Original Message
>From: Krzysztof Duleba
>Sent: 28 July 2005 08:00
> Igor Pechtchanski wrote:
>> On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
>>
>>> I am not. I understand that this is how it should work theoretically,
>>> but I've _checked_ that on a couple of Cygwin boxes with different
>>> versions of cygwin1.dll and gcc. All of them didn't really care that
>>> heap_chunk_in_mb was undefined in the registry. Perl, on the other hand,
>>> do care.
>>
>> Actually, you're right. Perhaps it depends on what kind of malloc the
>> program uses (i.e., whether it uses the Cygwin builtin malloc, or
>> something else).
>
> That's strange. How could Perl use something essentially different than
> malloc? I thought it would all come down to brk or sbrk.
>
> Krzysztof Duleba
There's a real bug here. I think it could be a consequence of the recent
cygload changes, but OTOH it could have already been there: I haven't looked
at the details of that patch, or the cvs history of that part of the code,
but we're in the same area. Here's how it goes:
Regardless of their malloc implementations, Perl and C both rely on
Cygwin's sbrk(...) implementation. The code that grows the heap looks like
this:
if ((VirtualAlloc (cygheap->user_heap.top, newbrksize, MEM_RESERVE,
PAGE_NOACCESS)
|| VirtualAlloc (cygheap->user_heap.top, newbrksize = commitbytes,
MEM_RESERVE, PAGE_NOACCESS))
&& VirtualAlloc (cygheap->user_heap.top, commitbytes, MEM_COMMIT,
PAGE_READWRITE) != NULL)
{
cygheap->user_heap.max = (char *) cygheap->user_heap.max + pround
(newbrksize);
goto good;
}
Here, cygwin is trying to extend the heap by allocating the maximum of
(requested size, heap_chunk_in_mb) bytes of memory contiguously to the end
of the current heap (or the minimum of the two if that fails), and it is
this that is failing in the perl case, and succeeding in the case of
compiled C code; I stepped through it in insight and watched the calls fail.
This must be because there is something allocated by perl that fragments the
process' memory map that isn't allocated when running a C program.
I've been on the track of it. By running that perl example
perl -e '$a="a"x(200 * 1024 * 1024);'
under windbg, and breakpointing VirtualAlloc, I was able to intercept the
call that tries to extend the heap: here's the stack, showing the args to
the function call
0:000> dd esp
0022eba0 204d6000 10001000 2000 0001
0022ebb0 101255f0 10243bdc 0022ec78 0022eb90
0022ebc0 100017ff 304d7000 0003
and here's what the output from !vadump showed in that area:
BaseAddress: 204d6000
RegionSize:07c6a000
State: 2000 MEM_RESERVE
Type: 0002 MEM_PRIVATE
BaseAddress: 2814
RegionSize:1000
State: 1000 MEM_COMMIT
Protect: 0004 PAGE_READWRITE
Type: 0002 MEM_PRIVATE
BaseAddress: 28141000
RegionSize:37ebf000
State: 0001 MEM_FREE
Protect: 0001 PAGE_NOACCESS
clearly showing that there's ~900meg of contiguous free space after the heap
except for a single page allocated at 0x2814, thus preventing it from
growing any larger than (0x2814 - 0x204d6000) ~= 125meg.
So, rerunning the example under insight again, I breakpointed
VirtualAlloc, and looked for a call that was allocating a small amount of
memory at some address beginning 0x2???. Here's what I found:
(gdb) c
Continuing.
Breakpoint 7, 0x77e7abc5 in VirtualAlloc () from
/win/c/WINDOWS/system32/kernel32.dll
(gdb) x/32xw $esp+4
0x22f82c: 0x2814 0x013c 0x2000 0x0004
0x22f83c: 0x00240178 0x002429e0 0x77fa88f0 0x0001
0x22f84c: 0x 0x7ffde000 0x001c 0x610f2350
0x22f85c: 0x2814 0x 0x 0x37ec
0x22f86c: 0x0001 0x0001 0x 0x00401088
0x22f87c: 0x 0x1000 0x0001 0x7ffe
0x22f88c: 0x0001 0x0001 0x024a 0x0001
0x22f89c: 0x0209000f 0x 0x002429d8 0x0024
(gdb) bt
#0 0x77e7abc5 in VirtualAlloc () from /win/c/WINDOWS/system32/kernel32.dll
#1 0x61010b29 in dll_list::alloc (this=0x610f2350, h=0x1000,
p=0x10125520, type=DLL_LINK) at /usr/build/src/winsup/cygwin/dll_init.cc:147
#2 0x6101110a in dll_dllcrt0 (h=0x1000, p=0x10125520) at
/usr/build/src/winsup/cygwin/dll_init.cc:382
#3 0x10108e78 in init_os_extras () from /usr/bin/cygperl5_8.dll
#4 0x77f5b42c in ntdl
Re: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
On Thu, 28 Jul 2005, Douglas Philips wrote: > On Jul 28, 2005, at 8:48 AM, Jason Tishler wrote: > > > Doug, > > > I don't know. When I saw the Python message it seemed plausible. > > > > > > The real issue is that Python broke with 1.5.18, either because of > > > the pthread change or not. > > > Be that as it may, should I report this bug in another forum? > > > > No, this is the right mailing list. However, you can increase the > > probability of it getting fixed by helping to isolate the problem. > > That's why I culled down my large application to a small Python script > which exhibited the bug and which I submitted to the list, along with my > cygcheck -srv and the error messages that Python gave me. So your test case is currently a small Python script, plus *all* of Python. I'm not downplaying your effort in producing the test case, just explaining Jason's statement about "isolating the problem". > > Besides submitting a patch, a minimal C test case is the best way to > > go. > > ??? A minimal C test case for a python bug... I'm confused. Python is written in C. Since the bug is to be fixed in Python, isolating the part of the C code that exhibits the problem would help fixing the bug. > I will submit my tbp (in a different form) to the official python > release for inclusion in their self-tests, and hopefully that'll prevent > _this_ bug from showing up further, whether on Cygwin or some other > platform... Yep, that's why it's good to have the small Python test case as well. :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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/
Re: suggestions for cygwin developers
Igor Pechtchanski wrote:
On Thu, 28 Jul 2005, Ken Dibble wrote:
Chris January wrote:
Alex Goldman wrote:
When Cygwin gets set up, it would be more user-friendly if it placed
two icons on the desktop:
one should start maximized Rxvt; another should start X with a
couple of xterms or whatever.
First-time users might think that the MS-DOS terminal is as good as
it gets, and this is not good for Cygwin. Others still have to
figure out how to start Rxvt automatically and how to configure it
to look pretty.
Also, it would be neat to be able to keep Cygwin up-to-date
automatically.
How about a prompt when a new Cygwin DLL version is available:
A new version of Cygwin is available. Run setup to install the latest
version.
This could be included as part of the /etc/profile or something.
Chris
Checking to see if a new version available assumes an internet
connection. My opinion is that this would play havoc with dial-up users.
Agreed. I would guess it could be a small service (a nice implementation
would even put an icon in the system tray).
If this is something you want, here is a hack to accomplish it.
I'm sure there are better, cleaner ways to do this and it will break
as soon as something in the package list changes, but it's 5 am
and I am not ready to think yet.
While the effort of actually writing code at 5am is commendable
(especially since you said "yet" -- the only time you'd see *me* writing
code at 5am is if I'd been doing it all night :-) ), the code below does
do some wasteful things.
#!/bin/bash
#Igor's whichpkg
function whichpkg() {
wget -qO- "http://cygwin.com/cgi-bin2/package-grep.cgi?grep=$1"; | \
sed -ne '/Cygwin Package List/,${s###g;p}'
}
You could also simply 'wget -qO- "http://cygwin.com/packages/cygwin";' and
find the last line that starts with "cygwin". That would be *wa-ay*
faster.
LATEST=`whichpkg cygwin | grep "emulation" | tail -1 | awk -F "-" '{print $2}'`
Even if you do use the "whichpkg" above, it's probably better to search
for 'cygwin1\.dll'... :-)
Besides, this would lose the Cygwin-specific release number.
CUR=`uname -a | awk '{print $3}' | awk -F"(" '{print $1}'`
CUR=`uname -r | awk -F"(" '{print $1}'`
or
CUR=`cygcheck -cd cygwin | sed -ne 's/^cygwin\s\+// p'`
Both will not do the right thing if you have a snapshot installed. You'll
have to think about what exactly the "right thing" is in this case.
if [ $CUR != $LATEST ]; then
echo "new cygwin dll version "$LATEST" available"
else
echo "Your cygwin dll is current"
fi
Again, you need to also deal with snapshots.
But if this were written in C, run as a service, and extended to all
installed packages, it could be the beginning of something useful. :-)
Igor
Yes, I know it was wasteful. I guess I failed to make my point.
OPINION: I don't believe in having the latest and greatest of
everything. I believe
in STABLE ( as anyone who has looked at my cygcheck
will attest).
So, like I said, I really don't think something
like this belongs in cygwin proper.
POINT: I can see the downside to this and have great reservations.
But if YOU must have this, it shouldn't be too hard for
YOU to do it.
YMMV.
Igor, Thanks for continuing to enlighten me about the myriad of ways of
doing things.
Regards,
Ken
--
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/
RE: GConf2 and clear fork bomb on x64
> -Original Message- > From: Gerrit P. Haase [mailto:[EMAIL PROTECTED] > Sent: 28 July 2005 13:31 > To: Oliver Walsh > Cc: cygwin@cygwin.com > Subject: Re: GConf2 and clear fork bomb on x64 > > Oliver Walsh wrote: > > >>tried to run rebaseall? > > ? > > > > There is no error, it fork bombs ie I get 4000 gconftool-2 processes. > > > > strace doesn't output anything > > The same with clear? Interesting ;) > > Would you please attach the output of cygcheck -svr? > > > Gerrit > -- > =^..^= Just a though, are there any outstanding issues with fork and hyperthreading/multiprocessor systems? Ollie -- 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/
[ANNOUNCEMENT] Updated: rebase-2.4.2-1
New News: === I have updated the version of rebase to 2.4.2-1. The tarballs should be available on a Cygwin mirror near you shortly. The only notable change (to rebaseall) since the previous release is: * Change zcat to "gzip -d -c" and egrep to "grep -E" to avoid the possibility of invoking a (bash) shell script. Old News: === The Cygwin rebase package contains two utilities, rebase and rebaseall. The first utility is modeled after Microsoft's SDK rebase: http://msdn.microsoft.com/library/en-us/tools/tools/rebase.asp The rebaseall utility is a convenient way for users that suffer from the Cygwin rebase problem to rebase their entire system (i.e., all of their DLLs). Please read the README file: /usr/share/doc/Cygwin/rebase-2.4.2.README since it covers requirements, usage, known issues, etc. I would like to thank Ralf Habacker for providing the imagehelper library. This library has enabled me to create a rebase utility that is usable by all Cygwin user (regardless of platform) on all DLLs (regardless of stripping). Standard News: To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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/
Re: Bug identified [was RE: perl - segfault on "free unused scalar"]
On Thu, 28 Jul 2005, Dave Korn wrote:
> Original Message
> >From: Krzysztof Duleba
> >Sent: 28 July 2005 08:00
>
> > Igor Pechtchanski wrote:
> >> On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> >>
> >>> I am not. I understand that this is how it should work
> >>> theoretically, but I've _checked_ that on a couple of Cygwin boxes
> >>> with different versions of cygwin1.dll and gcc. All of them didn't
> >>> really care that heap_chunk_in_mb was undefined in the registry.
> >>> Perl, on the other hand, do care.
> >>
> >> Actually, you're right. Perhaps it depends on what kind of malloc the
> >> program uses (i.e., whether it uses the Cygwin builtin malloc, or
> >> something else).
> >
> > That's strange. How could Perl use something essentially different than
> > malloc? I thought it would all come down to brk or sbrk.
>
> There's a real bug here. I think it could be a consequence of the
> recent cygload changes, but OTOH it could have already been there: I
> haven't looked at the details of that patch, or the cvs history of that
> part of the code, but we're in the same area. Here's how it goes:
>
> Regardless of their malloc implementations, Perl and C both rely on
> Cygwin's sbrk(...) implementation. The code that grows the heap looks
> like this:
>
>if ((VirtualAlloc (cygheap->user_heap.top, newbrksize, MEM_RESERVE,
> PAGE_NOACCESS)
> || VirtualAlloc (cygheap->user_heap.top, newbrksize = commitbytes,
> MEM_RESERVE, PAGE_NOACCESS))
>&& VirtualAlloc (cygheap->user_heap.top, commitbytes, MEM_COMMIT,
> PAGE_READWRITE) != NULL)
> {
> cygheap->user_heap.max = (char *) cygheap->user_heap.max + pround
> (newbrksize);
> goto good;
> }
>
> Here, cygwin is trying to extend the heap by allocating the maximum of
> (requested size, heap_chunk_in_mb) bytes of memory contiguously to the end
> of the current heap (or the minimum of the two if that fails), and it is
> this that is failing in the perl case, and succeeding in the case of
> compiled C code; I stepped through it in insight and watched the calls fail.
> This must be because there is something allocated by perl that fragments
> the process' memory map that isn't allocated when running a C program.
>
> I've been on the track of it. By running that perl example
>
>
> perl -e '$a="a"x(200 * 1024 * 1024);'
>
>
> under windbg, and breakpointing VirtualAlloc, I was able to intercept the
> call that tries to extend the heap: here's the stack, showing the args to
> the function call
> [snip bug analysis]
> clearly showing that there's ~900meg of contiguous free space after the heap
> except for a single page allocated at 0x2814, thus preventing it from
> growing any larger than (0x2814 - 0x204d6000) ~= 125meg.
Hmm, but shouldn't this code fail regardless of the value of
heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this succeed?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
--
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/
RE: Bug identified [was RE: perl - segfault on "free unused scalar"]
Original Message >From: Igor Pechtchanski >Sent: 28 July 2005 14:58 > Hmm, but shouldn't this code fail regardless of the value of > heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this succeed? Perhaps it only makes it succeed if you increase heap_chunk_in_mb until that initial heap chunk is big enough? Perhaps just because the memory map gets re-arranged and dll_list::alloc manages to find a page in between the dll and the heap? You could always check it out in a debugger if you like; I've got to leave this for the moment because I was doing that in my lunchbreak, which is long over now :-( cheers, DaveK -- Can't think of a witty .sigline today -- 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/
'id' groups listing conflicts w/'net group GROUPNAMEHERE /domain'
The 'id' command indicates user staffuser1 is in group ABC_NA-CTX-Notepad-A. I use this account 'staffuser1', and have no idea what group ABC_NA-CTX-Notepad-A is; I do not think user staffuser1 is really in that group, but you could prove me wrong (how?). This is causing problems in ssh sessions; Pierre A. Humblet supplied me with a workaround: (http://cygwin.com/ml/cygwin/2005-07/msg01287.html). How can we determine if user staffuser1 is or is not in group ABC_NA-CTX-Notepad-A? -- thanks, Tom Rodman console bash session: --v-v--C-U-T---H-E-R-E-v-v-- ~ $ uname -a CYGWIN_NT-5.0 OurServer120 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin ~ $ mkgroup -l -d >/etc/group && echo ok/done ok/done ~ $ id uid=15773(staffuser1) gid=16027(XYZ_ES_STAFF) groups=544(Administrators),545(Users),19858(ABC_NA-CTX-Notepad-A),10513(Domain Users),16026(XYZ_ES_ADMIN),16027(XYZ_ES_STAFF),16024(XYZ_Users) ~ $ cygcheck -s 2>/dev/null|egrep -A4 '^Output from .*id.exe' Output from c:\aut\cyg\bin\id.exe (nontsec) UID: 15773(staffuser1) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 545(Users)19858(ABC_NA-CTX-Notepad-A) 10513(Domain Users) 16026(XYZ_ES_ADMIN) 16027(XYZ_ES_STAFF) 16024(XYZ_Users) -- Output from c:\aut\cyg\bin\id.exe (ntsec) UID: 15773(staffuser1) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 545(Users)19858(ABC_NA-CTX-Notepad-A) 10513(Domain Users) 16026(XYZ_ES_ADMIN) 16027(XYZ_ES_STAFF) 16024(XYZ_Users) ~ $ net group ABC_NA-CTX-Notepad-A /domain |tee /tmp/foo001|egrep -q staffuser1 || echo OOPs OOPs ~ $ wc -l /tmp/foo001 32 /tmp/foo001 -- 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/
Re: OT: seeking opinions
At 09:13 AM 7/28/2005, Mike wrote: >I'm moving from a very technical slot to a unix manager slot. >I have done the tech thing for so long I know how to find answers >and put solutions together to make things work. I'm seeking everyone's >opinion on getting a laptop for this new slot. The laptop would >run windoze (must communication with the rest of the company) and >is for the purpose of tracking documents, proposals, notes, tasks, >ideas, schedules. Also for preparing all of the above things. Oh, >and taking notes in meetings, etc. I would also use it to search >through the documents for things. I think I would rather use a >wiki than word :(, but must still communicate with the rest of >the company. > >I would also load all of cygwin on it so I still have my dev tools >that I am most comfortable with, and so I can reach the unix >servers. > >It would have wireless so I can move about the house, to the library, >etc., to get things done. > >Does this make sense what I'm trying to achieve? >Is a laptop reasonable for this (though expensive, ~$900 USD), >or should I keep with my desktops at home and work? As you note, discussion of this is off-topic for this list. If you want to discuss it further and you feel there is *some* Cygwin relevence, you can move it to the cygwin-talk list, if you can't find a better forum. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
RE: Bug identified [was RE: perl - segfault on "free unused scalar"]
On Thu, 28 Jul 2005, Dave Korn wrote: > Original Message > >From: Igor Pechtchanski > >Sent: 28 July 2005 14:58 > > > Hmm, but shouldn't this code fail regardless of the value of > > heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this > > succeed? > > Perhaps it only makes it succeed if you increase heap_chunk_in_mb > until that initial heap chunk is big enough? Perhaps just because the > memory map gets re-arranged and dll_list::alloc manages to find a page > in between the dll and the heap? You could always check it out in a > debugger if you like; I've got to leave this for the moment because I > was doing that in my lunchbreak, which is long over now :-( Dave, I'm unfortunately not set up to do this kind of debugging ATM (heavy use of Cygwin for real work, and no other available machine, so can't play with heap_chunk_in_mb). That's why I appreciate your doing this. If you are interested in pursuing this later, it would be nice to find out how this behavior relates to the value of heap_chunk_in_mb. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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/
echo $?
I am trying to get my current expect scripts to run with the latest cygwin but am having problems with the cmd-prompt after issuing the command above. After the "echo $?", the expected prompt is returned but with white space before it. I've never seen this before on Windows or Unix. Example: $ echo $? 0 $ The prompt($) has a space before it which is making Expect not recognize it because my script is expecting just "$ " and not " $ ". CYGWIN_NT-5.1 POPCORN 1.5.17(0.129/4/2) 2005-05-25 19:38 i686 unknown unknown Cygwin Any help??? Thanks, Mike -- 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/
RE: echo $?
Original Message >From: Maloney, Michael >Sent: 28 July 2005 17:56 > > Example: > $ echo $? > 0 > $ > > The prompt($) has a space before it > Any help??? WJFFM. What do you see from "echo $? | od -c" ? cheers, DaveK -- Can't think of a witty .sigline today -- 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/
RE: echo $?
$ echo $? | od -c 000 0 \n 002 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn Sent: Thursday, July 28, 2005 1:03 PM To: cygwin@cygwin.com Subject: RE: echo $? Original Message >From: Maloney, Michael >Sent: 28 July 2005 17:56 > > Example: > $ echo $? > 0 > $ > > The prompt($) has a space before it > Any help??? WJFFM. What do you see from "echo $? | od -c" ? cheers, DaveK -- Can't think of a witty .sigline today -- 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/ -- 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/
Re: 'id' groups listing conflicts w/'net group GROUPNAMEHERE /domain'
Tom Rodman wrote: > The 'id' command indicates user staffuser1 is in group ABC_NA-CTX-Notepad-A. > I use this account 'staffuser1', and have no idea what group > ABC_NA-CTX-Notepad-A > is; I do not think user staffuser1 is really in that group, but you could > prove me wrong (how?). > > This is causing problems in ssh sessions; Pierre A. Humblet supplied > me with a workaround: (http://cygwin.com/ml/cygwin/2005-07/msg01287.html). > How can we determine if user staffuser1 is or is not in group > ABC_NA-CTX-Notepad-A? id reports the groups that are in the (Windows) process token, using http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/gettokeninformation.asp Somehow Windows put it there. The fact that net ... does not report it is consistent with your ssh troubles. When ssh asks Windows what groups you are part of, Windows does not include ABC_NA-CTX-Notepad-A However when ssh asks Windows to log you in (giving your password), Windows does include that group in the token. The discrepancy causes ssh to create another token, leading to your access troubles on shared drives. There is a remote chance (I have never observed something like that) that the group is in the token but not "enabled", or that SE_GROUP_USE_FOR_DENY_ONLY is set, or some such, see the special flags in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/token_groups.asp You may also get a clue by looking at the content of your /tmp/foo001 You can easily find out the details by creating a short program using http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcurrentprocess.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/openprocesstoken.asp and gettokeninformation to list the groups in your token and understand what's going on. The group SID can be mapped to a name with http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/lookupaccountsid.asp Do you feel able to do that? Pierre -- 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/
Re: echo $?
> I am trying to get my current expect scripts to run with the latest > cygwin but am having problems with the cmd-prompt after issuing the > command above. After the "echo $?", the expected prompt is returned but > with white space before it. I've never seen this before on Windows or > Unix. > What is your $PS1? And what shell (and version) are you running? There is a known bug in bash-3.0-7 with certain prompts displaying incorrectly, so if expect is postprocessing a screen-capture, I could see the prompt display bug being the cause of your concern. Usually, when post-processing shell output, the shell was not run in interactive mode, so that prompts are not part of the shell output; maybe more information about how you are running expect and why you expect (pardon the pun) to see the prompt as part of the output would also be helpful in diagnosing the problem. Hint - following these directions will help us know more about your setup, to see if anything obvious jumps out with your installed versions. As it is, your uname output mentions cygwin-1.5.17, although 1.5.18 is the latest, so you probably have several out-of-date packages. > Problem reports: http://cygwin.com/problems.html -- Eric Blake volunteer cygwin bash maintainer -- 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/
RE: echo $?
> > C:\>sh -i > sh-3.00$ PS1="$ " > > I also noticed in version 1.5.17 that when executing the shell, the > default prompt changed from "$ " to "sh-3.00$ ". It wasn't the cygwin upgrade, but the bash upgrade that changed your prompt. /bin/sh used to be ash, which defaults to PS1 of '$ ', but is now bash, which defaults to PS1 of '\s-\v\$ '. > > I expect the prompt in my script after a command is issued. It just > indicated that the command has been sent and then I can move on to the > next command. Obviously now, it get's stuck in the middle. > > Hint - following these directions will help us know more about your > setup, to see if anything obvious jumps out with your installed > versions. As it is, your uname output mentions cygwin-1.5.17, although > 1.5.18 is the latest, so you probably have several out-of-date packages. > > I'll download the latest if you think it would help. Well, bash-3.0-7 has a known display bug, and bash-3.0-8 requires cygwin-1.5.18 or newer, so it might help. But your cygcheck.out shows some other problems. First, in Windows, you have SHELL defined as c:\MKS\mksnt\sh.exe, which is NOT the cygwin shell, and may be interfering (although the path search only found c:\cygwin\bin\sh.exe, which is good). Second, you show ash-20040127-1 and bash-2.05b-17, even though your earlier report of the changed prompt would imply that you really have ash-20040127-3 and bash-3.0-7 or newer; I have no idea what is really going on, or if you even attached the correct cygcheck. -- Eric Blake -- 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/
RE: echo $?
Well, For now I just copied an old version of sh in. Is this going to be fixed in future builds? I have the same issue with the .18 build as well. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Blake Sent: Thursday, July 28, 2005 2:04 PM To: Maloney, Michael; cygwin@cygwin.com Subject: RE: echo $? > > C:\>sh -i > sh-3.00$ PS1="$ " > > I also noticed in version 1.5.17 that when executing the shell, the > default prompt changed from "$ " to "sh-3.00$ ". It wasn't the cygwin upgrade, but the bash upgrade that changed your prompt. /bin/sh used to be ash, which defaults to PS1 of '$ ', but is now bash, which defaults to PS1 of '\s-\v\$ '. > > I expect the prompt in my script after a command is issued. It just > indicated that the command has been sent and then I can move on to the > next command. Obviously now, it get's stuck in the middle. > > Hint - following these directions will help us know more about your > setup, to see if anything obvious jumps out with your installed > versions. As it is, your uname output mentions cygwin-1.5.17, although > 1.5.18 is the latest, so you probably have several out-of-date packages. > > I'll download the latest if you think it would help. Well, bash-3.0-7 has a known display bug, and bash-3.0-8 requires cygwin-1.5.18 or newer, so it might help. But your cygcheck.out shows some other problems. First, in Windows, you have SHELL defined as c:\MKS\mksnt\sh.exe, which is NOT the cygwin shell, and may be interfering (although the path search only found c:\cygwin\bin\sh.exe, which is good). Second, you show ash-20040127-1 and bash-2.05b-17, even though your earlier report of the changed prompt would imply that you really have ash-20040127-3 and bash-3.0-7 or newer; I have no idea what is really going on, or if you even attached the correct cygcheck. -- Eric Blake -- 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/ -- 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/
RE: echo $?
Ugh - top-posting. Reformatted. > > > Well, bash-3.0-7 has a known display bug, and bash-3.0-8 requires > > cygwin-1.5.18 or newer, so it might help. But your cygcheck.out > > shows some other problems. First, in Windows, you have SHELL > > defined as c:\MKS\mksnt\sh.exe, which is NOT the cygwin shell, > > and may be interfering (although the path search only found > > c:\cygwin\bin\sh.exe, which is good). Second, you show > > ash-20040127-1 and bash-2.05b-17, even though your earlier > > report of the changed prompt would imply that you really have > > ash-20040127-3 and bash-3.0-7 or newer; I have no idea what > > is really going on, or if you even attached the correct cygcheck. > > Well, For now I just copied an old version of sh in. Is this going to be > fixed in future builds? I have the same issue with the .18 build as > well. To repeat myself, the change in behavior is not due to an upgrade of cygwin to 1.5.18, but due to an upgrade to bash-3.0-x. (Yes, setup.exe upgrades both programs). Also, bash-3.0-8 attempts a workaround to a known display bug present in bash-3.0-7. You have yet to provide an accurate cygcheck.out that lists the true version of bash you are running (even "bash --version" would be helpful, here). And if there really is a bug, it will continue to be present in future bash releases unless you can help reduce it to a reproducible test case. So far, I have been unable to recreate the situation you described. I also wonder if the MKS toolset, installed by some other program, is causing interference with your cygwin installation. -- Eric Blake -- 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/
Re: 'id' groups listing conflicts w/'net group GROUPNAMEHERE /domain'
Thank you again Pierre. I appreciate the increased rights ;->It fixed up more than just the net drive issue, a couple of my database admin commands that were failing, now work again in an ssh session. see comments below -- regards, Tom On Thu 7/28/05 13:22 EDT "Pierre A. Humblet" wrote: > Tom Rodman wrote: > > > The 'id' command indicates user staffuser1 is in group ABC_NA-CTX-Notepad-A. > > I use this account 'staffuser1', and have no idea what group > > ABC_NA-CTX-Notepad-A > > is; I do not think user staffuser1 is really in that group, but you could > > prove me wrong (how?). > > > > This is causing problems in ssh sessions; Pierre A. Humblet supplied > > me with a workaround: (http://cygwin.com/ml/cygwin/2005-07/msg01287.html). > > > How can we determine if user staffuser1 is or is not in group > > ABC_NA-CTX-Notepad-A? > > id reports the groups that are in the (Windows) process token, using > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/gettokeninformation.asp > Somehow Windows put it there. > > The fact that net ... does not report it is consistent with your ssh troubles. > When ssh asks Windows what groups you are part of, Windows does > not include ABC_NA-CTX-Notepad-A > However when ssh asks Windows to log you in (giving your password), > Windows does include that group in the token. The discrepancy causes > ssh to create another token, leading to your access troubles on shared > drives. > > There is a remote chance (I have never observed something like that) that > the group is in the token but not "enabled", or that > SE_GROUP_USE_FOR_DENY_ONLY > is set, or some such, see the special flags in > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/token_groups.asp > You may also get a clue by looking at the content of your /tmp/foo001 The users in /tmp/foo001 mean little to me. I did recognize one person I know out of the ~86 usernames, so maybe I'll talk to him about the group's purpose and human "creator". The domain we're in is large - (many thousands of users), and 'mkpasswd -d -l' fails because it's so large, so I run 'mkpasswd -l', and then individual 'mkpasswd -d -u USERNAME' for our all the end users I support, and cat all these to /etc/passwd in a daily cron job. > > You can easily find out the details by creating a short program using > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcurrentprocess.asp > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/openprocesstoken.asp > and gettokeninformation to list the groups in your token and understand > what's going on. > The group SID can be mapped to a name with > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/lookupaccountsid.asp > Do you feel able to do that? I have not had time to thoughly look at your links, but my hunch is that I will need help writing the program(s) - and that I can get that help here where I work. I will keep the mailing list updated, but I expect it may take awhile; meanwhile I'll use the workaround. -- 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/
RE: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
Christopher Faylor wrote: >>> semaphore::_trywait doesn't have anything to do with pthread >>> mutexes, AFAIK. Douglas Philips wrote: >> The real issue is that Python broke with 1.5.18, either because of >> the pthread change or not. Be that as it may, should I report this >> bug in another forum? Jason Tishler wrote: > No, this is the right mailing list. However, you can increase the > probability of it getting fixed by helping to isolate the problem. > Besides submitting a patch, a minimal C test case is the best > way to go. Please ignore this if it sounds like noise, but I thought at least Jason might be interested. I wasn't following this thread closely since rebaseall had been mentioned, but the semaphore/pthread/Python mix wakened an old memory that I thought I should bring up. Give me a minute while I crank up the old wayback machine... :-) 3 or 4 years ago I introduced a patch into Python thread support that used native semaphores if they are supported. The POSIX way to indicate this is to define _POSIX_SEMAPHORES in a header file, but at the time either Cygwin either didn't define it, defined it in some way differently, or its definition was ignored for some reason (I don't remember the exact details). It was frustrating to me since the reason for my change was to fix Python threading under Cygwin, which was broken at the time, and although the Python developers accepted my change, they would only allow: #ifdef _POSIX_SEMAPHORES and not: #if defined(_POSIX_SEMAPHORES) || defined(__CYGWIN__) Fortunately, somebody else fixed the pthreads threading bug in Cygwin (the lack of an assignment prevented me from doing so), so things progressed without my help. Anyway, I just looked into /usr/include/sys/features.h, and _POSIX_SEMAPHORES is now defined. If we are seeing errors that indict semaphore::_trywait, it seems likely that my code is now being used, although I know that it wasn't being used when I first introduced it into Python. However, features.h does not appear to have changed in a while (at least not according to its comments). :-P Did something change (either in Cygwin or Python) that could explain why Python would have started recognizing that Cygwin supports POSIX semaphores? If so, perhaps that is contributing to the error. I'd poke around myself, but it's been a while since I've been inside either Python or Cygwin internals. On the other hand, I verified at the time that the semaphore solution worked under Cygwin Python, so I wouldn't expect it to be a problem even if the change just took place. However, it could potentially help in isolating the problem. -Jerry -- 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/
Re: Bug identified [was RE: perl - segfault on "free unused scalar"]
Dave, Some comments on your analysis. The latest perl uses auto-image-base and the base address should be different than default. It fails anyway. Perl uses its own malloc, rebuilding with the system malloc shows that it behaves similar than the C examples, I think the recent changes in Cygwin do what they should do: make setting the heap size superflous. I will release another update of perl using the cygwin malloc *now*, there is another problem which is exposed by Test::Harness, so I'll need to update perl anyway to fix Test::Harness. However, feel free to dig deeper if you think that you want to improve cygwin. Gerrit -- =^..^= -- 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/
Regression: (was Re: Ctrl-C not working as well as on Linux)
Christopher Faylor wrote: According to Alex Goldman on 7/21/2005 2:49 AM: On Linux, after I start a program that consumes 100% of CPU time, I can usually terminate it just by typing Ctrl-C. This is very convenient to me as a developer. However, using Cygwin in the same situation, the shell becomes "bash (Not Responding)", and I have to invoke the process manager and kill the process from there. Does anyone know why this happens and what can be done about it? ? CTRL-C should work just fine without CYGWIN=tty. In fact, it should work better than CYGWIN=tty in situations where system time is being consumed by a runaway process. I don't see any reason why either Cygwin or bash should become unresponsive due to a program which consumes CPU. - A bit belatedly to answer this, I know, but I updated my cygwin.dll (among others) about a week ago. Since then I've noticed Control-C doesn't terminate Cygwin programs, promptly, as it used to. No other settings have changed. I'm running "Bash.exe" natively in a standard cmd type window. Control-Break yields the same (non) effect. The problem is greatly noticed wen I do an "ls" on(in) large directories. My ls, is'ed aliased with "-CGF" by default to default select multiple columns, suppress "Group" and classify files by appending (*/=@|) to the entries; as a result, an ls in a large directory can take a while. It used to be the case that 'ls' would terminate immediately when I pressed control-C. Now, it finishes reading all the file information in the directory(a long process), displays the first file, then recognizes thecontrol-C. Previously, it would abort the file reading -- now it is not. I inferred this from the execution time which is a *BIG* indicator. Note the difference between these two "ls" runs on a 3000+ entry directory: /windows/system32> time ls dllcache >/dev/null real0m32.794s user0m0.580s sys 0m2.613s /windows/system32> time ls dllcache >/dev/null real0m0.975s user0m0.300s sys 0m0.621s === After the info is cached, a subsequent ls on the same dir runs significantly faster (~33x (3300%) faster). Since the update a week ago, a control-C on an "ls" takes about 30 seconds to respond. Here's an example with me pressing control-C: === /windows/options/i386> date;time ls Thu Jul 28 14:15:21 PDT 2005 12520437.CP_ real0m56.746s user0m1.422s sys 0m7.550s /windows/options/i386> date Thu Jul 28 14:16:18 PDT 2005 === Note it took over 56 seconds to recover after pressing Control-C. This wasn't the case in prior versions. Perhaps this is why the original poster suddenly noticed the difference in control-C processing time? FYI, my tty settings are as follows: = /> tty /dev/console /> echo $TTY /dev/conin /> echo $CYGWIN notitle glob:ignorecase export == I can provide more info if needed. Linda -- 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/
Re: Bug identified [was RE: perl - segfault on "free unused scalar"]
On Fri, Jul 29, 2005 at 12:16:42AM +0200, Gerrit P. Haase wrote: >Dave, > >Some comments on your analysis. > >The latest perl uses auto-image-base and the base address should be >different than default. It fails anyway. > >Perl uses its own malloc, rebuilding with the system malloc shows >that it behaves similar than the C examples, I think the recent >changes in Cygwin do what they should do: make setting the heap >size superflous. Could someone point to what these changes are that are supposed to make setting the heap size irrelevant? Dave mentioned "cygload". I don't really know what that is, unless it has something to do with the minor changes made to get cygwin somewhat working when loaded dynamically. I'm not really aware of any changes which would make setting the heap size irrelevant. cgf -- 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/
Re: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
On Jul 28, 2005, at 9:49 AM, Igor Pechtchanski wrote: That's why I culled down my large application to a small Python script which exhibited the bug and which I submitted to the list, along with my cygcheck -srv and the error messages that Python gave me. So your test case is currently a small Python script, plus *all* of Python. I'm not downplaying your effort in producing the test case, just explaining Jason's statement about "isolating the problem". If the bug is in Python... which it seems to be since I haven't heard (nor found in the archives with my pitiful searches) of anyone else having a problem. If I take out one of the triplets of Python threads, the problem doesn't seem to manifest. It sure feels to me like trying to guess how much of Python I need to be concerned with is no less of a big problem... I will try to find an even smaller Python program though, that might help. I had sort of hoped to get someone from the cygwin Python port interested, but apparently I'm using Python (on cygwin at least) in a way few others are... ??? A minimal C test case for a python bug... I'm confused. Python is written in C. Since the bug is to be fixed in Python, isolating the part of the C code that exhibits the problem would help fixing the bug. Or maybe it is in the pure Python code making some bogus assumptions about the underlying layers (implemented in C or not)... I will submit my tbp (in a different form) to the official python release for inclusion in their self-tests, and hopefully that'll prevent _this_ bug from showing up further, whether on Cygwin or some other platform.. Yep, that's why it's good to have the small Python test case as well. :-) Igor Thanks, I will be striving to secure an even smaller Python test case, at least to start. :-) --Doug -- 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/
Re: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
On Jul 28, 2005, at 6:02 PM, Williams, Gerald S (Jerry) wrote: On the other hand, I verified at the time that the semaphore solution worked under Cygwin Python, so I wouldn't expect it to be a problem even if the change just took place. However, it could potentially help in isolating the problem. Thanks, I'm interested too, but I won't be looking at it personally until I've produced (or failed to) an even simpler test case... --Doug -- 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/
Re: ps -p
On 7/27/05, Don Beusee wrote: > That's not good enough for scripting. First of all, the command is not so > simple (you have to grep -v grep also - so that the same script works on > Unix systems) and if you have small PID number like 14, that will likely > return lots of other processes (like 114, etc). Also, the same > appears in the PPID column if it has children. Some Unix variants might not > have a space in the ps output between the PID and previous or next column > when one of the column's data is larger than the specified printf format. > > So your command is not reliable enough for scripting and is also very slow > on large Unix systems with 1000's of processes running. ps -p is > immediate, reliable, and portable (it's SYSV/SVR4 standard). There's also always http://cygwin.com/contrib.html -- 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/
