Re: Anecdotal: Rebase and Visual Studio 2015 and /etc
On Jul 1, 2016, at 4:40 PM, Warren Young wrote: > > I’ve written a script to do that automatically. I’ve improved the script so that it no longer requires any parameters. It finds the last-used setup.ini file and extracts the list of currently-installed packages, all on its own. Thus, calling this script is now as simple as: $ /path/to/setup*.exe -P $(/path/to/find-cyg-roots) ... find-cyg-roots Description: Binary data -- 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: Anecdotal: Rebase and Visual Studio 2015 and /etc
On Jul 1, 2016, at 4:12 PM, KARL BOTTS wrote: > > I use Cygwin32 on Windows-64. Then you’re artificially making rebase’s job harder. The list of 32-bit-only Cygwin packages is tiny these days, and you’ve just rebuilt your Cygwin environment. With my new find-cyg-roots script, you could rebuild your current 32-bit environment under Cygwin 64 quickly. That should prevent the reoccurrence of the rebase problem. > Windows itself also > uses lots of 32-bit components even under Win-64. In fact, VS itself is > a (very large) 32-bit app. Both for legacy reasons, neither of which apply to Cygwin. > 32-bit software runs so smoothly under an opsys running on > Intel64, is one of the latter's best features. 64-bit software runs on 64-bit CPUs pretty well, too. :) >> Because Satya Nadella has been in charge for only about two years now. > > You think he's in charge? Microsoft under Nadella feels a whole lot different than Microsoft under Ballmer to me. Sure he’s steering a large ship, but he *is* moving it. -- 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: Anecdotal: Rebase and Visual Studio 2015 and /etc
On Jul 1, 2016, at 1:35 PM, Warren Young wrote: > > To clone an existing install using setup.exe: > > $ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \ >-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,) [snip] > ...you can prune the long list produced by that $() construct way down I’ve written a script to do that automatically. (Attached.) It takes the raw list parsed from installed.db using the scheme above and a copy of the setup.ini file downloaded by setup.exe and removes all “non-root” packages, being those that will be installed indirectly by some other package on that list. It cut my largest local Cygwin installation’s package list down to about a fifth the size spewed out by the command above. Enjoy! find-cyg-roots Description: Binary data -- 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: Anecdotal: Rebase and Visual Studio 2015 and /etc
> A VS installation shouldn’t affect the rebase setup of Cygwin. I'm with you. But it did. I am not blaming Cygwin; I am a friend of Cygwin. >> Eventually, I reinstalled a fresh cygwin > Did you install all the same things, or a minimal install, Most of the same packages, but a from-scratch install. And it is a pretty light Cygwin: no gcc, no X, no Apache, no databases, no LaTeX... >> 1) After you do the full rebase, before you even start anything cygwin, reboot >> Windows, then start a bash or something. Reboot Windows, early and often, >> whenever upgrading anything. > I’ve never had to resort to such voodoo to keep Cygwin going. The standard > schedule of reboots due to Patch Tuesday has been sufficient. I resort to such voodoo to keep Windows going. Windows is much better than it used to be, but I still say: whenever you feel nervous about the state of Windows, reboot it. You will feel better, even if it doesn't. Voodoo is not always sufficient: silver crosses and garlic help, too. BTW: I use Cygwin32 on Windows-64. I'm happy with that. Windows itself also uses lots of 32-bit components even under Win-64. In fact, VS itself is a (very large) 32-bit app. There are good reasons for that, for them and for us. Basically, that 32-bit software runs so smoothly under an opsys running on Intel64, is one of the latter's best features. > Cygwin should never cause a Windows box to become unbootable. It simply > doesn’t get its hooks into the system deeply enough to cause such trouble, I concur wholeheartedly: Cygwin is delightfully non-intrusive, given what it does. I have never seen Cygwin hose Windows: only the reverse. MS should take a lesson. In fact, I think they are trying: they claim that the next VS will be "XCOPY deployable", which means what sane software, such as Cygwin, has always been. Mostly, it means they have to rip out all the dependencies on the goddamn Registry. Which will require many thousand kiddy-coder-hours, methinks. >> And, it moves DLLs around, even installs more, on the way back up. > “It” being Windows, or Cygwin? > If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs, unless > by some wild coincidence there is an overlap in memory load spaces. "It" being Windows. That is why you get the screen after install-stuff-then-reboot, "Configuring windows, please don't turn off your machine", and so forth. Among other things, they are delay-replacing DLLs (for which there are special Windows syscalls). Also, they "rebase" lots of DLLs, notably .NET.Framework parts, to try to optimize load time, by avoiding runtime fixups: they don't really use PIC code, if at all. Given all that, it does not seem to me that some load-address conflicts would be a "wild coincidence". > Because Satya Nadella has been in charge for only about two years now. You think he's in charge? Ha-ha, I bet so did he, when he took the job. But he is trying to change a corporate culture, without breaking too many eggs. Good luck to him. Heroin might help. --- Karl Botts, kdbo...@usa.net -- 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: Lengthy "xmlto" build step in Cygwin.
On Jul 1, 2016, at 2:52 PM, Hans-Bernhard Bröker wrote: > > Am 01.07.2016 um 20:36 schrieb Warren Young: > >> That means you have the DocBook tools installed but don’t have the >> DocBook XSL stylesheets installed > > only docbox2x-texi is checked for by winsup/doc/configure.ac. You’re in a fine position to fix that, then. :) > At least xmlto surely has to be checked for, too, don't you think? That and xsltproc, at least. > And maybe it would be possible to add a check for the docbook-xml45 package The trick is finding that out portably. You can’t check for version 4.5 stylesheets specifically, because someday the docs may move to DocBook 5. You also can’t use Cygwin-specific methods to check for this because the docs are also built on non-Cygwin systems. The official builds of everything under winsup are in fact cross-compiled on a Fedora box rather than built under Cygwin. Finally, the stylesheets may be in different locations on different machines. Probably the most portable method is something like if ! grep -q file://.*docbook /etc/xml/catalog then AC_MSG_ERROR([the DocBook stylesheets are not installed]) fi Consider that pseudocode. (Untested, written off the top of my head.) > Or, to turn this around: shouldn't one of these packages: > > xmlto > dblatex > docbook2x > > formally require package docbook-xml45 Certainly not xmlto or xsltproc, as they’re both used for more than DocBook. dblatex could, I suppose, but you’ll find that Fedora doesn’t tie those two together, either: http://koji.fedoraproject.org/koji/rpminfo?rpmID=7275706 That’s probably because dblatex will consume either XSL or SGML stylesheets, and they don’t want to depend on both. Plus, as you’ve found, the network fetch option does work; it’s just sow. Even if you fix that, there's more than just dblatex for rendering DocBook to PDF, so you’d have to chase all those avenues, too. For instance, there’s FOP, which isn’t DocBook specific, so making docbook-xsl a dependency of it would be wrong, so you’re left hangnig. docbook2x is perhaps a better candidate, though I don’t actually see a reason it’s the only possible build option. I suspect you could do everything it does in pure XSLT, obviating the need for it. So, you’d still need to call out the need for docbook-xsl in the build instructions. Bottom line, you just have to know you need these things, if you’re going to work with DocBook. It’s just part of the learning curve. -- 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
Can't Delete Home Directory - Unknown+User:Unknown+Group
I don't know how this happened, and it was probably self-inflicted, but one of the home directories in a new cygwin install has wound up owned by Unknown+User and Unknown+Group, with permissions 750. Opening the cygwin window "As Administrator" will not allow me to remove the directory or change ownership, with "Permission denied" Attempts to take ownership in windows also fail with permission errors. That's normal in my experience. This is installed on Win7 Pro 64-bit. I've done quite a few cygwin installs and rarely had more than minor problems. I'd have no objection to wiping this install and starting over, but of course I'm stuck at the "wipe" part. Thanks for any suggestions. -- 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: Use of spawnvp function makes console window appear.
On July 1, 2016 Corinna Vinschen wrote: On Jun 30 20:38, Kaz Kylheku wrote: > I tracked this down to the fhandler_console::need_invisible() call in > child_info_spawn::worker(). > > Whatever that is supposed to do is not working properly because > the invisible window is perfectly visible. Try starting the process detached: spawnvp(_P_DETACH, argv[0], argv); Without a doubt that will work, since the call to fhandler_console::need_invisible is conditional on the mode not being _P_DETACH. The problem is that sometimes you don't want this detach behavior. Secondly, this child_info_spawn::worker is used underneath various functions: exec*, spawn*, popen, system. Not all these can pass through _P_DETACH at all. (I'm only using spawnvp for the sake of producing a minimal test case). Cheers ... -- 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: Lengthy "xmlto" build step in Cygwin.
Am 01.07.2016 um 20:36 schrieb Warren Young: That means you have the DocBook tools installed but don’t have the DocBook XSL stylesheets installed, so it has to fetch them over the Internet. Those Internet servers are heavily overloaded because of all the *other* users with the same system misconfiguration you have. Well, in all fairness it has to be pointed out that this mis-configuration was set up, or at least not actively prevented, by the packages involved. Now the need for these packages _is_ actually mentioned somewhere: winsup/doc/README: === ADDITIONAL BUILD REQUIREMENTS FOR DOCUMENTATION dblatex docbook-xml45 docbook-xsl docbook2x-texi gzip texinfo xmlto === But of these only docbox2x-texi is checked for by winsup/doc/configure.ac. At least xmlto surely has to be checked for, too, don't you think? And maybe it would be possible to add a check for the docbook-xml45 package (or equivalent) here, to at least output a warning. Or, to turn this around: shouldn't one of these packages: xmlto dblatex docbook2x formally require package docbook-xml45 (and possibly all the other docbook-* packages)? -- 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
symlinks to unlinked but open files should work
Cygwin seems to look up a symlink wrong: When the target-file is unlinked while it is used by a process the file still exists and the symlink should point to that file. Test: ln -s out1 lout1 exec >lout1 rm out1 [[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2 rm lout1 Only on cygwin it prints the message. -Helmut -- -- 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: Anecdotal: Rebase and Visual Studio 2015 and /etc
On Jun 29, 2016, at 6:24 AM, KARL BOTTS wrote:
>
> A couple of weeks ago I installed Visual Studio 2015...It is a huge install
> -- 20GB disk space, more than an hour, a couple of reboots.
In a world where main storage is measured in 100s of MB per second, installing
20 gigs should not take hours. (Yes, hours: the recent upgrade to VS 2015 SP3
took two hours here.)
Maddening.
> After that, I had the now semi-familiar problems with cygwin -- "cannot fork,
> cannot load dlls", that kind of stuff.
A VS installation shouldn’t affect the rebase setup of Cygwin.
Is this a 32-bit system? If so, and you have lots of Cygwin libraries
installed, it can starve rebase of suitable library loading points. That gives
two obvious solutions: 1) Go 64-bit; or 2) Remove stuff you don’t actually need.
> Eventually, I reinstalled a fresh cygwin
Did you install all the same things, or a minimal install, which you built on
top of, installing only things you need right now? If the latter, perhaps the
actual fix was installing fewer Cygwin-based DLLs, thereby giving rebase more
freedom to place DLLs.
> 1) After you do the full rebase, before you even start anything cygwin, reboot
> Windows, then start a bash or something. Reboot Windows, early and often,
> whenever upgrading anything. This has helped me before. I suspect that I
> forgot it this last time. I _suspect_ that had I followed that, I would not
> have had to reinstall cygwin. Maybe.
I’ve never had to resort to such voodoo to keep Cygwin going. The standard
schedule of reboots due to Patch Tuesday has been sufficient.
> 2) I always have cygdrive-prefix set to /
Me, too.
> But when you reinstall cygwin, you must do it again with "mount -c". And then
> immediately do "mount -m > /etc/fstab", so that it sticks.
You’re doing it the hard way.
After a fresh install, just edit /etc/fstab. The last line in the stock
version is:
none /cygdrive cygdrive binary,posix=0,user 0 0
Just change the second field to / and restart Cygwin.
> Then, you should
> patch up the symlinks in /etc/{hosts,services,couple-more}
I’ve never manually done that, primarily because I rarely use such files via
Cygwin.
You can force Cygwin to fix such things up for you by reinstalling the
base-files package. That’s doubtless why my symlinks are in order: some
upgrade along the line fixed them for me.
> 3) Once you have a cygwin you like, you can _usually_ copy it to other hosts.
> Use cygwin cp or tar.
rsync -a should also work.
> 4) Keep yourself a list of cygwin packages you know you need,
You don’t need to; Cygwin itself remembers what you have installed.
To clone an existing install using setup.exe:
$ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \
-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,)
The installed.db file is copied from the machine whose Cygwin installation you
want to clone. It lives in /etc/setup.
If you don’t need many packages, you can prune the long list produced by that
$() construct way down, so that you install only the “root” packages that cause
all the others to be installed as dependencies.
> I have had trouble
> with the "setup -P", sometimes, but I think you could get that to work.
I’ve just tested the above command here to create a local clone. I encountered
no trouble once I had the command debugged.
> 5) Again, reboot Windows between any steps.
If that is needed after setup.exe exits, setup.exe itself will tell you. If it
doesn’t and you get no postinstall script errors, you can safely assume that
your new Cygwin installation is ready to use.
> you want to know that it _will_ reboot, anyhow.
Cygwin should never cause a Windows box to become unbootable. It simply
doesn’t get its hooks into the system deeply enough to cause such trouble,
> And, it moves
> DLLs around, even installs more, on the way back up.
“It” being Windows, or Cygwin?
If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs, unless by
some wild coincidence there is an overlap in memory load spaces. And again,
that’s solved by either using 64-bit Windows and 64-bit Cygwin or not
installing so much stuff that conflicts are near-inevitable.
If the latter, Cygwin doesn’t install new things on bootup. Once setup.exe
exits, your Cygwin installation should be stable until you fire setup.exe up
again.
> I still don't understand why MS did not just help cygwin
> get a better installation/maintenance procedure, and fix the damn fork
> problems, instead of going down the UbuntuOnWindows path.
Because Satya Nadella has been in charge for only about two years now. The
time to help Cygwin with the fork() problem was about 15 years ago. Ballmer
and his predecessors had no interest in helping Windows work with non-Windows
platforms. Nadella’s coming along now and bailing like mad, trying to keep the
ship afloat despite their two major cash cows (Office and Windows) shrinking
fast in profitability. T
Re: Lengthy "xmlto" build step in Cygwin.
On Jun 30, 2016, at 11:19 AM, Kaz Kylheku wrote: > > It sat for a long time in "book set list ..." with the CPU idle. That means you have the DocBook tools installed but don’t have the DocBook XSL stylesheets installed, so it has to fetch them over the Internet. Those Internet servers are heavily overloaded because of all the *other* users with the same system misconfiguration you have. Solution: install the docbook-xsl package. Tip: In the future, you can debug problems like this by adding --nonet to the xsltproc command. That prevents it from trying to download XSL files and such from the Internet, so that if you are missing local copies, it fails fast. IMHO that flag should be the default in the stock Makefiles. -- 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: The function ioctl bug
Hi Viacheslav,
On Jul 1 23:38, Бабенко Вячеслав wrote:
> Dear friends!
>
> The function ioctl return -1 (errno equal 95) if I use cygwin-x86_64 but
> return 0 if I use cygwin-x86.
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int c;
> int fd = socket(AF_INET, SOCK_STREAM, 0);
> if (ioctl(fd, FIONREAD, &c) == -1)
> printf("errno:%u\n", errno);
> close(fd);
> return 0;
> }
My fault. As result of a header change in newlib I also changed the
definition of FIONREAD and others in , but failed to make
sure to call Winsock's ioctlsocket with the correctly specified Winsock
FIONREAD. This only affects x86_64 as you noticed.
I applied a patch to fix this issue and uploaded new developer
snapshots to https://cygwin.com/snapshots/
(Note that recent snapshots don't work on XP and Server 2003 anymore)
Please give them a try.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: The function ioctl bug
Dear friends!
The function ioctl return -1 (errno equal 95) if I use cygwin-x86_64 but return
0 if I use cygwin-x86.
#include
#include
#include
#include
#include
int main()
{
int c;
int fd = socket(AF_INET, SOCK_STREAM, 0);
if (ioctl(fd, FIONREAD, &c) == -1)
printf("errno:%u\n", errno);
close(fd);
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Repairing permissions after windows reinstall
Andrey Repin writes: > Greetings, Henry S. Thompson! > >> Good news: My cygwin file tree survived a Windows (10) reinstall >> Not-so-good news: I have a new SID, so not only do I not own those files >> any more (that's easily fixed), but I don't have the permissions I >> should, because they are now held by some miscellaneous old SID. > > So, what? Go to top directory properties, Advanced, Owner tab, Change, and > change the owner to what is desired. Much to glib an answer. Changing the owner is the _last_ thing you want to do after (programmatically) changing a bunch of ACLs. >> In fact I see _two_ raw SIDs when I look at the security tab for any >> directory in the old cygwin tree: one has Full control, and the other >> just Read & execute. > >> I presume the first is the old me, what's the second? > If you write these SID's it would be easier to tell. ...-513 - Domain User, it turns out. >> Can this be easily fixed, i.e. put me back where I used to be? > > As Corinna said, this can be fixed, you just have to fake a valid UID for old > user to jumpstart the process. > Obviously, you would need to run the script as administrator account to work > on the permissions changes. Script is non-obvious, will share once I have mostly debugged it. 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: h...@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] -- 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: chere not seeing my preferred $HOME
Thanx to the responders to this issue. My problem, it turns out, is due to my having set up Windows environment variable "HOME", which conflicted with my Cygwin HOME. Apparently my Windows HOME overrode my Cygwin HOME; deleting the Windows HOME allowed chere to see my Cygwin HOME, and all is now good. Not sure what I'm breaking by deleting my Windows HOME, but surely something of my own creation. Thanx again! --Ken Nellis
Re: Use of spawnvp function makes console window appear.
On Jun 30 20:38, Kaz Kylheku wrote: > On 29.06.2016 15:28, Kaz Kylheku wrote: > > Hi all, > > > > I've encountered a strange behavior. When a Cygwin C application that is > > compiled with "-mwindows" tries to spawn another program, that > > application > > suddenly gets a console window! > > I tracked this down to the fhandler_console::need_invisible() call in > child_info_spawn::worker(). > > Whatever that is supposed to do is not working properly because > the invisible window is perfectly visible. Try starting the process detached: spawnvp(_P_DETACH, argv[0], argv); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
help Unsubscribe
-- 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: Syntax for sed .. altered?
Greetings, Fergus Daly! > So far sed is the only operation where extreme sloth is exhibited. A > favoured benchtest using a long computation within Cygwin has not suddenly > slowed down, and remains consistent +/- 1 second within and between > machines. More detective work required, I guess. And any "Me Too"s very > gratefully received. Just to add to your list of exploration candidates - how is your permissions configured? Are your machine is an AD member? Is it local to the AD network, or accessing domain controller remotely? Do you run cygserver? -- With best regards, Andrey Repin Friday, July 1, 2016 14:41:34 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: Why does ldd not show cyg*.dll in its output?
Hi David,
On Jun 30 23:27, David Macek wrote:
> On 29. 6. 2016 23:45, David Macek wrote:
> > I can try watching them side by side in debuggers tomorrow, maybe I'll find
> > something.
>
> Yep, found something. TL;DR the issue is that Windows spins a thread
> in the process before our DLLs are loaded. Detailed analysis below.
> [...]
> 8. EXIT_PROCESS_DEBUG_EVENT
>
> Event #6 is the culprit here. NT apparently starts a thread in our
> process which confuses ldd into believing that the process has
> finished loading DLL from its import table and kills it, as explained
> above. The thread appears non-deterministically, too, sometimes I see
> event #5 (and the associated DLL in ldd's output), sometimes not. The
> thread's entry point is always the same and ProcExp reports the same
> location (I checked in case of some symbol mash-up, as it often
> happens when debugging across the Cygwin-Windows boundary). When I
> broke ldd at `case CREATE_THREAD_DEBUG_EVENT`, the new thread's stack
> trace (from ProcExp) looked like this:
> [...]
> After some experimentation, I came up with a patch that tries to
> determine whether to ignore a thread based on the thread's entry point
> lying inside or outside of the memory occupied by ntdll.dll:
Nice detective work! As for the below patch, I think the condition
should be turned around to test if the thread entry point is inside the
Cygwin DLL. This event:
10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread = {hThread = 0x88,
lpThreadLocalBase = 0x7ff5b000, lpStartAddress = 0x180044cf0
}
denotes that we are ready. So instead of contining if the thread entry
point is inside ntdll, continue as long as the entry point is not in the
Cygwin DLL. That would also have the advantage to be independent of
future changes in Windows as well as injection from virus checkers etc.
What do you think?
> --- ldd.cc.orig 2016-04-28 21:54:57.556500700 +0200
> +++ ldd.cc 2016-06-30 23:24:20.394384800 +0200
> @@ -327,6 +327,10 @@
> {
>bool exitnow = false;
>DWORD cont = DBG_CONTINUE;
> + MODULEINFO mi;
> + HMODULE ntdll = LoadLibrary("ntdll.dll");
> + HMODULE ntdllend = NULL;
> + void *entryPoint;
>if (!WaitForDebugEvent (&ev, INFINITE))
> break;
>switch (ev.dwDebugEventCode)
> @@ -357,6 +361,31 @@
> }
> break;
> case CREATE_THREAD_DEBUG_EVENT:
> + if (ntdll != NULL)
> +{
> + if (ntdllend == NULL)
> +{
> + /* Using our ntdll.dll HMODULE with a foreign process
> + should be fine because ntdll.dll is mapped to the same
> + address in every concurrently executing process and
> + HMODULEs are just pointers to the image in the process
> + memory. Using GetModuleHandle(NULL) didn't work for the
> + author of this code (-> ERROR_INVALID_HANDLE). */
> + if (GetModuleInformation(hProcess, ntdll, &mi, sizeof(mi)))
> +ntdllend = ntdll + (ptrdiff_t)mi.SizeOfImage;
> + else
> +ntdll = NULL;
> +}
> + if (ntdllend != NULL)
> +{
> + entryPoint = (void*)ev.u.CreateThread.lpStartAddress;
> + /* If the thread's entry point is in ntdll.dll, let's
> +assume that this isn't the program's main thread and
> +ignore it. */
> + if (ntdll <= entryPoint && entryPoint < ntdllend)
> +break;
> +}
This check can be simplified. Rather than explicitly checking for start
and end address of ntdll.dll (or cygwin1.dll), one could just find the
file for a given address:
wchar_t fnamebuf[MAX_PATH];
if (GetMappedFileNameW (hProcess,
(PVOID) ev.u.CreateThread.lpStartAddress,
fnamebuf, sizeof fnamebuf)
&& wcsstr (fname, L"cygwin1.dll"))
printf ("bingo\n");
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Syntax for sed .. altered?
>> $ find archive -type f | wc 87 871698 >> $ time find archive -type f | xargs sed -i 's/string1/string2/g' real1m2.587s user0m1.200s sys 0m12.884s >> More than a minute for 90 files is just extraordinary. >> Anybody else having a similar experience? > $ find test -type f |wc 177 1775119 > $ time find test -type f | xargs sed -i -e "s/Octave/Pippo/g" real0m5.149s user0m0.170s sys 0m1.183s BLODA ? All very perplexing. Within and between 3 different machines I get very variable timings of anything from 0m 52s to 3m 08s across 90 files, but never brief. On a 4th machine I get a more or less consistent 8s. Previously I tried reverting to an earlier cygwin1.dll (much earlier: a year) and to the [prev] offering in setup for sed. No difference in experience. On local machines I have reduced all services and cut startup processes to just antivirus (MS Security Essentials or other). No difference. So this is not a consequence of a weird file set or, apparently, a faulty Cygwin installation, but a manifestation of different machine architectures / platforms. All W7 but some 32 some 64. All protected, some differently, but having no congruence with the diverse timings above. Sio far sed is the only operation where extreme sloth is exhibited. A favoured benchtest using a long computation within Cygwin has not suddenly slowed down, and remains consistent +/- 1 second within and between machines. More detective work required, I guess. And any "Me Too"s very gratefully received. Fergus -- 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: zp_fontconfig_cache_1.sh exit code 2
On 13 June 2016 at 01:35, Ken Brown wrote: > On 6/12/2016 7:26 PM, Mark McGregor wrote: >> >> Ken wrote: >>> >>> I obtained the output in the attachment, which looks good. Are you saying >>> that the message is bogus and no action is needed? >> >> >> Yes. >> >> >> Ok, thanks! It is nice to know than nothing is broken in this respect. But >> it would be also nice to get less bogus messages. > > > Agreed. I took a brief look at the fontconfig code at one point to see if I > could figure out why this was happening, but I didn't succeed and didn't > feel like spending a lot of time on it. > > Ken I have recently experienced this as well. Some sources (https://bugs.archlinux.org/task/6024 and http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg266900.html) suggest that it is some sort of time stamp related issue? -- VH -- 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
