setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Kenneth Wolcott]

Hi;

I think 64bit Cygwin is awesome :-)

FYI: trivial postinstall errors:

Downloaded setup-x86_64.exe from cygwin.com
Selected c:\cygwin64 as install point
Selected c:\cygwin64\download as download location
Requested Install from Internet

Postinstall errors:

Package: bash
    bash.sh exit code 1
Package: a2ps
    a2ps.sh exit code 2
Package: xinit
    xinit.sh exit code 134

Thanks,
Ken Wolcott

--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Yaakov (Cygwin/X)]

On 2013-07-22 19:52, Kenneth Wolcott wrote:
> Postinstall errors:

Thanks for the feedback; remarks inline.

> Package: bash
>      bash.sh exit code 1

I think the problem is that virtual /dev is a read-only filesystem, but 
if you make a real /dev directory; then you can write to it.  Could you 
run 'mkdir -p /dev' (without the quotes) and then try rerunning 
setup-x86_64.exe?  I suspect this will work then.

FWIW, I wonder why this entire script isn't handled by base-files.

> Package: a2ps
>      a2ps.sh exit code 2

This is due to a missing papersize(5) file.  I'm working on a fix, but a 
workaround is to run the following command, then rerun setup-x86_64.exe:

echo letter > /etc/papersize

> Package: xinit
>      xinit.sh exit code 134

This is from a SIGABRT in mkshortcut.  Chuck?


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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 22 23:40, Yaakov (Cygwin/X) wrote:
> On 2013-07-22 19:52, Kenneth Wolcott wrote:
> >Postinstall errors:
> 
> Thanks for the feedback; remarks inline.
> 
> >Package: bash
> >     bash.sh exit code 1
> 
> I think the problem is that virtual /dev is a read-only filesystem,
> but if you make a real /dev directory; then you can write to it.
> Could you run 'mkdir -p /dev' (without the quotes) and then try
> rerunning setup-x86_64.exe?  I suspect this will work then.

The base-cygwin script usually creates the /dev dir.  Do we have
a dependency loop which let bash.sh run before base-cygwin?

> FWIW, I wonder why this entire script isn't handled by base-files.
> 
> >Package: a2ps
> >     a2ps.sh exit code 2
> 
> This is due to a missing papersize(5) file.  I'm working on a fix,
> but a workaround is to run the following command, then rerun
> setup-x86_64.exe:
> 
> echo letter > /etc/papersize

I'd prefer `echo a4 > /etc/papersize' ;)

> >Package: xinit
> >     xinit.sh exit code 134
> 
> This is from a SIGABRT in mkshortcut.  Chuck?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Yaakov (Cygwin/X)]

On 2013-07-23 02:21, Corinna Vinschen wrote:
> On Jul 22 23:40, Yaakov (Cygwin/X) wrote:
>> On 2013-07-22 19:52, Kenneth Wolcott wrote:
>>> Postinstall errors:
>>
>> Thanks for the feedback; remarks inline.
>>
>>> Package: bash
>>>      bash.sh exit code 1
>>
>> I think the problem is that virtual /dev is a read-only filesystem,
>> but if you make a real /dev directory; then you can write to it.
>> Could you run 'mkdir -p /dev' (without the quotes) and then try
>> rerunning setup-x86_64.exe?  I suspect this will work then.
>
> The base-cygwin script usually creates the /dev dir.  Do we have
> a dependency loop which let bash.sh run before base-cygwin?

The only package that depends on base-cygwin is cygwin itself, and 
neither depend on bash.

>>> Package: a2ps
>>>      a2ps.sh exit code 2
>>
>> This is due to a missing papersize(5) file.  I'm working on a fix,
>> but a workaround is to run the following command, then rerun
>> setup-x86_64.exe:
>>
>> echo letter > /etc/papersize
>
> I'd prefer `echo a4 > /etc/papersize' ;)

