Re: mmap call gives invalid argument
On Nov 21 11:20, Carlo Florendo wrote:
> On Wed, Nov 19, 2008 at 11:44 PM, Corinna Vinschen wrote:
> > Try building Cygwin from scratch after disabling the first `if' statement
> > in fhandler_dev_mem::mmap (file winsup/cygwin/mmap.cc). If that helps,
> > it seems that this check is too well meant and we should better rely on
> > the OS function doing the right thing.
>
> Ok. I've recompiled cygwin. I've also attached the new cygcheck.
>
> The diff output below shows the only change I did. So essentially, we
> just let the compiler skip the if statement you mentioned.
>
> --- mmap.cc.orig2008-11-21 11:06:48.0 +0800
> +++ mmap.cc 2008-11-21 11:06:59.0 +0800
> @@ -1825,6 +1825,7 @@ HANDLE
> fhandler_dev_mem::mmap (caddr_t *addr, size_t len, int prot,
> int flags, _off64_t off)
> {
> +#ifdef IGNORE_CFF_DMIDECODE_ISSUE
>if (off >= mem_size
>|| (DWORD) len >= mem_size
>|| off + len >= mem_size)
> @@ -1833,6 +1834,7 @@ fhandler_dev_mem::mmap (caddr_t *addr, s
>debug_printf ("-1 = mmap(): illegal parameter, set EINVAL");
>return INVALID_HANDLE_VALUE;
> }
> +#endif
>
>UNICODE_STRING memstr;
>RtlInitUnicodeString (&memstr, L"\\device\\physicalmemory");
>
>
> In spite of that, after recompiling dmidecode with the new
> cygwin1.dll, this is what we get:
>
> $ ./dmidecode.exe
> /dev/mem: mmap: Invalid argument
> # dmidecode 2.9
> SMBIOS 2.5 present.
> 54 structures occupying 1495 bytes.
> Table at 0x3BEE3000.
>
> The new strace is here: http://astra.ph/research/carlo/strace2.out
>
> Is this some problem associated with accessing the device because it's 1GB?
I don't know. See the strace yourself:
156 133660 [main] dmidecode 2092 mmap64: addr 0, len 13783, prot 1, flags 1,
fd 3, off 1005453312
101 133761 [main] dmidecode 2092 MapViewNT: 0 = NtMapViewOfSection (h:6F8,
addr:0, len:13783, off:1005453312, protect:2, type:0)
85 133846 [main] dmidecode 2092 seterrno_from_win_error:
/home/Administrator/cygwin-1.5.25-15/winsup/cygwin/mmap.cc:1871 windows error 87
79 133925 [main] dmidecode 2092 geterrno_from_win_error: windows error 87
== errno 22
74 133999 [main] dmidecode 2092 __set_errno: void
seterrno_from_win_error(const char*, int, DWORD):310 val 22
82 134081 [main] dmidecode 2092 mmap64: 0x = mmap()
Now you get the error message directly from Windows. Unfortunately,
we don't see the actual NTSTATUS value returned by NtMapViewOfSection
because I left the value out of the debug message. Silly me!
What you see is the converted Win32 error code 87, which is
ERROR_INVALID_PARAMETER. The actual NTSTATUS code might give you
another hint. Just change the debug_printf statement in the MapViewNT
function (mmap.cc line 384) to
debug_printf ("%p (status %p) = NtMapViewOfSection (h:%x, addr:%x, len:%u,"
" off:%D, protect:%x, type:%x)",
base, ret, h, addr, len, off, protect, 0);
recompile, rerun, and look for the "NtMapViewOfSection" lines in
the strace output. What's the hex status code?
However, since this fails on the native NT level, I don't think this is
just a simple Cygwin problem. It seems that this SMBIOS stuff is
somehow broken on that system.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: Run OpenSSH service with Local System Account
On Nov 20 15:37, William Zhang wrote: > Hi All, > > Sorry i hit the send button by mistake before I finished the last > mail. This is my > full question. > > I am wondering if there is a way to run the Cygwin OpenSSH service as > Local System Account in Windows 2003 and 2008 instead of the > cyg_server account created during the setup. I am using > Cygwin+OpenSSH on the Windows test server and I remotely execute > automation testing script from a linux box. However the program This won't work. The reason why you can't use the LocalSystem account to run sshd (*and* get pubkey authentication) is not a Cygwin restriction, but a Windows restriction. With Windows 2008 this works even worse because the "Interact with desktop" has been officially deprecated for security reasons. It's still available in the services GUI but it doesn't work as on earlier systems. There are probably other workarounds for your problem. What exactly are you testing? Why do you need interaction with the desktop, even though you're doing automated script testing? For instance, the official workaround as propagated by Microsoft is to start the application by the user account running the desktop session and to use IPC mechanisms (named pipes, sockets) to communicate between the service and the desktop application. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: ddrescue-1.9-1
Version 1.9-1 of ddrescue has been uploaded. http://www.gnu.org/software/ddrescue/ddrescue.html Description from README: GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors. The basic operation of ddrescue is fully automatic. That is, you don't have to wait for an error, stop the program, read the log, run it in reverse mode, etc. If you use the logfile feature of ddrescue, the data is rescued very efficiently, (only the needed blocks are read). Also you can interrupt the rescue at any time and resume it later at the same point. Ddrescue is also able to selectively overwrite parts of the output file, which has a number of interesting uses like wiping data, marking bad areas or even, in some cases, "repair" damaged sectors. Upstream NEWS: * The new option "--domain-logfile" has been added. * Verbosity control of user messages has been simplified. Christian Franke -- 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 keep clicking "Next". If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
Cygwin 1.7: O_DIRECT read from raw devices returns EOF
On cygwin 1.7.0-32, read() from raw devices returns 0 always if device
was opened with O_DIRECT.
Testcase:
$ dd if=/dev/sdb of=/dev/null count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.027 s, 19.0 kB/s
$ dd if=/dev/sdb of=/dev/null count=1 iflag=direct
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0 s, Infinity B/s
Same for /dev/scd0, /dev/fd0.
Bug was probably introduced in fhandler_dev_floppy.cc 1.51:
void
fhandler_dev_floppy::raw_read (void *ptr, size_t& ulen)
{
...
DWORD bytes_to_read = 0;
...
if (devbuf)
{ /* !O_DIRECT ... */ }
else
{
_off64_t current_position = get_current_position ();
if (current_position + bytes_to_read >= drive_size)
bytes_to_read = drive_size - current_position;
if (bytes_to_read && !read_file (p, len, &bytes_read, &ret))
...
In the O_DIRECT case, bytes_to_read is always 0.
Christian
--
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: Cygwin 1.7: O_DIRECT read from raw devices returns EOF
On Nov 21 13:58, Christian Franke wrote:
> void
> fhandler_dev_floppy::raw_read (void *ptr, size_t& ulen)
> {
> ...
> DWORD bytes_to_read = 0;
> ...
> if (devbuf)
> { /* !O_DIRECT ... */ }
> else
> {
> _off64_t current_position = get_current_position ();
> if (current_position + bytes_to_read >= drive_size)
> bytes_to_read = drive_size - current_position;
> if (bytes_to_read && !read_file (p, len, &bytes_read, &ret))
> ...
>
> In the O_DIRECT case, bytes_to_read is always 0.
Indeed. Thanks for catching this bug! I've checked in a patch.
Would you mind to give it a whirl?
Thanks again,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
Problem with aliases in bash as login shell
When bash is started with the "-l" (that's an 'L') flag, aliases that I've defined in .bashrc don't take effect. My .bash_profile includes a call to .bashrc, and I know that .bashrc is being executed because I've put an echo at the beginning and end of it, and both messages are printed out. Even if I execute .bashrc manually, it will print out the messages, but I get no aliases. I can, however, manually enter aliases, and they work. I can also copy/paste the aliases from .bashrc to the command line, and then they work. -- 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: Problem with aliases in bash as login shell
Hi Ryan, > -Original Message- > From: [EMAIL PROTECTED] ... > When bash is started with the "-l" (that's an 'L') flag, aliases that > I've defined in .bashrc don't take effect. My .bash_profile includes a > call to .bashrc, and I know that .bashrc is being executed because ... I bet Your line with the call of .bashrc from .bash_profile looks like .bashrc change it to . .bashrc and it will do what You intend and then RTFM for an explanation :-) best regards, matthias -- 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: Setup wants to revert my upgrade of Emacs
Jonathan Ferro wrote on Friday, November 21, 2008 7:05 AM:: > Casual browsing recently revealed that one of my all-time favorite > software packages, Emacs Calc, has returned to active maintenance and > is part of the GNU Emacs distribution. My thought: why does my > Cygwin installation not have it? > > Setup run 1: Fiddling with Setup shows that I can turn all three of > emacs, emacs-el, and emacs-X11 to "22.1-3" instead of "21.2-13". > Score! > Problem: 21.2-13 is uninstalled and nothing is installed. It's too late now, but you can usually find out why by checking the setup log files. > Setup run 2: I can turn all three packages to "22.1-3" and *manually > check* the binary box, something I've never had to do manually > before. > This correctly installs all 3 packages, for now. > > Setup run 3: When rerunning Setup to look at something else, > fortunately I am in the habit of always looking at the "Partial" view > before hitting Next, and I see that it has queued up all three > packages to be reinstalled to version "21.2-13". > I have canceled out of that Setup session, but I'd like to figure out > how to get my choice to "stick". > > Am I asking in the right place, regarding the dependency information > for the emacs package? > Should this be regarded as a general problem? (I.e., is there some > technical or policy issue preventing 22.1-3 from being listed as the > "new" version?) > Is there something I can do to remove these packages from the > maintenance upgrade list in my installation for now, so that I can > stick with my chosen version? > The problem is that the current emacs is 21.2 (see the setup.ini in your package download directory). The 22.1 version is experimental ([test]). Setup defaults to "upgrading" to the current stable version, which unfortunately means it tries to downgrade any experimental packages. This is one of the costs of living on the bleeding edge (yes, I know 22 has been out a while now) Although your choice won't stick, you can click on the emacs version number in setup until it shows "Keep" to prevent it downgrading. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 8:46 AM, Morche Matthias <[EMAIL PROTECTED]> wrote: > I bet Your line with the call of .bashrc from .bash_profile looks like > .bashrc > change it to > . .bashrc > and it will do what You intend and then RTFM for an explanation :-) > Thanks. I'm a linux nub. It took a good bit of looking to find an explanation though, especially since no search engine understands "." as a search term. -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 09:10:32AM -0600, Ryan Stewart wrote: >On Fri, Nov 21, 2008 at 8:46 AM, Morche Matthias ><[EMAIL PROTECTED]> wrote: >> I bet Your line with the call of .bashrc from .bash_profile looks like >> .bashrc >> change it to >> . .bashrc >> and it will do what You intend and then RTFM for an explanation :-) >> >Thanks. I'm a linux nub. It took a good bit of looking to find an >explanation though, especially since no search engine understands "." >as a search term. google is not the final authority. "info bash" or "man bash" would give you this info much more directly. -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 9:13 AM, Christopher Faylor <[EMAIL PROTECTED]> wrote: > google is not the final authority. "info bash" or "man bash" would give > you this info much more directly. > A nearly 4900 line man page is not exactly "direct". That was the first place I looked. It was also the last place I looked, but even knowing more or less what I was looking for, I couldn't find it. Can you point me to a line number in the man page? -- 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: Problem with aliases in bash as login shell
Ryan Stewart wrote: " A nearly 4900 line man page is not exactly "direct". That was the " first place I looked. It was also the last place I looked, but even " knowing more or less what I was looking for, I couldn't find it. Can " you point me to a line number in the man page? The '.' command is a synonym for the 'source' command. Searching for source in the bash man page will turn up use of this word in numerous contexts, but will find the one you want after not too many false positives. stephan(); -- 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: Problem with aliases in bash as login shell
On 2008-11-21 15:24Z, Ryan Stewart wrote: > On Fri, Nov 21, 2008 at 9:13 AM, Christopher Faylor > <[EMAIL PROTECTED]> wrote: ^^ http://www.cygwin.com/acronyms/#PCYMTNQREAIYR >> google is not the final authority. "info bash" or "man bash" would give >> you this info much more directly. >> > A nearly 4900 line man page is not exactly "direct". That was the > first place I looked. It was also the last place I looked, but even > knowing more or less what I was looking for, I couldn't find it. Can > you point me to a line number in the man page? Copy and paste the following two lines separately, hitting Enter after each one, to search for a literal period surrounded by spaces in the manpage: man bash / \.[ ] Hit 'n' ['N'] to move to the next [previous] occurrence. -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 09:10:32AM -0600, Ryan Stewart wrote: >On Fri, Nov 21, 2008 at 8:46 AM, Morche Matthias ><[EMAIL PROTECTED]> wrote: >> I bet Your line with the call of .bashrc from .bash_profile looks like >> .bashrc >> change it to >> . .bashrc >> and it will do what You intend and then RTFM for an explanation :-) >> >Thanks. I'm a linux nub. It took a good bit of looking to find an >explanation though, especially since no search engine understands "." >as a search term. Type "info bash" or "man bash" and then: / \. ^ ^ space here to searche for space dot space. This may not hit the appropriate description in the first try but typing "n" will get you there quickly. Also, knowing that "." is a command you can look under "SHELL BUILTIN COMMANDS". -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 10:24 AM, Ryan Stewart wrote: > A nearly 4900 line man page is not exactly "direct". That was the > first place I looked. It was also the last place I looked, but even > knowing more or less what I was looking for, I couldn't find it. Can > you point me to a line number in the man page? To be fair, you have to do a lot of reading to learn the necessary concepts; there's not really a simple statement you can search for. Start with the section "COMMAND EXECUTION ENVIRONMENT", which is at line 1665 on my system (but I'm not using Cygwin ATM). "The shell has an execution environment, which consists of [...] shell aliases defined with alias [...] When a simple command other than a builtin or shell function is executed, it is invoked in a separate execution environment [...] A command invoked in this separate environment cannot affect the shell's execution envrionment". So basically, any command you run gets its own copy of the shell environment and can't change anything. Environment variables, aliases, current working dir, etc. There is no way to have the DOS effect of running a batch file and finding your command prompt in a different directory at the end of it (a nasty surprise for someone coming the other way from UNIX to DOS for the first time!) You can run .bash_profile all you want, but every time you're starting a new copy of the shell that gets thrown away when it hits the end of the file. So far, it sounds like you're out of luck, but the other piece of info is in the description of the "source" built-in (line 2681 for me): "source filename [arguments] Read and execute commands from filename *in the current shell environment* " (emphasis mine). Now, the "." command is a synonym for "source" - it's what the "source" command was called in the original UNIX shell, probably because it was most often used with files whose names start with ".". It's the more common way to load a file into the current envionment, but source is probably the easier command to find in the doc and would have worked as well. -- Mark J. Reed <[EMAIL PROTECTED]> -- 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 9:52 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote: > To be fair, you have to do a lot of reading to learn the necessary > concepts; there's not really a simple statement you can search for. > Start with the section "COMMAND EXECUTION ENVIRONMENT", which is at > line 1665 on my system (but I'm not using Cygwin ATM). > [...] "COMMAND EXECUTION ENVIRONMENT"--that's what I needed. Thanks for the detailed explanation! -- 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/
setup.ini keeps updating with nothing altered except timestamp
Subject says all. Half a dozen times or more today setup.ini has got a new timestamp with nothing else altered, e.g.: ~> diff tmp.setup.ini setup.ini 5c5 < setup-timestamp: 1227280844 --- > setup-timestamp: 1227270014 (where tmp is the "current" version just downloaded from a mirror, and the other was the "current" version just a while back). Has something got stuck in a groundhog kind of a way? 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: Problem with aliases in bash as login shell
On Fri, Nov 21, 2008 at 10:58 AM, Ryan Stewart wrote: > On Fri, Nov 21, 2008 at 9:52 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote: ^^ There's a policy on this list of not including email addresses in the body of messages, so as to minimize spam exposure. So please don't include addresses in quoted material. (http://cygwin.com/acronyms/#PCYMTNQREAIYR) (My address is in my .sig at the bottom of every message I post, so I'm clearly among the more cavalier on this point, but it's one thing to do it with your own address and another to include someone else's...) > "COMMAND EXECUTION ENVIRONMENT"--that's what I needed. Thanks for the > detailed explanation! No problem. -- Mark J. Reed <[EMAIL PROTECTED]> -- 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: Run OpenSSH service with Local System Account
Hi Corinna, Thank you for the clarification. It is a Microsoft driver testing tool and it can run automated mode so that it will dismiss the confirmation dialog boxes automatically in a regular session but it will hang in a windows service context when those confirmation dialog box pops up. I figured a workaround. Basically I call the task and scheduler utility (schtasks.exe) from the testing script running in the service context to create a task and run it. The task runs the GUI test tool in the currently logged on user context and can interact with its desktop. Whew... case closed. Thanks, William On Fri, Nov 21, 2008 at 2:31 AM, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > On Nov 20 15:37, William Zhang wrote: >> Hi All, >> >> Sorry i hit the send button by mistake before I finished the last >> mail. This is my >> full question. >> >> I am wondering if there is a way to run the Cygwin OpenSSH service as >> Local System Account in Windows 2003 and 2008 instead of the >> cyg_server account created during the setup. I am using >> Cygwin+OpenSSH on the Windows test server and I remotely execute >> automation testing script from a linux box. However the program > > This won't work. The reason why you can't use the LocalSystem account > to run sshd (*and* get pubkey authentication) is not a Cygwin > restriction, but a Windows restriction. With Windows 2008 this works > even worse because the "Interact with desktop" has been officially > deprecated for security reasons. It's still available in the services > GUI but it doesn't work as on earlier systems. > > There are probably other workarounds for your problem. What exactly > are you testing? Why do you need interaction with the desktop, even > though you're doing automated script testing? > > For instance, the official workaround as propagated by Microsoft is to > start the application by the user account running the desktop session > and to use IPC mechanisms (named pipes, sockets) to communicate between > the service and the desktop application. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On Thu, Nov 20, 2008 at 3:40 PM, Lonni J Friedman <[EMAIL PROTECTED]> wrote: > Greetings, > I'm attempting to setup a build environment, which happens to require > cygwin. I ran into no problems getting this up with 32bit Windows XP, > however for both WINXP64 and VISTA64, the cygwin installation blows up > badly while running all of the postinstall scripts (in > /etc/postinstall). Nearly all of them are segfaulting. > > For example, if I attempt to run /etc/postinstall/bash.sh manually, it > churns for a few seconds, and then dies with the following output: > 11 [main] bash 1644 +_cygtls::handle_exceptions: Error while dumping > state ( probably a corrupted stack) > Segmentation fault (core dumped) > > The only potential oddity in this equation is that my Windows (both 32 > & 64bit) installations are inside of Xen (running on a Linux system). > > I'm at a complete loss on how to debug this at this point. Any and > all suggestions are gratefully accepted. No suggestions? Anyway, it also looks like I'm getting a stackdump every dump this segfaults which includs the following: ## Exception: STATUS_ACCESS_VIOLATION at eip=7D61C95D eax= ebx=0022C4D8 ecx= edx= esi=FFFE edi= ebp=0022C4A8 esp=0022C45C program=C:\cygwin\bin\bash.exe, pid 924, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0022C4A8 7D61C95D (0274, FFFE, 0022C4D8, 0001) 61169E30 6101CDEB (000F, 8010, 0274, ) 6113F9B8 044F (610FE560, 610FE530, 610FDB40, 6101E4A0) 610FE950 610FDB70 (90909090, 90909090, 90C3C031, 90909090) 11 [main] bash 924 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ## -- 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 Cygwin Package: fetchmail-6.3.9-1
New News: === I have updated the version of fetchmail to 6.3.9-1. The tarballs should be available on a Cygwin mirror near you shortly. The only change between this version and the previous one is the following: o update to version 6.3.9 Old News: === Fetchmail is a remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links, like SLIP or PPP connections. Fetchmail supports every remote-mail protocol currently in use on the Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6, and IPSEC) for retrieval. Then Fetchmail forwards the mail through SMTP so you can read it through your favorite mail client. See the fetchmail home page for more details: http://fetchmail.berlios.de/ Please read the README file: /usr/share/doc/Cygwin/fetchmail-6.3.9.README since it covers requirements, installation, known issues, etc. 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
Lonni J Friedman wrote: On Thu, Nov 20, 2008 at 3:40 PM, Lonni J Friedman wrote: Greetings, I'm attempting to setup a build environment, which happens to require cygwin. I ran into no problems getting this up with 32bit Windows XP, however for both WINXP64 and VISTA64, the cygwin installation blows up badly while running all of the postinstall scripts (in /etc/postinstall). Nearly all of them are segfaulting. For example, if I attempt to run /etc/postinstall/bash.sh manually, it churns for a few seconds, and then dies with the following output: 11 [main] bash 1644 +_cygtls::handle_exceptions: Error while dumping state ( probably a corrupted stack) Segmentation fault (core dumped) The only potential oddity in this equation is that my Windows (both 32 & 64bit) installations are inside of Xen (running on a Linux system). I'm at a complete loss on how to debug this at this point. Any and all suggestions are gratefully accepted. No suggestions? Anyway, it also looks like I'm getting a stackdump every dump this segfaults which includs the following: ## Exception: STATUS_ACCESS_VIOLATION at eip=7D61C95D eax= ebx=0022C4D8 ecx= edx= esi=FFFE edi= ebp=0022C4A8 esp=0022C45C program=C:\cygwin\bin\bash.exe, pid 924, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0022C4A8 7D61C95D (0274, FFFE, 0022C4D8, 0001) 61169E30 6101CDEB (000F, 8010, 0274, ) 6113F9B8 044F (610FE560, 610FE530, 610FDB40, 6101E4A0) 610FE950 610FDB70 (90909090, 90909090, 90C3C031, 90909090) 11 [main] bash 924 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ## There's been one other report, that I recall, of problems running Cygwin under Xen but AFAIK, no one on the list who's digging into the code is using it (or at least seeing the problem when using it.) Whatever the problem is, it seems specific to Xen since other VMs run Cygwin fine. Certainly the stack suggests that the crash happens in bash and not the Cygwin DLL, though I'm not sure that this says much. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: python-pyrex 0.9.8.5-1
Version 0.9.8.5-1 of "python-pyrex" has been uploaded. It lets you write code that mixes Python and C data types any way you want, and compiles it into a C extension for Python. 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. -- 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On Fri, Nov 21, 2008 at 04:51:03PM -0500, Larry Hall (Cygwin) wrote: > Lonni J Friedman wrote: >> On Thu, Nov 20, 2008 at 3:40 PM, Lonni J Friedman wrote: >>> Greetings, >>> I'm attempting to setup a build environment, which happens to require >>> cygwin. I ran into no problems getting this up with 32bit Windows XP, >>> however for both WINXP64 and VISTA64, the cygwin installation blows up >>> badly while running all of the postinstall scripts (in >>> /etc/postinstall). Nearly all of them are segfaulting. >>> >>> For example, if I attempt to run /etc/postinstall/bash.sh manually, it >>> churns for a few seconds, and then dies with the following output: >>> 11 [main] bash 1644 +_cygtls::handle_exceptions: Error while dumping >>> state ( probably a corrupted stack) >>> Segmentation fault (core dumped) >>> >>> The only potential oddity in this equation is that my Windows (both 32 >>> & 64bit) installations are inside of Xen (running on a Linux system). >>> >>> I'm at a complete loss on how to debug this at this point. Any and >>> all suggestions are gratefully accepted. >> No suggestions? Anyway, it also looks like I'm getting a stackdump >> every dump this segfaults which includs the following: >> ## >> Exception: STATUS_ACCESS_VIOLATION at eip=7D61C95D >> eax= ebx=0022C4D8 ecx= edx= esi=FFFE >> edi= >> ebp=0022C4A8 esp=0022C45C program=C:\cygwin\bin\bash.exe, pid 924, thread >> main >> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >> Stack trace: >> Frame Function Args >> 0022C4A8 7D61C95D (0274, FFFE, 0022C4D8, 0001) >> 61169E30 6101CDEB (000F, 8010, 0274, ) >> 6113F9B8 044F (610FE560, 610FE530, 610FDB40, 6101E4A0) >> 610FE950 610FDB70 (90909090, 90909090, 90C3C031, 90909090) >> 11 [main] bash 924 _cygtls::handle_exceptions: Error while >> dumping state (probably corrupted stack) >> ## > > There's been one other report, that I recall, of problems running > Cygwin under Xen but AFAIK, no one on the list who's digging into > the code is using it (or at least seeing the problem when using it.) > Whatever the problem is, it seems specific to Xen since other VMs run > Cygwin fine. Certainly the stack suggests that the crash happens in > bash and not the Cygwin DLL, though I'm not sure that this says much. > ;-) Actually the stack suggests that it is happening in a system call (0x7D61C95D) from the cygwin DLL (0xc101CDEB) but your observations and conclusions are still the same. I'm not aware of anyone actively investigating Xen problems. Hopefully this observation won't trigger a "Well, it seems to me..." or a "Death of Cygwin unless..." from anyone. 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On Fri, Nov 21, 2008 at 3:02 PM, Christopher Faylor <[EMAIL PROTECTED]> wrote: > On Fri, Nov 21, 2008 at 04:51:03PM -0500, Larry Hall (Cygwin) wrote: >> Lonni J Friedman wrote: >>> On Thu, Nov 20, 2008 at 3:40 PM, Lonni J Friedman wrote: Greetings, I'm attempting to setup a build environment, which happens to require cygwin. I ran into no problems getting this up with 32bit Windows XP, however for both WINXP64 and VISTA64, the cygwin installation blows up badly while running all of the postinstall scripts (in /etc/postinstall). Nearly all of them are segfaulting. For example, if I attempt to run /etc/postinstall/bash.sh manually, it churns for a few seconds, and then dies with the following output: 11 [main] bash 1644 +_cygtls::handle_exceptions: Error while dumping state ( probably a corrupted stack) Segmentation fault (core dumped) The only potential oddity in this equation is that my Windows (both 32 & 64bit) installations are inside of Xen (running on a Linux system). I'm at a complete loss on how to debug this at this point. Any and all suggestions are gratefully accepted. >>> No suggestions? Anyway, it also looks like I'm getting a stackdump >>> every dump this segfaults which includs the following: >>> ## >>> Exception: STATUS_ACCESS_VIOLATION at eip=7D61C95D >>> eax= ebx=0022C4D8 ecx= edx= esi=FFFE >>> edi= >>> ebp=0022C4A8 esp=0022C45C program=C:\cygwin\bin\bash.exe, pid 924, thread >>> main >>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >>> Stack trace: >>> Frame Function Args >>> 0022C4A8 7D61C95D (0274, FFFE, 0022C4D8, 0001) >>> 61169E30 6101CDEB (000F, 8010, 0274, ) >>> 6113F9B8 044F (610FE560, 610FE530, 610FDB40, 6101E4A0) >>> 610FE950 610FDB70 (90909090, 90909090, 90C3C031, 90909090) >>> 11 [main] bash 924 _cygtls::handle_exceptions: Error while >>> dumping state (probably corrupted stack) >>> ## >> >> There's been one other report, that I recall, of problems running >> Cygwin under Xen but AFAIK, no one on the list who's digging into >> the code is using it (or at least seeing the problem when using it.) >> Whatever the problem is, it seems specific to Xen since other VMs run >> Cygwin fine. Certainly the stack suggests that the crash happens in >> bash and not the Cygwin DLL, though I'm not sure that this says much. >> ;-) > > Actually the stack suggests that it is happening in a system call > (0x7D61C95D) from the cygwin DLL (0xc101CDEB) but your observations and > conclusions are still the same. I'm not aware of anyone actively > investigating Xen problems. This looks very similar to my problem (except that disabling TS doesn't seem to help): http://www.nabble.com/Re:-cygwin-bash-crashes-on-Win-Serv-2008-td20131536.html *sigh* -- ~ L. Friedman[EMAIL PROTECTED] LlamaLand https://netllama.linux-sxs.org -- 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On 11/21/2008, Christopher Faylor wrote: Actually the stack suggests that it is happening in a system call (0x7D61C95D) from the cygwin DLL (0xc101CDEB) but your observations and conclusions are still the same. I'm not aware of anyone actively investigating Xen problems. Doh! I read the stack upside down. Hopefully this observation won't trigger a "Well, it seems to me..." or a "Death of Cygwin unless..." from anyone. Right. There's no point in arguing that. After all, Windows is dead so... ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On Fri, Nov 21, 2008 at 03:49:43PM -0800, Lonni J Friedman wrote: >This looks very similar to my problem (except that disabling TS >doesn't seem to help): >http://www.nabble.com/Re:-cygwin-bash-crashes-on-Win-Serv-2008-td20131536.html > >*sigh* Except for the fact that something crashes I don't see any similarity at all. It's unlikely that you're going to find a magic bullet here. It's more likely that this will require building Cygwin and debugging the problem. -- 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: nearly all postinstall scripts segfaulting in 64bit Windows (XP + Vista)
On Fri, Nov 21, 2008 at 6:04 PM, Christopher Faylor <[EMAIL PROTECTED]> wrote: > On Fri, Nov 21, 2008 at 03:49:43PM -0800, Lonni J Friedman wrote: >>This looks very similar to my problem (except that disabling TS >>doesn't seem to help): >>http://www.nabble.com/Re:-cygwin-bash-crashes-on-Win-Serv-2008-td20131536.html >> >>*sigh* > > Except for the fact that something crashes I don't see any similarity at > all. > > It's unlikely that you're going to find a magic bullet here. It's more > likely that this will require building Cygwin and debugging the problem. I know nothing about debugging cygwin (or windows) problems. Is there something specific that I should be doing? -- 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: mmap call gives invalid argument
On Fri, Nov 21, 2008 at 6:20 PM, Corinna Vinschen wrote:
>
> 156 133660 [main] dmidecode 2092 mmap64: addr 0, len 13783, prot 1, flags
> 1, fd 3, off 1005453312
> 101 133761 [main] dmidecode 2092 MapViewNT: 0 = NtMapViewOfSection (h:6F8,
> addr:0, len:13783, off:1005453312, protect:2, type:0)
> 85 133846 [main] dmidecode 2092 seterrno_from_win_error:
> /home/Administrator/cygwin-1.5.25-15/winsup/cygwin/mmap.cc:1871 windows error
> 87
> 79 133925 [main] dmidecode 2092 geterrno_from_win_error: windows error 87
> == errno 22
> 74 133999 [main] dmidecode 2092 __set_errno: void
> seterrno_from_win_error(const char*, int, DWORD):310 val 22
> 82 134081 [main] dmidecode 2092 mmap64: 0x = mmap()
>
> Now you get the error message directly from Windows. Unfortunately,
> we don't see the actual NTSTATUS value returned by NtMapViewOfSection
> because I left the value out of the debug message. Silly me!
>
> What you see is the converted Win32 error code 87, which is
> ERROR_INVALID_PARAMETER. The actual NTSTATUS code might give you
> another hint. Just change the debug_printf statement in the MapViewNT
> function (mmap.cc line 384) to
>
> debug_printf ("%p (status %p) = NtMapViewOfSection (h:%x, addr:%x, len:%u,"
>" off:%D, protect:%x, type:%x)",
>base, ret, h, addr, len, off, protect, 0);
>
> recompile, rerun, and look for the "NtMapViewOfSection" lines in
> the strace output. What's the hex status code?
>
> However, since this fails on the native NT level, I don't think this is
> just a simple Cygwin problem. It seems that this SMBIOS stuff is
> somehow broken on that system.
Thank you very much Corinna. I will definitely try that out. The
machine in question, unfortunately, had been pulled out and I would
have access to it only in the next week or two. Hence, my updates
regarding this topic would come a little bit later. I am, however,
interested in a resolution, if there is any. Thanks to all you've
suggested.
Until then.
Best Regards,
Carlo
--
Carlo Florendo
Software Engineer
Astra Philippines - Software Development and Outsourcing
R&D: http://astra.ph, Astra Group: http://astra.co.jp
--
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/
