From: Tony Richardson <richardson.tony@gmail.com>
To: Ken Brown <kbrown@cornell.edu>
Cc: cygwin <cygwin@cygwin.com>
Subject: Re: graph (plotutils) seg-faulting
Date: Thu, 23 Jul 2020 12:00:44 -0500 [thread overview]
Message-ID: <CAPp9Z=XQS78DrEUtwGZsi-bg3YHVVJnqJYmM1C4cccA1+JPtpQ@mail.gmail.com> (raw)
In-Reply-To: <63b0ea9f-040b-e2a3-3835-3bd990efdc1b@cornell.edu>
On Thu, Jul 23, 2020 at 11:49 AM Ken Brown via Cygwin <cygwin@cygwin.com>
wrote:
> On 7/23/2020 12:48 AM, Marco Atzeri via Cygwin wrote:
> > On 23.07.2020 00:12, Ken Brown via Cygwin wrote:
> >> On 7/22/2020 6:07 PM, Tony Richardson via Cygwin wrote:
> >>> On Wed, Jul 22, 2020 at 3:48 PM Marco Atzeri via Cygwin <
> cygwin@cygwin.com>
> >>> wrote:
> >>>
> >>>> On 22.07.2020 14:06, Ken Brown via Cygwin wrote:
> >>>>> On 7/22/2020 1:36 AM, Marco Atzeri via Cygwin wrote:
> >>>>>> On 22.07.2020 02:10, Tony Richardson via Cygwin wrote:
> >>>>>>> I have attached both the cygcheck and strace output.
> >>>>>>>
> >>>>>>> Tony Richardson
> >>>>>>>
> >>>>>>
> >>>>>> something is clearly interfering with your Cygwin installation
> >>>>>>
> >>>>>> --- Process 11136 loaded C:\Applications\cygwin64\bin\cygwin1.dll at
> >>>>>> 0000000000c80000
> >>>>>> --- Process 11136 unloaded DLL at 0000000000c80000
> >>>>>
> >>>>> I can reproduce the problem on my system:
> >>>>>
> >>>>> $ strace graph
> >>>> ...
> >>>>
> >>>>> Segmentation fault
> >>>>>
> >>>>>
> >>>>> I thought that simply rebuilding plotutils might fix the problem, but
> >>>>> there were a lot of compilation warnings, and the build failed. Some
> of
> >>>>> the warnings look serious to me, but I have no idea if they could
> cause
> >>>>> Windows to try to load DLLs at strange addresses.
> >>>>>
> >>>>> Ken
> >>>>> --
> >>>>
> >>>> Hi Ken,
> >>>> I rebuilt and uploaded a test version 2.6-6 only for 64bit
> >>>> try to see if something change
> >>>>
> >>>> Regards
> >>>> Marco
> >>>>
> >>>
> >>> I tried the test version, unfortunately it still segfaults for me.
> > no surprise. It was unlikely to work
> >
> >>
> >> Same for me. I'm also getting strange output from ldd, but maybe
> that's just
> >> another manifestation of the same problem:
> >>
> >> $ ldd /usr/bin/graph
> >> ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff82a4c0000)
> >> KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL
> (0x7ff8289c0000)
> >> KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
> (0x7ff8280c0000)
> >> cygplot-2.dll => /usr/bin/cygplot-2.dll (0x9f0000)
> >> cygplot-2.dll => /usr/bin/cygplot-2.dll (0xbf0000)
> >> cygplot-2.dll => /usr/bin/cygplot-2.dll (0xbf0000)
> >> cygwin1.dll => /usr/bin/cygwin1.dll (0xd20000)
> >> [...]
> >> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x1760000)
> >> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x1760000)
> >> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x1780000)
> >> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x1780000)
> >>
> >> Ken
> >> --
> >
> >
> > can you check with
> > cat /proc/self/maps
> >
> > Usually I see
> >
> [snip]
>
Again nothing unusual.
>
> There really does seem to be something peculiar about the graph program.
> I
> don't recall ever seeing this behavior with any other program. Since it
> doesn't
> happen to everyone, it might depend on the Windows version. Mine is
> Windows 10
> 1909, Build 18363.959.
>
> I'm going to drop out of this discussion now. I'm not a graph user, and I
> only
> jumped in to confirm that I could reproduce the problem, so that the other
> posters wouldn't think the problem was just with their systems.
>
> Ken
>
My office machine (one of the problem machines) is running exactly the same
version/build of Windows 10.
Tony
next prev parent reply other threads:[~2020-07-23 17:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-18 21:12 briand
2020-07-19 6:04 ` Marco Atzeri
2020-07-19 15:55 ` briand
2020-07-19 17:46 ` Marco Atzeri
2020-07-19 18:23 ` briand
2020-07-19 19:15 ` Marco Atzeri
2020-07-21 3:12 ` briand
2020-07-21 4:28 ` Marco Atzeri
2020-07-21 14:50 ` Brian Inglis
2020-07-21 16:17 ` Tony Richardson
2020-07-21 23:59 ` Brian Inglis
2020-07-22 0:10 ` Tony Richardson
2020-07-22 5:36 ` Marco Atzeri
2020-07-22 12:06 ` Ken Brown
2020-07-22 20:47 ` Marco Atzeri
2020-07-22 22:07 ` Tony Richardson
2020-07-22 22:12 ` Ken Brown
2020-07-23 4:48 ` Marco Atzeri
2020-07-23 16:47 ` Ken Brown
2020-07-23 17:00 ` Tony Richardson [this message]
2020-07-23 17:17 ` Brian Inglis
2020-07-23 18:39 ` Tony Richardson
2020-07-24 6:24 ` ASSI
2020-07-22 16:30 ` Tony Richardson
2020-07-22 18:10 ` Marco Atzeri
2020-07-23 5:43 ` briand
2020-07-23 12:49 ` Tony Richardson
2020-07-23 14:40 ` marco atzeri
2020-07-23 14:48 ` Tony Richardson
2020-07-21 12:29 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPp9Z=XQS78DrEUtwGZsi-bg3YHVVJnqJYmM1C4cccA1+JPtpQ@mail.gmail.com' \
--to=richardson.tony@gmail.com \
--cc=cygwin@cygwin.com \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).