public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Hans-Bernhard Bröker" <HBBroeker@t-online.de>
To: cygwin@cygwin.com
Subject: Re: headache on build repeatibility: octave vs BLODA ?
Date: Wed, 29 Jan 2020 00:03:00 -0000	[thread overview]
Message-ID: <f2d0d267-cca2-bec4-e6a4-1a8d64ebff57@t-online.de> (raw)
In-Reply-To: <2904b4fa-6349-bd3e-c4ff-4b32a0bb3838@gmail.com>

Am 25.01.2020 um 17:55 schrieb Marco Atzeri:

>    libinterp/corefcn/file-io.cc-tst 
> ...............................fatal: caught signal Segmentation fault 
> -- stopping myself...
> /bin/sh: line 1:  3771 Segmentation fault      (core dumped) /bin/sh 
> ../run-octave --norc --silent --no-history -p 
> /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/build/test/mex 
> /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test/fntests.m 
> /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test 

> Can anyone try to rebuild the Octave package and let me know
> if the segfault during test is present or not in your system ?

The problem occurs the same way, here, running Win10 Pro 1909 fully 
updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running 
besides Defender.

> Be aware that build time is very long (~ 4 hours) and requires
> a ton of mathematical libraries.

The build itself completed in ~30 minutes, here ;-).  But then this is a 
fresh i9, 8-core, 16-thread box.

cygport install took ages to complete, though, because objcopy takes 
spectacularly long to strip those DLLs --- longer than it took to build 
the whole package! And it does them one at a time.  That could profit 
from some parallelization.

So while I waited, I decided to try it with the distributed octave.exe 
instead.
It passes the critical tests without issue.

Next step, after cygport inst is done: run the test with the executable 
in cygport's "inst" directory (to bypass libtool): Success, again!

So I tried running the test via libtool, i.e. the run-octave script. 
And boom it goes.

So re-run it in gdb, via libtool (run-octave -g ...).  Still crashes, 
but I didn't manage to get around the SIGSEGV handler in octave.  It 
always caught the SEGV before gdb managed to get there.

So my finding, so far, would be that this is related to libtool.  Maybe 
some update to Windows broke the way libtool interacts with 
not-quite-finished executables...

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

  parent reply	other threads:[~2020-01-29  0:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-25 16:55 Marco Atzeri
2020-01-25 18:15 ` Brian Inglis
2020-01-27  6:54   ` Marco Atzeri
2020-01-25 20:36 ` Achim Gratz
2020-01-26  6:58   ` Marco Atzeri
2020-01-26  8:05     ` ASSI
2020-01-26  8:38       ` Marco Atzeri
2020-01-27  6:45         ` Marco Atzeri
2020-01-27 11:33           ` Takashi Yano
2020-01-28  6:41             ` Marco Atzeri
2020-01-28 14:55               ` Takashi Yano
2020-01-29  9:44               ` Corinna Vinschen
2020-01-29 12:19                 ` Marco Atzeri
2020-01-29 13:46                   ` Takashi Yano
2020-01-29 15:11                     ` Takashi Yano
2020-01-29 15:32                     ` Corinna Vinschen
2020-01-29 15:34                       ` Corinna Vinschen
2020-01-29 16:08                         ` Takashi Yano
2020-01-29 17:57                           ` Corinna Vinschen
2020-01-30 21:05                     ` Brian Inglis
2020-01-30 21:34                       ` Marco Atzeri
2020-01-28 17:26   ` ASSI
2020-01-28 20:04     ` Marco Atzeri
2020-01-28 20:21       ` Achim Gratz
2020-01-26  2:42 ` Takashi Yano
2020-01-26  5:11   ` Takashi Yano
2020-01-26 10:24     ` Marco Atzeri
2020-01-26 10:31       ` Takashi Yano
2020-01-29  0:03 ` Hans-Bernhard Bröker [this message]
2020-01-29  0:39   ` Hans-Bernhard Bröker
2020-01-29  5:10   ` Marco Atzeri

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=f2d0d267-cca2-bec4-e6a4-1a8d64ebff57@t-online.de \
    --to=hbbroeker@t-online.de \
    --cc=cygwin@cygwin.com \
    /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).