Bug Report

Bug Report

[julie77793]

Cygwin doesn't create an environment variable in bash to indicate that the
platform is Cygwin under Windows.

This causes compatibility problems when running various tools. Most of my
issues have been with Python tools running Windows Python.

I have been addressing this issue by grepping PATH for cygdrive which
doesn't seem like a very good approach.

Both msys2 and mingw solve this issue by setting the MSYSTEM environment
variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS

Please add some way of identifying that programs are running under Cygwin.

RE: [EXTERNAL] Bug Report

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> Please add some way of identifying that programs are running under Cygwin.

Have you tried to use the "uname" command for the identification purposes?

$ uname
CYGWIN_NT-6.1

$ uname
CYGWIN_NT-10.0

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: CygwinPaltform Identification

[Brian Inglis]

On 2022-02-08 15:01, julie77793@gmail.com wrote:
> Cygwin doesn't create an environment variable in bash to indicate that the
> platform is Cygwin under Windows.
> This causes compatibility problems when running various tools. Most of my
> issues have been with Python tools running Windows Python.
> I have been addressing this issue by grepping PATH for cygdrive which
> doesn't seem like a very good approach.
> Both msys2 and mingw solve this issue by setting the MSYSTEM environment
> variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS
> Please add some way of identifying that programs are running under Cygwin.

I have been switching env/OS/arch/triple dependent profile and rc files 
and sections for years with:

64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE
cygwin Windows_NT x86_64 x86_64-unknown-cygwin

32 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE
cygwin Windows_NT i686 i686-pc-cygwin

Please note that *only* $OS is exported by default (in the above list), 
so you will have to explicitly export (in profiles) any other shell 
variables you wish to be available to shell subprocesses.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

RE: CygwinPaltform Identification

[julie77793]

I realize that I can create my own env variables. I just think that Cygwin
should provide them so that programmers writing software can rely on the
variable name and value. If there is no consistent value when Cygwin is
installed then dozens of tools that work on other bash solutions for Windows
can't be made to work on Cygwin.

-----Original Message-----
From: Cygwin <cygwin-bounces+cygwin=prettywhack.com@cygwin.com> On Behalf Of
Brian Inglis
Sent: Tuesday, February 8, 2022 6:46 PM
To: cygwin@cygwin.com
Subject: Re: CygwinPaltform Identification

On 2022-02-08 15:01, julie77793@gmail.com wrote:
> Cygwin doesn't create an environment variable in bash to indicate that 
> the platform is Cygwin under Windows.
> This causes compatibility problems when running various tools. Most of 
> my issues have been with Python tools running Windows Python.
> I have been addressing this issue by grepping PATH for cygdrive which 
> doesn't seem like a very good approach.
> Both msys2 and mingw solve this issue by setting the MSYSTEM 
> environment variable which lets tools check that OS=Windows_NT and 
> MSYSTEM=MSYS Please add some way of identifying that programs are running
under Cygwin.

I have been switching env/OS/arch/triple dependent profile and rc files and
sections for years with:

64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT x86_64
x86_64-unknown-cygwin

32 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT i686
i686-pc-cygwin

Please note that *only* $OS is exported by default (in the above list), so
you will have to explicitly export (in profiles) any other shell variables
you wish to be available to shell subprocesses.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains too much
technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

RE: CygwinPaltform Identification

[Allen Hewes]

> -----Original Message-----
> From: Cygwin <cygwin-bounces+allen=decisiv.net@cygwin.com> On Behalf
> Of julie77793@gmail.com
> Sent: Tuesday, February 8, 2022 11:13 PM
> To: cygwin@cygwin.com
> Subject: RE: CygwinPaltform Identification
>
> I realize that I can create my own env variables. I just think that Cygwin
> should provide them so that programmers writing software can rely on the
> variable name and value. If there is no consistent value when Cygwin is
> installed then dozens of tools that work on other bash solutions for Windows
> can't be made to work on Cygwin.
>

It does. How much more consistent can you get with what Brian pointed out? OSTYPE would be safe in BASH 4+. And if you wanted to be pedantic, OS and OSTYPE and some regex of MACHTYPE? MSYSTEM isn't portable. Of course, there's always uname.