I suppose you would. :-)  Any idea how to provide a sane default that 
most people on both sides of the pond would be happy with?


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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 23 03:27, Yaakov (Cygwin/X) wrote:
> On 2013-07-23 02:21, Corinna Vinschen wrote:
> >On Jul 22 23:40, Yaakov (Cygwin/X) wrote:
> >>On 2013-07-22 19:52, Kenneth Wolcott wrote:
> >>>Postinstall errors:
> >>
> >>Thanks for the feedback; remarks inline.
> >>
> >>>Package: bash
> >>>     bash.sh exit code 1
> >>
> >>I think the problem is that virtual /dev is a read-only filesystem,
> >>but if you make a real /dev directory; then you can write to it.
> >>Could you run 'mkdir -p /dev' (without the quotes) and then try
> >>rerunning setup-x86_64.exe?  I suspect this will work then.
> >
> >The base-cygwin script usually creates the /dev dir.  Do we have
> >a dependency loop which let bash.sh run before base-cygwin?
> 
> The only package that depends on base-cygwin is cygwin itself, and
> neither depend on bash.

A deps loop could screw this up.  What does the full setup log say
to the deps order?  Maybe that gives us a hint...

> >>>Package: a2ps
> >>>     a2ps.sh exit code 2
> >>
> >>This is due to a missing papersize(5) file.  I'm working on a fix,
> >>but a workaround is to run the following command, then rerun
> >>setup-x86_64.exe:
> >>
> >>echo letter > /etc/papersize
> >
> >I'd prefer `echo a4 > /etc/papersize' ;)
> 
> I suppose you would. :-)  Any idea how to provide a sane default
> that most people on both sides of the pond would be happy with?

We don't support LC_PAPER so we also don't have this information in
some DB.  Just use letter and let us europeans with their weird
paper formats handle this manually.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Yaakov (Cygwin/X)]

On 2013-07-23 03:59, Corinna Vinschen wrote:
> On Jul 23 03:27, Yaakov (Cygwin/X) wrote:
>> On 2013-07-23 02:21, Corinna Vinschen wrote:
>>> On Jul 22 23:40, Yaakov (Cygwin/X) wrote:
>>>> echo letter > /etc/papersize
>>>
>>> I'd prefer `echo a4 > /etc/papersize' ;)
>>
>> I suppose you would. :-)  Any idea how to provide a sane default
>> that most people on both sides of the pond would be happy with?
>
> We don't support LC_PAPER so we also don't have this information in
> some DB.

So which Thursday isn't booked yet? :-)

> Just use letter and let us europeans with their weird
> paper formats handle this manually.

I suppose "weird" is a matter of perspective, but I'll proceed as you 
suggest.  Unless you think this is worth (ab)using a setup.hint message: 
tag?


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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 23 14:50, Yaakov (Cygwin/X) wrote:
> On 2013-07-23 03:59, Corinna Vinschen wrote:
> >On Jul 23 03:27, Yaakov (Cygwin/X) wrote:
> >>On 2013-07-23 02:21, Corinna Vinschen wrote:
> >>>On Jul 22 23:40, Yaakov (Cygwin/X) wrote:
> >>>>echo letter > /etc/papersize
> >>>
> >>>I'd prefer `echo a4 > /etc/papersize' ;)
> >>
> >>I suppose you would. :-)  Any idea how to provide a sane default
> >>that most people on both sides of the pond would be happy with?
> >
> >We don't support LC_PAPER so we also don't have this information in
> >some DB.
> 
> So which Thursday isn't booked yet? :-)

Can we move that to Friday?

> >Just use letter and let us europeans with their weird
> >paper formats handle this manually.
> 
> I suppose "weird" is a matter of perspective, but I'll proceed as
> you suggest.  Unless you think this is worth (ab)using a setup.hint
> message: tag?

No, I don't think so.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Charles Wilson]

On 7/23/2013 12:40 AM, Yaakov (Cygwin/X) wrote:
> On 2013-07-22 19:52, Kenneth Wolcott wrote:
>> Postinstall errors:
>>
>> Package: xinit
>>      xinit.sh exit code 134
>
> This is from a SIGABRT in mkshortcut.  Chuck?

 From xinit.sh:
	/usr/bin/mkshortcut $CYGWINFORALL -P .....
where $CYGWINFORALL is probably -A

