Re: substitute for xclip?
On 19/10/2022 23:52, Oliver Schoede wrote: Hi! On Wed, 19 Oct 2022 14:58:42 +0200 Ulli Horlacher wrote: https://fex.rus.uni-stuttgart.de/fop/jFZ6T7wI/X-20221019141237.png I have selected [copy] in the file browser, but /dev/clipboard is empty. Also getclip gives me no output. It looks to me like you copied the file, not the file name? To clarify the above, Windows has a non-text clipboard data type when 'copying' a file in the File Explorer which encodes additional information other than its path. This is to allow the equivalent 'paste' function in Explorer and other file-accepting GUI applications to work more intelligently. Unfortunately, Cygwin's /dev/clipboard and get/putclip only process text formats. I imagine your X file manager is simply copying a textual representation of the file path to the clipboard when you choose 'copy' which of course can be extracted by scripts etc. It appears that Windows Explorer doesn't also place a textual representation onto the clipboard (the Windows clipboard allows multiple representations to exist simultaneously) which is what would be required for Cygwin to use it at present. -- Sam Edge -- 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: substitute for xclip?
On Thu, Oct 20, 2022 at 12:27 AM Sam Edge wrote: > On 19/10/2022 23:52, Oliver Schoede wrote: > > Hi! > > > > On Wed, 19 Oct 2022 14:58:42 +0200 > > Ulli Horlacher wrote: > >> https://fex.rus.uni-stuttgart.de/fop/jFZ6T7wI/X-20221019141237.png > >> > >> I have selected [copy] in the file browser, but /dev/clipboard is > >> empty. Also getclip gives me no output. > >> > > > > It looks to me like you copied the file, not the file name? > > > To clarify the above, Windows has a non-text clipboard data type when > 'copying' a file in the File Explorer which encodes additional > information other than its path. This is to allow the equivalent 'paste' > function in Explorer and other file-accepting GUI applications to work > more intelligently. Unfortunately, Cygwin's /dev/clipboard and > get/putclip only process text formats. > > I imagine your X file manager is simply copying a textual representation > of the file path to the clipboard when you choose 'copy' which of course > can be extracted by scripts etc. It appears that Windows Explorer > doesn't also place a textual representation onto the clipboard (the > Windows clipboard allows multiple representations to exist > simultaneously) which is what would be required for Cygwin to use it at > present. > > -- > Sam Edge You can force Windows Explorer to copy the path by doing SHIFT-RightClick on the filename and selecting "Copy as path." The next hurdle that you'll run into is that the clipboard contents will be in Windows/DOS format (c:\folder\filename) while Cygwin will most often expect it in *nix format (cygdrive/c/folder.filename). 'cygpath' is your friend. Sometimes (not clear exactly when) Cygwin will accept the Windows path, but I always convert it to *nix format to avoid unpleasant surprises later. -- 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: Debugging malloc crash in gdb
On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote: > > On 18/10/2022 11:35, David Allsopp wrote: > > I'm wondering if I may be able to have some pointers for debugging what > > seems to be an unexpected interaction between mmap/mprotect/munmap and > > malloc with the OCaml runtime. > > > > At the moment, I know that we crash in malloc, so my main question is how to > > go further in gdb. I installed the cygwin-debuginfo package, but all I'm > > getting is: > > Firstly, if the crash is inside the cygwin DLL, you must follow the > advice in [1], and use 'set cygwin-exceptions on' to tell gdb to stop on > an exception inside cygwin itself. > > [1] https://cygwin.com/faq.html#faq.programming.debugging-cygwin > > > > /cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550 > > : internal-error: void resume_1(gdb_signal): Assertion > > `pc_in_thread_step_range (pc, tp)' failed. I'm not sure now which combination of stepping directly into the malloc call, adding set cygwin-exceptions on or switching to gdb 12.1, but either way I was able to get to an invalid memory access in mmap_alloc in malloc.cc. At this point, p was a pointer to the start of the 256M block which had been passed to munmap. What I then noticed from that is a bug in our code - the mmap'd region was actually 256M+64K but the size passed to munmap was 256M... so the munmap call was not releasing the entire block. Fixing that on the OCaml side fixes the error completely - I don't know whether what we were seeing before counts as a bug in Cygwin's allocator? Many thanks! David -- 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: Debugging malloc crash in gdb
Hello David,
congrats on your bug fixing but gdb is pretty open that it considers it as
its own bug while running its "inferior", somewhere here:
if (tp->control.may_range_step)
{
/* If we're resuming a thread with the PC out of the step
range, then we're doing some nested/finer run control
operation, like stepping the thread out of the dynamic
linker or the displaced stepping scratch pad. We
shouldn't have allowed a range step then. */
gdb_assert (pc_in_thread_step_range (pc, tp));
}
whatever the logic behind setting may_range_step might be, it is (or should
be) as much decoupled from all the probable bugs in allocators of all the
possible flavours.
So, it should be investigated from the side of gdb maintainers too, for
sure, as I see it.
Kind Regards
Ariel Burbaickij
On Thu, Oct 20, 2022 at 10:22 AM David Allsopp wrote:
> On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote:
> >
> > On 18/10/2022 11:35, David Allsopp wrote:
> > > I'm wondering if I may be able to have some pointers for debugging what
> > > seems to be an unexpected interaction between mmap/mprotect/munmap and
> > > malloc with the OCaml runtime.
> > >
> > > At the moment, I know that we crash in malloc, so my main question is
> how to
> > > go further in gdb. I installed the cygwin-debuginfo package, but all
> I'm
> > > getting is:
> >
> > Firstly, if the crash is inside the cygwin DLL, you must follow the
> > advice in [1], and use 'set cygwin-exceptions on' to tell gdb to stop on
> > an exception inside cygwin itself.
> >
> > [1] https://cygwin.com/faq.html#faq.programming.debugging-cygwin
> >
> >
> > >
> /cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550
> > > : internal-error: void resume_1(gdb_signal): Assertion
> > > `pc_in_thread_step_range (pc, tp)' failed.
>
> I'm not sure now which combination of stepping directly into the
> malloc call, adding set cygwin-exceptions on or switching to gdb 12.1,
> but either way I was able to get to an invalid memory access in
> mmap_alloc in malloc.cc. At this point, p was a pointer to the start
> of the 256M block which had been passed to munmap.
>
> What I then noticed from that is a bug in our code - the mmap'd region
> was actually 256M+64K but the size passed to munmap was 256M... so the
> munmap call was not releasing the entire block. Fixing that on the
> OCaml side fixes the error completely - I don't know whether what we
> were seeing before counts as a bug in Cygwin's allocator?
>
> Many thanks!
>
>
> David
>
> --
> 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
>
--
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: Errors in building the documentation prevent compilation from completing properly
On 19/10/2022 18:57, Denis Excoffier wrote: Hello, Currently i have docbook2X not working on my system (a perl problem that i don't know how to repair, but in a few months i will reinstall completely this C:\Cygwin64 which dates back to 2019). This means that /usr/share/docbook2X and /usr/bin/docbook2x-texi are missing. Consequently, no *.info* file is produced. Nevertheless, i tried to compile cygwin from sources (newlib-cygwin-3.3.6.tar.bz2), knowing that "Normally, building ignores any errors in building the documentation" (see https://cygwin.com/faq.html#faq.programming.building-cygwin) The behaviour was changed by [1], but unfortunately the documentation change that contains has not yet been published. Use the configure option '--disable-doc'. [1] https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=f4a26ececa180cec70c41b6dd2082ff730f92065 However, in order to 'make' and then 'make install' properly, i had to apply the following easy patch (below). Hope this helps, Regards, Denis Excoffier. diff -uNr o/newlib-cygwin/winsup/doc/Makefile.am p/newlib-cygwin/winsup/doc/Makefile.am --- o/newlib-cygwin/winsup/doc/Makefile.am 2022-09-05 13:09:51.0 +0200 +++ p/newlib-cygwin/winsup/doc/Makefile.am 2022-10-19 14:00:03.052557100 +0200 @@ -61,7 +61,7 @@ install-info-local: cygwin-ug-net.info cygwin-api.info @$(MKDIR_P) $(DESTDIR)$(infodir) - $(INSTALL_DATA) *.info* $(DESTDIR)$(infodir) + -$(INSTALL_DATA) *.info* $(DESTDIR)$(infodir) Ignoring errors here is (and always was) a terrible idea, frankly. install-etc: @$(MKDIR_P) $(DESTDIR)$(sysconfdir)/postinstall @@ -141,7 +141,7 @@ # this generates a custom charmap for docbook2x-texi which has a mapping for ® charmap: - cp /usr/share/docbook2X/charmaps/texi.charmap charmap + -cp /usr/share/docbook2X/charmaps/texi.charmap charmap echo "ae (R)" >>charmap intro2man.stamp: intro.xml man.xsl -- 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: Errors in building the documentation prevent compilation from completing properly
> On 2022-10-20 12:29, Jon Turney wrote: > > On 19/10/2022 18:57, Denis Excoffier wrote: >> Hello, >> Currently i have docbook2X not working on my system (a perl problem >> that i don't know how to repair, but in a few months i will reinstall >> completely >> this C:\Cygwin64 which dates back to 2019). >> This means that /usr/share/docbook2X and /usr/bin/docbook2x-texi are missing. >> Consequently, no *.info* file is produced. >> Nevertheless, i tried to compile cygwin from sources >> (newlib-cygwin-3.3.6.tar.bz2), >> knowing that "Normally, building ignores any errors in building the >> documentation" >> (see https://cygwin.com/faq.html#faq.programming.building-cygwin) > > The behaviour was changed by [1], but unfortunately the documentation change > that contains has not yet been published. > > Use the configure option '--disable-doc'. For me, '--disable-doc' makes no difference with the unpatched code. Same errors. Sorry. Regards, Denis Excoffier. -- 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
New mirror: ftp.halifax.rwth-aachen.de
Hi, we were asked to mirror Cygwin, so here it is! Contact information: f...@halifax.rwth-aachen.de URLs: https://ftp.halifax.rwth-aachen.de/cygwin/ http://ftp.halifax.rwth-aachen.de/cygwin/ ftp://ftp.halifax.rwth-aachen.de/cygwin/ rsync://ftp.halifax.rwth-aachen.de/cygwin/ Location: Europe -> Germany We're running rsync once every six hours. The configured upstream is rsync.com/ftp/cygwin/. The initial sync is still oingoing, but should be done soon. Our mirror is able to serve data with up to 20 GBit/sec. Enjoy! :) Carsten -- Dr. Carsten Otto http://verify.rwth-aachen.de/otto/ signature.asc Description: PGP signature -- 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