Cygwin:
$ printf "BASH=%s\nOS=%s\nOSTYPE=%s\nHOSTTYPE=%s\nMACHTYPE=%s\n" "${BASH_VERSION}" "${OS-Unknown}" "${OSTYPE}" "${HOSTTYPE}" "${MACHTYPE}"
BASH=4.4.23(1)-release
OS=Windows_NT
OSTYPE=cygwin
HOSTTYPE=x86_64
MACHTYPE=x86_64-unknown-cygwin

MSYS2:
$ printf "BASH=%s\nOS=%s\nOSTYPE=%s\nHOSTTYPE=%s\nMACHTYPE=%s\n" "${BASH_VERSION}" "${OS-Unknown}" "${OSTYPE}" "${HOSTTYPE}" "${MACHTYPE}"
BASH=5.1.8(1)-release
OS=Windows_NT
OSTYPE=msys
HOSTTYPE=x86_64
MACHTYPE=x86_64-pc-msys

Fedora:
$ printf "BASH=%s\nOS=%s\nOSTYPE=%s\nHOSTTYPE=%s\nMACHTYPE=%s\n" "${BASH_VERSION}" "${OS-Unknown}" "${OSTYPE}" "${HOSTTYPE}" "${MACHTYPE}"
BASH=5.1.0(1)-release
OS=Unknown
OSTYPE=linux-gnu
HOSTTYPE=x86_64
MACHTYPE=x86_64-redhat-linux-gnu

FreeBSD:
$ printf "BASH=%s\nOS=%s\nOSTYPE=%s\nHOSTTYPE=%s\nMACHTYPE=%s\n" "${BASH_VERSION}" "${OS-Unknown}" "${OSTYPE}" "${HOSTTYPE}" "${MACHTYPE}"
BASH=5.1.16(0)-release
OS=Unknown
OSTYPE=freebsd12.2
HOSTTYPE=amd64
MACHTYPE=amd64-portbld-freebsd12.2