This is the same bug as this one:
http://www.cygwin.com/ml/cygwin/2013-01/msg00261.html

I never replied directly to that message (I was still AWOL at the time), 
but I later referenced it here:
http://cygwin.com/ml/cygwin/2013-06/msg00214.html

> I believe your report has to do with error handling when attempting
> to modify the All User's Desktop, when you don't actually retain the
> elevated permissions necessary to do so.
>
> However, mkshortcut shouldn't *hang* in that case, so it's definitely
> mkshortcut bug. I just haven't had the cycles to track it down and
> fix it. PTC...

...and that's still true.  Is there are way for setup.exe to delegate 
its elevated credentials down to /bin/bash, and thence to 
mkshortcut.exe? Otherwise, even the *fix* for this bug will just make it 
not hang or crash; it will still fail to modify the all-users start 
menu/desktop.

Do we need to extend setup.exe *itself* to accept instructions from 
packages somehow (maybe in the setup.ini?) so that setup.exe *itself* 
can do some of these privilege-requiring tasks?

--
Chuck


--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 23 14:14, Charles Wilson wrote:
> On 7/23/2013 12:40 AM, Yaakov (Cygwin/X) wrote:
> >On 2013-07-22 19:52, Kenneth Wolcott wrote:
> >>Postinstall errors:
> >>
> >>Package: xinit
> >>     xinit.sh exit code 134
> >
> >This is from a SIGABRT in mkshortcut.  Chuck?
> 
> From xinit.sh:
> 	/usr/bin/mkshortcut $CYGWINFORALL -P .....
> where $CYGWINFORALL is probably -A
> 
> This is the same bug as this one:
> http://www.cygwin.com/ml/cygwin/2013-01/msg00261.html
> 
> I never replied directly to that message (I was still AWOL at the
> time), but I later referenced it here:
> http://cygwin.com/ml/cygwin/2013-06/msg00214.html
> 
> >I believe your report has to do with error handling when attempting
> >to modify the All User's Desktop, when you don't actually retain the
> >elevated permissions necessary to do so.
> >
> >However, mkshortcut shouldn't *hang* in that case, so it's definitely
> >mkshortcut bug. I just haven't had the cycles to track it down and
> >fix it. PTC...
> 
> ...and that's still true.  Is there are way for setup.exe to
> delegate its elevated credentials down to /bin/bash, and thence to
> mkshortcut.exe? Otherwise, even the *fix* for this bug will just
> make it not hang or crash; it will still fail to modify the
> all-users start menu/desktop.

Setup does not give up any of it's permissions when starting the
postinstall scripts via CreateProcess.  The scripts have the same
permissions as setup itself, which makes a lot of sense if you think
about it.  Missing permissions to change system dirs should only occur
if setup has been started as non-admin, or if the UAC installer
recognition has been switched off (affects only the 32 bit version).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Charles Wilson]

On 7/23/2013 2:46 PM, Corinna Vinschen wrote:
> On Jul 23 14:14, Charles Wilson wrote:
>>> I believe your report has to do with error handling when attempting
>>> to modify the All User's Desktop, when you don't actually retain the
>>> elevated permissions necessary to do so.

>> Is there are way for setup.exe to
>> delegate its elevated credentials down to /bin/bash, and thence to
>> mkshortcut.exe? Otherwise, even the *fix* for this bug will just
>> make it not hang or crash; it will still fail to modify the
>> all-users start menu/desktop.
>
> Setup does not give up any of it's permissions when starting the
> postinstall scripts via CreateProcess.  The scripts have the same
> permissions as setup itself, which makes a lot of sense if you think
> about it.  Missing permissions to change system dirs should only occur
> if setup has been started as non-admin, or if the UAC installer
> recognition has been switched off (affects only the 32 bit version).

But even if /bin/bash is elevated, it doesn't follow that any of the 
tools launched within a script -- via cygwin's fork/exec method -- ALSO 
retain that elevation.

Does it?

--
Chuck


--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 23 15:08, Charles Wilson wrote:
> On 7/23/2013 2:46 PM, Corinna Vinschen wrote:
> >On Jul 23 14:14, Charles Wilson wrote:
> >>>I believe your report has to do with error handling when attempting
> >>>to modify the All User's Desktop, when you don't actually retain the
> >>>elevated permissions necessary to do so.
> 
> >>Is there are way for setup.exe to
> >>delegate its elevated credentials down to /bin/bash, and thence to
> >>mkshortcut.exe? Otherwise, even the *fix* for this bug will just
> >>make it not hang or crash; it will still fail to modify the
> >>all-users start menu/desktop.
> >
> >Setup does not give up any of it's permissions when starting the
> >postinstall scripts via CreateProcess.  The scripts have the same
> >permissions as setup itself, which makes a lot of sense if you think
> >about it.  Missing permissions to change system dirs should only occur
> >if setup has been started as non-admin, or if the UAC installer
> >recognition has been switched off (affects only the 32 bit version).
> 
> But even if /bin/bash is elevated, it doesn't follow that any of the
> tools launched within a script -- via cygwin's fork/exec method --
> ALSO retain that elevation.
> 
> Does it?

Yes, it does.  CreateProcess propagates its own user token untouched.

Weird question.  Did you ever start an elevated shell and lost your
admin permissions in a child process?  If that would occur, nothing
would work right in an admin shell.  Even the `id' call would not show
the admins group in your supplementary group list.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Charles Wilson]

On 7/23/2013 3:23 PM, Corinna Vinschen wrote:
> On Jul 23 15:08, Charles Wilson wrote:
>> But even if /bin/bash is elevated, it doesn't follow that any of the
>> tools launched within a script -- via cygwin's fork/exec method --
>> ALSO retain that elevation.
>>
>> Does it?
>
> Yes, it does.  CreateProcess propagates its own user token untouched.
>
> Weird question.  Did you ever start an elevated shell and lost your
> admin permissions in a child process?  If that would occur, nothing
> would work right in an admin shell.  Even the `id' call would not show
> the admins group in your supplementary group list.

OK. At one point I thought there was an issue with propagating 
elevation, but I guess not.

So...is it possible to launch setup*.exe in an UNelevated context 
(somehow bypassing the UAC detection, even though we don't ship a 
manifest)?  Then, if the user selects 'Install for All Users' you would 
see this problem.

--
Chuck



--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Corinna Vinschen]

On Jul 24 09:04, Charles Wilson wrote:
> On 7/23/2013 3:23 PM, Corinna Vinschen wrote:
> >On Jul 23 15:08, Charles Wilson wrote:
> >>But even if /bin/bash is elevated, it doesn't follow that any of the
> >>tools launched within a script -- via cygwin's fork/exec method --
> >>ALSO retain that elevation.
> >>
> >>Does it?
> >
> >Yes, it does.  CreateProcess propagates its own user token untouched.
> >
> >Weird question.  Did you ever start an elevated shell and lost your
> >admin permissions in a child process?  If that would occur, nothing
> >would work right in an admin shell.  Even the `id' call would not show
> >the admins group in your supplementary group list.
> 
> OK. At one point I thought there was an issue with propagating
> elevation, but I guess not.
> 
> So...is it possible to launch setup*.exe in an UNelevated context
> (somehow bypassing the UAC detection, even though we don't ship a
> manifest)?  Then, if the user selects 'Install for All Users' you
> would see this problem.

Yes.  The only thing we could do about that, would be to change
the manifest to start the 32 bit version always as admin, just as
the 64 bit setup.

On second thought, I wonder if we should get rid of the "All users"/
"Just me" selection entirely.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Andrey Repin]

Greetings, Charles Wilson!

>>> But even if /bin/bash is elevated, it doesn't follow that any of the
>>> tools launched within a script -- via cygwin's fork/exec method --
>>> ALSO retain that elevation.
>>>
>>> Does it?
>>
>> Yes, it does.  CreateProcess propagates its own user token untouched.
>>
>> Weird question.  Did you ever start an elevated shell and lost your
>> admin permissions in a child process?  If that would occur, nothing
>> would work right in an admin shell.  Even the `id' call would not show
>> the admins group in your supplementary group list.

> OK. At one point I thought there was an issue with propagating 
> elevation, but I guess not.