And Cygwin Python knows of it's host:
$ python
Python 3.8.12 (default, Sep 10 2021, 16:06:59)
[GCC 11.2.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'CYGWIN_NT-10.0-19044'
>>> platform.release()
'3.3.4-341.x86_64'
>>> quit()

/allen

________________________________

Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.

Re: Bug Report

[Ernie Rael]

On 2/8/22 2:01 PM, julie77793@gmail.com wrote:
> Cygwin doesn't create an environment variable in bash to indicate that the
> platform is Cygwin under Windows.
>
> This causes compatibility problems when running various tools. Most of my
> issues have been with Python tools running Windows Python.
>
> I have been addressing this issue by grepping PATH for cygdrive which
> doesn't seem like a very good approach.
>
> Both msys2 and mingw solve this issue by setting the MSYSTEM environment
> variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS
>
> Please add some way of identifying that programs are running under Cygwin.
>
And of course there's

    $ uname -o
    Cygwin

-ernie

Re: Cygwin Platform Identification

[Brian Inglis]

On 2022-02-08 21:13, julie77793@gmail.com wrote:
> On Tuesday, February 8, 2022 6:46 PM, Brian Inglis wrote:
> On 2022-02-08 15:01, julie77793@gmail.com wrote:
>> Cygwin doesn't create an environment variable in bash to indicate that
>> the platform is Cygwin under Windows.
>> This causes compatibility problems when running various tools. Most of
>> my issues have been with Python tools running Windows Python.
>> I have been addressing this issue by grepping PATH for cygdrive which
>> doesn't seem like a very good approach.
>> Both msys2 and mingw solve this issue by setting the MSYSTEM
>> environment variable which lets tools check that OS=Windows_NT and
>> MSYSTEM=MSYS
>> Please add some way of identifying that programs are running under
>> Cygwin.

> I have been switching env/OS/arch/triple dependent profile and rc files and
> sections for years with:
> 
> 64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT x86_64
> x86_64-unknown-cygwin
> 
> 32 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE cygwin Windows_NT i686
> i686-pc-cygwin
> 
> Please note that *only* $OS is exported by default (in the above list), so
> you will have to explicitly export (in profiles) any other shell variables
> you wish to be available to shell subprocesses.

> I realize that I can create my own env variables. I just think that 
> Cygwin should provide them so that programmers writing software can 
> rely on the variable name and value. If there is no consistent value 
> when Cygwin is installed then dozens of tools that work on other
> bash solutions for Windows can't be made to work on Cygwin.
If you would like information provided, please request the information 
you seek, and you are more likely to get a response.

You are making a series of incorrect statements here based on incorrect 
assumptions due to lack of relevant information.

Did I suggest you had to set any of those variables?

If you would RTFM e.g. "$ info bash var" you would realize that those 
variables named are set by bash, depending on the build target or host 
execution environment.

I said *only* $OS is exported by default, such that it is automatically 
exported to be available in child processes.

The other variables named have not been automatically exported by 
default since bash 2.

You have to explicitly export the other variables named from your bash 
login or bash process execution shell to make them available in child 
process environments.

Other shells may not provide platform identification or use the same 
variable names e.g.

bash $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
x86_64 . x86_64-unknown-cygwin . cygwin .

dash $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .

mksh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .

posh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. . .

tcsh $ echo  $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
x86_64-cygwin . x86_64 . cygwin . unknown

zsh $ echo $HOSTTYPE . $MACHTYPE . $OSTYPE . $VENDOR
. x86_64 . cygwin . pc

in which case utilities may be used or system configuration enquiries 
sysconf(3) may be required.

Cygwin also provides the POSIX mandated outputs:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html

64 $ uname
CYGWIN_NT-10.0
32 $ uname
CYGWIN_NT-10.0-WOW

and common Linux and BSD extensions (e.g. -o):

64 $ uname -so
CYGWIN_NT-10.0 Cygwin
64 $ uname -rv
3.3.4(0.341/5/3) 2022-01-31 19:35

$ head /proc/version
CYGWIN_NT-10.0-19044 version 3.3.4-341.x86_64 (corinna@calimero) (gcc 
version 11.2.0 20210728 (Fedora Cygwin 11.2.0-2) (GCC) ) 2022-01-31 
19:35 UTC

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: CygwinPaltform Identification

[Henry S. Thompson]

Brian Inglis writes:

> On 2022-02-08 15:01, julie77793@gmail.com wrote:
>> Cygwin doesn't create an environment variable in bash to indicate that the
>> platform is Cygwin under Windows.
>> ...
>
> I have been switching env/OS/arch/triple dependent profile and rc files
> and sections for years with:
>
> 64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE
> cygwin Windows_NT x86_64 x86_64-unknown-cygwin
> ...

When I don't know or can't remember what variable has the information
I want, printenv is my first stop, e.g.

  64> printenv | grep -i cygwin
  Cygwin=server
  PATH=...

As Brian pointed out, that doesn't find what you need, because it only
lists environment variables, but this does:

  64> declare -p | grep -i cygwin
  declare -ar BASH_VERSINFO=([0]="4" [1]="4" [2]="12" [3]="3" [4]="release" [5]="x86_64-unknown-cygwin")
  declare -x Cygwin="server"
  declare -- MACHTYPE="x86_64-unknown-cygwin"
  declare -- OSTYPE="cygwin"
  declare -x PATH=...

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: Cygwin Platform Identification

[Brian Inglis]

On 2022-02-09 02:12, Henry S. Thompson wrote:
> Brian Inglis writes:
> 
>> On 2022-02-08 15:01, julie77793@gmail.com wrote:
>>> Cygwin doesn't create an environment variable in bash to indicate that the
>>> platform is Cygwin under Windows.
>>> ...
>>
>> I have been switching env/OS/arch/triple dependent profile and rc files
>> and sections for years with:
>>
>> 64 $ echo $OSTYPE $OS $HOSTTYPE $MACHTYPE
>> cygwin Windows_NT x86_64 x86_64-unknown-cygwin
>> ...
> 
> When I don't know or can't remember what variable has the information
> I want, printenv is my first stop, e.g.
> 
>    64> printenv | grep -i cygwin
>    Cygwin=server
>    PATH=...
> 
> As Brian pointed out, that doesn't find what you need, because it only
> lists environment variables, but this does:
> 
>    64> declare -p | grep -i cygwin
>    declare -ar BASH_VERSINFO=([0]="4" [1]="4" [2]="12" [3]="3" [4]="release" [5]="x86_64-unknown-cygwin")
>    declare -x Cygwin="server"
>    declare -- MACHTYPE="x86_64-unknown-cygwin"
>    declare -- OSTYPE="cygwin"
>    declare -x PATH=...

AKA `set` in most shells:

$ set | egrep -i '=[^/\\]*(cygwin|windows)'
BASH_VERSINFO=([0]="4" [1]="4" [2]="12" [3]="3" [4]="release" 
[5]="x86_64-unknown-cygwin")
MACHTYPE=x86_64-unknown-cygwin
OS=Windows_NT
OSTYPE=cygwin
XDG_CURRENT_DESKTOP=X-Cygwin
$ env | egrep -i '=[^/\\]*(cygwin|windows)'
OS=Windows_NT
XDG_CURRENT_DESKTOP=X-Cygwin

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Bug Report

[Bill Stewart]

On Tue, Feb 8, 2022 at 3:02 PM julie77793 wrote:

Cygwin doesn't create an environment variable in bash to indicate that the
> platform is Cygwin under Windows.
>

FYI, as a point of decorum: The subject line of this thread is rather
undiplomatic.

(Bug usually means "software should do X but fails in some way," not
"please add feature X.")

Recommended reading: How to ask questions the smart way[1]

[1] http://www.catb.org/~esr/faqs/smart-questions.html

Bill

Re: bug report

[Brian Inglis]

On 2023-09-06 16:20, Asad Ali via Cygwin wrote:
> On Fri, Dec 30, 2022 at 5:46 AM Asad Ali <asadali.282821@gmail.com> wrote:
>> I'm a penetration tester and bug bounty hunter. I have found a potential
>> vulnerability in the site. Please review the report below.
> Is there any update on this ? I'm hoping to receive a reward for the
> reported bug. Waiting for your response.
Cygwin site does not require logins, maybe you have been phished?
Cygwin is a volunteer project and does not offer any bounties.
Your report does not provide a Simple Test Case, reproducible step by step 
process, attached cygcheck output, or show any signs of being related to this 
project, as it does not provide those browsers.
Please give yourself 2 cents for your report.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: bug report

[Asad Ali]

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

Hi Team,

Is there any update on this ? I'm hoping to receive a reward for the
reported bug.

Waiting for your response.

On Fri, Dec 30, 2022 at 5:46 AM Asad Ali <asadali.282821@gmail.com> wrote:

> Hey Team,
>
>
>
> I'm a penetration tester and bug bounty hunter. I have found a potential
> vulnerability in the site. Please review the report below.
>
>
>
> Vulnerability: Broken Authentication & Session Management
> We have observed that when we change "password" from one browser in place
> of session expiration from another browser it just updates the password
> from another browser and the old session gets updated without being logged
> out. The flows goes like this:
> Broken Authentication and Session Management > Failure to Invalidate
> Session > On Password Change
> Steps:
>
> 1- Login from two browsers at a time [From Chrome browser and from Mozilla
> Firefox].
>
> 2- Change password in settings from chrome browser.
>
> 3- Now Check Mozilla Firefox.
>
> 4- Your Session got "updated" in place of expiration.
>
>
>
>
> Same goes with when using two different computer systems.
>
> 1- Login from two computers at a time
>
> 2- Change password in settings from computer A.
>
> 3- Now Check computer B.
> 4- Your Session got "updated" in place of expiration.
>
> Recommendations: If Session is Updating from one Browser/Computer so other
> should expire first to renew session after login.
>
>
>
> If you require any additional information, please let me know. I'll be
> waiting to hear from your side regarding the report and bounty.
>

Re: Bug report

[Igor Pechtchanski]

On Mon, 5 May 2003, Igor Pechtchanski wrote:

> On 5 May 2003, Kern Sibbald wrote:
> [snip]
> > > Did you try running the program from the command line in a
> > > LocalSystem-owned shell?
> >
> > I ran it in an rxvt shell under my id and it does not crash.
> > Tell me how to get a LocalSystem owned shell and I will try
> > it.  This is XP Home, so I don't have access to a lot of the
> > XP security dialogs.
>
> "at <time> /interactive c:\cygwin\bin\bash.exe -i --login"
> (<time> should be current time however long you're willing to wait, at
                                ^ plus

> least one minute).  "at /?" for help.
> [Note, this works on Win2k, don't know about XP Home].

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


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

[Igor Pechtchanski]

On 5 May 2003, Kern Sibbald wrote:

> Hello,
>
> On Mon, 2003-05-05 at 18:38, Igor Pechtchanski wrote:
> > On 5 May 2003, Kern Sibbald wrote:
> >
> > > I guess you guys (and gal) really don't want bug
> > > reports because it is not at all obvious where
> > > to send them.
> >
> > This is the right place.
>
> Great.
>
> > > Anyway here is one:
> > >
> > > Running WinXP Home version.
> > >
> > > Using Cygwin 1.3.20
> > >
> > > When running my program with LocalSystem userid
> > > as a service, doing a pthread_kill(thread_id, SIGUSR2)
> > > causes some sort of memory fault referencing memory at 0x3a
> > > (or something like that because the program disappears
> > > poof).
> > >
> > > Running as a normal user works fine.
> >
> > What's the exact error message (I assume you get a popup box)?
>
> No, I get absolutely nothing. Poof and it is gone, well, the
> service manager knows it went away but not why.
>
> A friend ran the program on Win2K and he got:
>
>       Instruction at 0x0041276a referenced memory at 0x3c
>
> That appears to be somewhere in the cygwin1.dll.

Try checking the "Allow service to interact with the desktop" box, and you
should see the error popup on your system too.

> > Is there a stacktrace file generated?
>
> If it is, I don't know where the system put it.

The system should put it in the directory from which the program is run.

> >   Did you try setting
> > "error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
> > variable?
>
> No, if you can tell me how to set the environment variable for
> a service, I'll try it, but since it is a service, I am unlikely
> to get any output.

"cygrunsrv --help", or "man cygrunsrv", or see /bin/ssh-host-config for an
example.  You might also need the "Allow service to interact with desktop"
bit.

> > Did you try running the program from the command line in a
> > LocalSystem-owned shell?
>
> I ran it in an rxvt shell under my id and it does not crash.
> Tell me how to get a LocalSystem owned shell and I will try
> it.  This is XP Home, so I don't have access to a lot of the
> XP security dialogs.

"at <time> /interactive c:\cygwin\bin\bash.exe -i --login"
(<time> should be current time however long you're willing to wait, at
least one minute).  "at /?" for help.
[Note, this works on Win2k, don't know about XP Home].

> > Can you provide a simple testcase that
> > reproduces your problem?
>
> Probably not as my program is some 65K+ lines of code.

You could try a simple program that calls the offending function (after
creating some threads, most likely), and see if the problem manifests...

> I've solved the problem for myself by doing the "signal"
> a different way, so it is not critical for me but it cost
> about 8 hours of debugging -- primarily due to the fact that
> it seems to be dependent on whether or not it is a service.
>
> Best regards,
> Kern

It's most likely dependent on the value of your CYGWIN variable or some
permissions (as the service runs as LocalSystem).  Trying the program out
from a LocalSystem-owned window (see above) should give you some idea of
what's at fault.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


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

[Kern Sibbald]

Hello,

On Mon, 2003-05-05 at 18:38, Igor Pechtchanski wrote:
> On 5 May 2003, Kern Sibbald wrote:
> 
> > I guess you guys (and gal) really don't want bug
> > reports because it is not at all obvious where
> > to send them.
> 
> This is the right place.

Great.

> 
> > Anyway here is one:
> >
> > Running WinXP Home version.
> >
> > Using Cygwin 1.3.20
> >
> > When running my program with LocalSystem userid
> > as a service, doing a pthread_kill(thread_id, SIGUSR2)
> > causes some sort of memory fault referencing memory at 0x3a
> > (or something like that because the program disappears
> > poof).
> >
> > Running as a normal user works fine.
> 
> What's the exact error message (I assume you get a popup box)?

No, I get absolutely nothing. Poof and it is gone, well, the
service manager knows it went away but not why.

A friend ran the program on Win2K and he got:

      Instruction at 0x0041276a referenced memory at 0x3c

That appears to be somewhere in the cygwin1.dll.

> Is there a stacktrace file generated?

If it is, I don't know where the system put it.

>   Did you try setting
> "error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
> variable?  

No, if you can tell me how to set the environment variable for
a service, I'll try it, but since it is a service, I am unlikely
to get any output.

> Did you try running the program from the command line in a
> LocalSystem-owned shell?  

I ran it in an rxvt shell under my id and it does not crash.
Tell me how to get a LocalSystem owned shell and I will try
it.  This is XP Home, so I don't have access to a lot of the
XP security dialogs.

> Can you provide a simple testcase that
> reproduces your problem?

Probably not as my program is some 65K+ lines of code.

I've solved the problem for myself by doing the "signal"
a different way, so it is not critical for me but it cost
about 8 hours of debugging -- primarily due to the fact that
it seems to be dependent on whether or not it is a service.

Best regards,

Kern


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

[Christopher Faylor]

On Mon, May 05, 2003 at 06:21:24PM +0200, Kern Sibbald wrote:
>I guess you guys (and gal) really don't want bug reports because it is
>not at all obvious where to send them.

From http://cygwin.com/lists.html - 

"cygwin: a high volume list for discussion of just about all things
Cygwin-related.  If you have questions about how to use Cygwin, or if
you have cygwin-specific (see above) questions, bugs, or observations
about the UNIX tools (bash, gcc, make, etc.) that come with Cygwin, this
is the list for you..."

The 'bugs' part of the above sentence would make it pretty obvious where
to send bug reports.

>Anyway here is one:
>
>Running WinXP Home version.
>
>Using Cygwin 1.3.20
>
>When running my program with LocalSystem userid as a service, doing a
>pthread_kill(thread_id, SIGUSR2) causes some sort of memory fault
>referencing memory at 0x3a (or something like that because the program
>disappears poof).
>
>Running as a normal user works fine.

The words at http://cygwin.com/bugs.html might help you craft a bug
report which actually would stand a chance of being looked at.  This
message is too vague for anyone to be able to help you.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

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

[Igor Pechtchanski]

On 5 May 2003, Kern Sibbald wrote:

> I guess you guys (and gal) really don't want bug
> reports because it is not at all obvious where
> to send them.

This is the right place.

> Anyway here is one:
>
> Running WinXP Home version.
>
> Using Cygwin 1.3.20
>
> When running my program with LocalSystem userid
> as a service, doing a pthread_kill(thread_id, SIGUSR2)
> causes some sort of memory fault referencing memory at 0x3a
> (or something like that because the program disappears
> poof).
>
> Running as a normal user works fine.

What's the exact error message (I assume you get a popup box)?
Is there a stacktrace file generated?  Did you try setting
"error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
variable?  Did you try running the program from the command line in a
LocalSystem-owned shell?  Can you provide a simple testcase that
reproduces your problem?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


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

[Kern Sibbald]

I guess you guys (and gal) really don't want bug
reports because it is not at all obvious where
to send them.  

Anyway here is one:

Running WinXP Home version.

Using Cygwin 1.3.20

When running my program with LocalSystem userid
as a service, doing a pthread_kill(thread_id, SIGUSR2) 
causes some sort of memory fault referencing memory at 0x3a 
(or something like that because the program disappears
poof).

Running as a normal user works fine.


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

[David L Wiltshire]

Cygwin DLL 1.3.2

I just installed this on Win 98 SE box. The paste button on the bash
window does not function (although the other buttons appear to work
fine). If the clipboard is empty pushing on the paste button registers
an error message "Clipboard empty" but if there is something is on the
clipboard there is simply no effect.

Best regards,

David Wiltshire

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Bug Report

[Christopher G. Faylor]

In article <199807010655.IAA00527.cygnus.gnu-win32@surgery1.best.ms.philips.com>,
Ronald Pijnacker <Ronald.Pijnacker@best.ms.philips.com> wrote:
>....
>> To fix the most serious problems:
>>   Please, _READ_ the IMPORTANT UPGRADE NOTICE at the end of this note.
>>   Please, ensure that there is only _ONE_ cygwinb19.dll.
>>   Please, ensure that _ALL_ b18 binaries have been removed.
>>   Please, _USE_ the Searchable Mail Archives.
>....
>
>Wouldn't it be about time to release a new (or at least updated)
>version of the cygwin stuff? This would alow newcomers to start
>without having to upgrade their newly installed distrubution before
>they can do something useful. It would also eliminate the necessity
>for Earnie to keep on having to type `_READ_ the IMPORTANT UPGRADE
>NOTICE' etc. every time somebody asks a question about why something
>doesn't work.

You're right.  We'll probably be releasing a new version sometime after
Geoffrey returns from vacation.
-- 
cgf@cygnus.com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug Report

[Ronald Pijnacker]

....
> To fix the most serious problems:
>   Please, _READ_ the IMPORTANT UPGRADE NOTICE at the end of this note.
>   Please, ensure that there is only _ONE_ cygwinb19.dll.
>   Please, ensure that _ALL_ b18 binaries have been removed.
>   Please, _USE_ the Searchable Mail Archives.
....

Wouldn't it be about time to release a new (or at least updated)
version of the cygwin stuff? This would alow newcomers to start
without having to upgrade their newly installed distrubution before
they can do something useful. It would also eliminate the necessity
for Earnie to keep on having to type `_READ_ the IMPORTANT UPGRADE
NOTICE' etc. every time somebody asks a question about why something
doesn't work.

Ronald.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

bug report

[p.a.c.tavares]

The following code works fine in a HP system (using gcc 2.7.2), calling 
the correct "Column" contructor with the right arguments

int Table::init(int line,int col,double fill_value)
{
   n_lines = line;
   n_cols = col;
   if (pt) delete [] pt;
   pt = new Column[col](line,fill_value);
   if (pt == NULL) return 1;
   return 0;
}

However under cygwin, in spite of compiling fine it calls (according 
to gdb) the correct column constructor "Column::Column(int,double) but all 
the arguments show up as 0 (including the int which results in a lenght 0 
column being created). The form of this contructor is I believe 
irrelevant but here it is anyway. A check of the value of 'size' in the 
first line of the function tells that size=0 (when it was called with a 
positive number by Table::init(int,double),

Column::Column(int size,double fill_value)
{
	len = size;
	val = new float [len];
	while (size > 0) val[--size] = fill_value;
}


I am using gcc in a win95 system, 486 with 16Mb. the options of the 
compiler are -gstabs+ and a -I entry. The libraries are, -lstdc++ -lg++ 
-lm -lpact (the last being my own library)

----------------------------------------------------------------------------
Pedro A.C. Tavares <p.tavares@strath.ac.uk>

Superconducting Devices Group         Tel: +44-141-548 3151
Dept. of Physics & Applied Physics    Fax: +44-141-552 7143
University of Strathclyde             For PGP public key: "finger
Glasgow, UK                               pedro_t@zebedee.phys.strath.ac.uk"
----------------------------------------------------------------------------
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: bug report

[Sean McNeil]

I don't know if anyone has addressed this reported problem, but apparantly the stream
I/O routines are following the rule of assuming files are text unless fopen has the "b"
in the mode.  The posted code works just fine when opened with "wb" and "rb".
This appears to be consistent with what I read in the man pages regarding fopen.
This is not a bug, then, but the expected behaviour.

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: bug report

[Sergey Okhapkin]

Andres Takach wrote:
> 
> There seems to be a problem in the read() (getc etc.) when
> reading binary files. A character 1A can confuse the read
> to think that it has found the end of file.
>   fp = fopen("temp","w");
> 
>   fp = fopen("temp","r");

You should open binary files with "wb"/"rb" mode flags.

-- 
Sergey Okhapkin
Moscow, Russia
Looking for a job.


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

bug report

[Andres Takach]

There seems to be a problem in the read() (getc etc.) when
reading binary files. A character 1A can confuse the read
to think that it has found the end of file.

This problem also happens when using the gnu-win92 "od" program.
In fact it also happens on the perl implementation for win 95/NT.
The perl problem happens on even NT machines. 

I have included below a simple c program that exposes the problem.

Andres Takach


#include <stdio.h>
#include <stdlib.h>

/* this program illustrates the fact that if the character 1A is
  present in a binary file, getc() will return an EOF at that point
  (same can be said about read() etc.)  The output of this program
  should be 13 (13 chars in file "temp") but instead it is 2.
  Program "od" will also quit early and same can be said about
  perl for windows 95/NT.
*/

main(){
  FILE *fp;
  int ch;
  int count = 0;
  int i;
  fp = fopen("temp","w");

/* Write two random chars to "temp"*/
  putc(255,fp); 
  putc('a',fp);
  
/* Write offending char 26 (Hex 1A) to "temp" */
  putc(26,fp);    

/* Write 10 more 'a's to file "temp"  and close file */
  for(i=0; i < 10; i++) putc('a',fp);  /* 10 more bytes */
  fclose(fp);

/* Attempt to count # of bytes in "temp" */
  fp = fopen("temp","r");
  while( getc(fp)!= EOF) count++;
  /* should be 13 bytes */
  printf("Number of bytes: %d\n",count);
}