> So...is it possible to launch setup*.exe in an UNelevated context

Yes, is you rename it to something less apparent. People suggested
"getcygwin.exe" earlier.

> (somehow bypassing the UAC detection, even though we don't ship a
> manifest)?  Then, if the user selects 'Install for All Users' you would 
> see this problem.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 24.07.2013, <17:33>

Sorry for my terrible english...


--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Kenneth Wolcott]

Hi All;

  Again, first of all, thanks for Cygwin!  And thanks for Cygwin 64!

  Since almost all pertinent context in this email thread is now
scattered (at least for me), I have removed all prior content in this
reply.

  I just ran an update using the same mirror (kernel.org) I usually use.

  I was warned that my setup.ini was newer than my setup*.exe so I
terminated the update.

  I downloaded a fresh setup-x86_64.exe from cygwin.com and then ran
the update again.

  Now I get only this postinstall error:

  Package: xinit
    xinit.sh exit code 134

  The a2ps and bash postinstall errors have vanished.

  The output of uname -a is: CYGWIN_NT-6.1 User-PC 1.7.22(0.268/5/3)
2013-07-22 17:06 x86_64 Cygwin

Thanks,
Ken Wolcott

--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Jon TURNEY]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On 25/07/2013 05:24, Kenneth Wolcott wrote:
>   I downloaded a fresh setup-x86_64.exe from cygwin.com and then ran
> the update again.
> 
>   Now I get only this postinstall error:
> 
>   Package: xinit
>     xinit.sh exit code 134
I can reproduce this problem, so I had a go at investigating and fixing it.

mkshortcut appears to exiting with SIGABRT in free(), which suggests some heap
corruption, which I managed to track down after a bit of work with dmalloc.

This appears to be a long standing bug, which for some reason manifests itself
more severely on x86_64.

xstrncat() does not allow for the terminating null byte in the memory
allocation it makes.  strncat(dest, src, n) writes n+1 bytes to dest (n from
src plus the terminating null byte, which is always appended).  So, the size
of dest must be at least strlen(dest)+n+1.  Currently only strlen(dest)+n
bytes are allocated.

Trivial patch attached.


[-- Attachment #2: cygutils-strncat.patch --]
[-- Type: text/plain, Size: 462 bytes --]

--- origsrc/cygutils-1.4.12/src/mkshortcut/mkshortcut.c	2013-04-28 00:17:56.000000000 +0100
+++ src/cygutils-1.4.12/src/mkshortcut/mkshortcut.c	2013-07-28 22:36:54.890625000 +0100
@@ -394,7 +394,7 @@ xstrndup (const char *string, size_t n)
 static char *
 xstrncat (char **dest, const char *add, size_t n)
 {
-  size_t len = strlen (*dest) + n;
+  size_t len = strlen (*dest) + n + 1;
   char *s = (char *) realloc (*dest, len * sizeof (char));
   if (!s)
   {


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134

[Charles Wilson]

On 7/28/2013 5:47 PM, Jon TURNEY wrote:
> On 25/07/2013 05:24, Kenneth Wolcott wrote:
>>    I downloaded a fresh setup-x86_64.exe from cygwin.com and then ran
>> the update again.
>>
>>    Now I get only this postinstall error:
>>
>>    Package: xinit
>>      xinit.sh exit code 134
> I can reproduce this problem, so I had a go at investigating and fixing it.
>
> mkshortcut appears to exiting with SIGABRT in free(), which suggests some heap
> corruption, which I managed to track down after a bit of work with dmalloc.
>
> This appears to be a long standing bug, which for some reason manifests itself
> more severely on x86_64.
>
> xstrncat() does not allow for the terminating null byte in the memory
> allocation it makes.  strncat(dest, src, n) writes n+1 bytes to dest (n from
> src plus the terminating null byte, which is always appended).  So, the size
> of dest must be at least strlen(dest)+n+1.  Currently only strlen(dest)+n
> bytes are allocated.
>
> Trivial patch attached.

Thanks, Jon. I'll roll a new release of cygutils immediately for both 
x86 and x86_64.

--
Chuck



--
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