Re: headache on build repeatibility: octave vs BLODA ?
Am 30.01.2020 um 22:05 schrieb Brian Inglis: On 2020-01-29 06:46, Takashi Yano wrote: Hi Marco, On Wed, 29 Jan 2020 13:19:11 +0100 Marco Atzeri wrote: As Octave uses gnulib, it is possible that the changes in MS are causing a different subset of gnulib to be used than before, may be exposing a latent bug or race. Unfortunately my old build tree was polluted by mistake, so I can not directly compare a good build tree versus a failing one. I found suspicious difference between the working build and the not-working build. The not-working build has fflush.o, fseek.o and fseeko.o in build/libgnu/.libs directory, while the working build does not. Also, cygoctave-7.dll of not-working build exports rpl_fflush, rpl_fseek and rpl_fseeko, while that of the working build does not. As a test, I used following patch to forcibly remove the code setting REPLACE_FSEEKO to 1 in configure script, and rebuilt octave. This works without segmentation fault. For these to be considered missing or deficient such that they should be provided or replaced gnulib must consider Cygwin lacking support for ANSI C fflush https://www.gnu.org/software/gnulib/MODULES.html#ansic_enh_stdio and POSIX 2008 fseek and fseeko supporting pipes and 4GB in 32 bit mode https://www.gnu.org/software/gnulib/MODULES.html#posix_sup perhaps as a result of incorrect conclusions about Cygwin in autoreconf? I was able to rebuild 5.1.0 successfully on a x86_64 cygwin1.dll built from git source. Nor flush or fseek gnulib modules were built. During weekend I will replicate with i686. Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
On 2020-01-29 06:46, Takashi Yano wrote: > Hi Marco, > > On Wed, 29 Jan 2020 13:19:11 +0100 > Marco Atzeri wrote: >> As Octave uses gnulib, it is possible that the changes in MS are causing >> a different subset of gnulib to be used than before, may be exposing >> a latent bug or race. >> >> Unfortunately my old build tree was polluted by mistake, so I can >> not directly compare a good build tree versus a failing one. > > I found suspicious difference between the working build and the > not-working build. > > The not-working build has fflush.o, fseek.o and fseeko.o in > build/libgnu/.libs > directory, while the working build does not. > > Also, cygoctave-7.dll of not-working build exports rpl_fflush, > rpl_fseek and rpl_fseeko, while that of the working build does > not. > > As a test, I used following patch to forcibly remove the code > setting REPLACE_FSEEKO to 1 in configure script, and rebuilt > octave. This works without segmentation fault. For these to be considered missing or deficient such that they should be provided or replaced gnulib must consider Cygwin lacking support for ANSI C fflush https://www.gnu.org/software/gnulib/MODULES.html#ansic_enh_stdio and POSIX 2008 fseek and fseeko supporting pipes and 4GB in 32 bit mode https://www.gnu.org/software/gnulib/MODULES.html#posix_sup perhaps as a result of incorrect conclusions about Cygwin in autoreconf? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: headache on build repeatibility: octave vs BLODA ?
On Jan 30 01:08, Takashi Yano wrote: > On Wed, 29 Jan 2020 16:34:28 +0100 > Corinna Vinschen wrote: > > On Jan 29 16:32, Corinna Vinschen wrote: > > > On Jan 29 22:46, Takashi Yano wrote: > > > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900 > > > > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900 > > > > @@ -30,16 +30,19 @@ > > > > HAVE_FSEEKO=0 > > > >else > > > > if test $WINDOWS_64_BIT_OFF_T = 1; then > > > > This makes me a bit suspicious... it looks like a check only > > required for native builds, not for Cygwin. > > I think REPLACE_FSEEKO is set to 1 not here, > > > > > m4_ifdef([gl_FUNC_FFLUSH_STDIN], [ > > > >gl_FUNC_FFLUSH_STDIN > > > >case "$gl_cv_func_fflush_stdin" in > > > > *yes) ;; > > > > -*) REPLACE_FSEEKO=1 ;; > > > > +dnl *) REPLACE_FSEEKO=1 ;; > > > > +*) REPLACE_FSEEKO=0 ;; > > > >esac > > but here. > > gl_cv_func_fflush_stdin is set here in configure by: > > if ac_fn_c_try_run "$LINENO"; then : > gl_cv_func_fflush_stdin=yes > else > gl_cv_func_fflush_stdin=no > fi > > and the test code for this decision is as attached. conftest.c > returns 0 in cygwin 3.0.7, while cygwin with commit 59362c80e3a > returns 5. > > I am not sure why segfault occurs if fseeko is replaced. > Probably due to a bug in octave or cygwin. Thanks, that was very helpful. I'll revert commit 59362c80e3a0. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Fwd: Re: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 16:39 schrieb Hans-Bernhard Bröker: [Ooops, sent this to Takashi instead of the list, originally.] Am 29.01.2020 um 14:46 schrieb Takashi Yano: On Wed, 29 Jan 2020 13:19:11 +0100 Marco Atzeri wrote: As Octave uses gnulib, it is possible that the changes in MS are causing a different subset of gnulib to be used than before, may be exposing a latent bug or race. Note that fp->_seek64 is actually null, so this is calling a null pointer, possibly caused by gnulib interfering with the call sequence? or applying the wrong sequence to a Posix system, that portion of Octave is built using gnulib submodules. It seems the new build are taking the wrong pieces. Thank to both for your efforts Marco -- 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: headache on build repeatibility: octave vs BLODA ?
On Wed, 29 Jan 2020 16:34:28 +0100
Corinna Vinschen wrote:
> On Jan 29 16:32, Corinna Vinschen wrote:
> > On Jan 29 22:46, Takashi Yano wrote:
> > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900
> > > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900
> > > @@ -30,16 +30,19 @@
> > > HAVE_FSEEKO=0
> > >else
> > > if test $WINDOWS_64_BIT_OFF_T = 1; then
>
> This makes me a bit suspicious... it looks like a check only
> required for native builds, not for Cygwin.
I think REPLACE_FSEEKO is set to 1 not here,
> > > m4_ifdef([gl_FUNC_FFLUSH_STDIN], [
> > >gl_FUNC_FFLUSH_STDIN
> > >case "$gl_cv_func_fflush_stdin" in
> > > *yes) ;;
> > > -*) REPLACE_FSEEKO=1 ;;
> > > +dnl *) REPLACE_FSEEKO=1 ;;
> > > +*) REPLACE_FSEEKO=0 ;;
> > >esac
but here.
gl_cv_func_fflush_stdin is set here in configure by:
if ac_fn_c_try_run "$LINENO"; then :
gl_cv_func_fflush_stdin=yes
else
gl_cv_func_fflush_stdin=no
fi
and the test code for this decision is as attached. conftest.c
returns 0 in cygwin 3.0.7, while cygwin with commit 59362c80e3a
returns 5.
I am not sure why segfault occurs if fseeko is replaced.
Probably due to a bug in octave or cygwin.
--
Takashi Yano
#include
# include
int
main ()
{
FILE *f = fopen ("conftest.txt", "r");
char buffer[10];
int fd;
int c;
if (f == NULL)
return 1;
fd = fileno (f);
if (fd < 0 || fread (buffer, 1, 5, f) != 5)
{ fclose (f); return 2; }
/* For deterministic results, ensure f read a bigger buffer. */
if (lseek (fd, 0, SEEK_CUR) == 5)
{ fclose (f); return 3; }
/* POSIX requires fflush-fseek to set file offset of fd. This fails
on BSD systems and on mingw. */
if (fflush (f) != 0 || fseek (f, 0, SEEK_CUR) != 0)
{ fclose (f); return 4; }
if (lseek (fd, 0, SEEK_CUR) != 5)
{ fclose (f); return 5; }
/* Verify behaviour of fflush after ungetc. See
*/
/* Verify behaviour of fflush after a backup ungetc. This fails on
mingw. */
c = fgetc (f);
ungetc (c, f);
fflush (f);
if (fgetc (f) != c)
{ fclose (f); return 6; }
/* Verify behaviour of fflush after a non-backup ungetc. This fails
on glibc 2.8 and on BSD systems. */
c = fgetc (f);
ungetc ('@', f);
fflush (f);
if (fgetc (f) != c)
{ fclose (f); return 7; }
fclose (f);
return 0;
;
return 0;
}
hello world
--
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
Fwd: Re: headache on build repeatibility: octave vs BLODA ?
[Ooops, sent this to Takashi instead of the list, originally.]
Am 29.01.2020 um 14:46 schrieb Takashi Yano:
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may be exposing
a latent bug or race.
Unfortunately my old build tree was polluted by mistake, so I can
not directly compare a good build tree versus a failing one.
I found suspicious difference between the working build and the
not-working build.
The not-working build has fflush.o, fseek.o and fseeko.o in
build/libgnu/.libs
directory, while the working build does not.
Also, cygoctave-7.dll of not-working build exports rpl_fflush,
rpl_fseek and rpl_fseeko, while that of the working build does
not.
That's very interesting, as one of those: rpl_fseeko, is indeed in the
code path to the crash:
=
#0 0x in ?? ()
#1 0x00018019b9c7 in __sflush_r (ptr=ptr@entry=0xd680,
fp=fp@entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:179
#2 0x00018019baeb in _fflush_r (ptr=ptr@entry=0xd680,
fp=fp@entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:278
#3 0x00018019fd67 in _fseeko_r (ptr=0xd680, fp=0x800080ae8,
offset=4, whence=0) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fseeko.c:314
#4 0x0001801346bb in _sigfe () at sigfe.s:35
#5 0x00042cdc77d9 in c_file_ptr_buf::seekoff (this=0x800223dc0,
offset=, dir=) at
/usr/src/debug/octave-5.1.0-1/libinterp/corefcn/c-file-ptr-stream.cc:118
#6 0x0003d7fd72b3 in cygstdc++-6!_ZNSi5tellgEv () from
/usr/bin/cygstdc++-6.dll
#7 0x00042d0881da in octave::textscan::scan
(this=this@entry=0xb470, isp=..., fmt=..., ntimes=ntimes@entry=2,
options=..., count=@0xb6f8: 0)
=
(Yes, neither fseeko nor rpl_fseeko can bee seen here, but they were
passed as part of executing #5: seekoff.
Here's me stepping into that seekoff() call, in a later gdb session:
=
Thread 1 "doctave-cli" hit Breakpoint 1, c_file_ptr_buf::seekoff
(this=0x800220eb0, offset=0, dir=std::_S_cur) at
/usr/src/debug/octave-5.1.0-1/libinterp/corefcn/c-file-ptr-stream.cc:115
115 {
(gdb) s
116 if (f)
(gdb)
118 octave_fseeko_wrapper (f, offset, seekdir_to_whence (dir));
(gdb)
octave_fseeko_wrapper (fp=0x800080ae8, offset=0, whence=1) at
/usr/src/debug/octave-5.1.0-1/liboctave/wrappers/filepos-wrappers.c:40
40 }
(gdb)
rpl_fseeko (fp=0x800080ae8, offset=0, whence=1) at
/usr/src/debug/octave-5.1.0-1/libgnu/fseeko.c:42
42 {
(gdb)
58if ((fp->_flags & __SL64) == 0)
(gdb)
42 {
(gdb)
58if ((fp->_flags & __SL64) == 0)
(gdb)
70if (fp_->_p == fp_->_bf._base
(gdb)
163 return fseeko (fp, offset, whence);
(gdb)
164 }
(gdb)
163 return fseeko (fp, offset, whence);
(gdb)
/wip/cygport-git/gdb/gdb-8.2.1-1.x86_64/src/gdb-8.2.1/gdb/infrun.c:2723:
internal-error: void resume_1(gdb_signal): Assertion
`pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
Re: headache on build repeatibility: octave vs BLODA ?
On Jan 29 16:32, Corinna Vinschen wrote: > On Jan 29 22:46, Takashi Yano wrote: > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900 > > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900 > > @@ -30,16 +30,19 @@ > > HAVE_FSEEKO=0 > >else > > if test $WINDOWS_64_BIT_OFF_T = 1; then This makes me a bit suspicious... it looks like a check only required for native builds, not for Cygwin. > > - REPLACE_FSEEKO=1 > > + dnl REPLACE_FSEEKO=1 > > + REPLACE_FSEEKO=0 > > fi > > if test $gl_cv_var_stdin_large_offset = no; then > > - REPLACE_FSEEKO=1 > > + dnl REPLACE_FSEEKO=1 > > + REPLACE_FSEEKO=0 > > fi > > m4_ifdef([gl_FUNC_FFLUSH_STDIN], [ > >gl_FUNC_FFLUSH_STDIN > >case "$gl_cv_func_fflush_stdin" in > > *yes) ;; > > -*) REPLACE_FSEEKO=1 ;; > > +dnl *) REPLACE_FSEEKO=1 ;; > > +*) REPLACE_FSEEKO=0 ;; > >esac > > Commit 59362c80e3a in newlib you mention in your other mail should be a > minor change and the code looks pretty much the same in FreeBSD, while > OpenBSD and NetBSD are more similar to the old newlib code. Both > implementations should be ok, in theory. > > So, the question is, what exactly is this test testing? Can it be > extracted from the autoconf stuff and converted to a simple testcase > which proves that the behaviour is now wrong? > > If so, I'll revert commit 59362c80e3a. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: headache on build repeatibility: octave vs BLODA ?
On Jan 29 22:46, Takashi Yano wrote: > Hi Marco, > > On Wed, 29 Jan 2020 13:19:11 +0100 > Marco Atzeri wrote: > > As Octave uses gnulib, it is possible that the changes in MS are causing > > a different subset of gnulib to be used than before, may be exposing > > a latent bug or race. > > > > Unfortunately my old build tree was polluted by mistake, so I can > > not directly compare a good build tree versus a failing one. > > I found suspicious difference between the working build and the > not-working build. > > The not-working build has fflush.o, fseek.o and fseeko.o in > build/libgnu/.libs > directory, while the working build does not. > > Also, cygoctave-7.dll of not-working build exports rpl_fflush, > rpl_fseek and rpl_fseeko, while that of the working build does > not. > > As a test, I used following patch to forcibly remove the code > setting REPLACE_FSEEKO to 1 in configure script, and rebuilt > octave. This works without segmentation fault. > > I do not look into the reason why this difference causes yet. > > I would be happy if this could help. > > --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900 > +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900 > @@ -30,16 +30,19 @@ > HAVE_FSEEKO=0 >else > if test $WINDOWS_64_BIT_OFF_T = 1; then > - REPLACE_FSEEKO=1 > + dnl REPLACE_FSEEKO=1 > + REPLACE_FSEEKO=0 > fi > if test $gl_cv_var_stdin_large_offset = no; then > - REPLACE_FSEEKO=1 > + dnl REPLACE_FSEEKO=1 > + REPLACE_FSEEKO=0 > fi > m4_ifdef([gl_FUNC_FFLUSH_STDIN], [ >gl_FUNC_FFLUSH_STDIN >case "$gl_cv_func_fflush_stdin" in > *yes) ;; > -*) REPLACE_FSEEKO=1 ;; > +dnl *) REPLACE_FSEEKO=1 ;; > +*) REPLACE_FSEEKO=0 ;; >esac Commit 59362c80e3a in newlib you mention in your other mail should be a minor change and the code looks pretty much the same in FreeBSD, while OpenBSD and NetBSD are more similar to the old newlib code. Both implementations should be ok, in theory. So, the question is, what exactly is this test testing? Can it be extracted from the autoconf stuff and converted to a simple testcase which proves that the behaviour is now wrong? If so, I'll revert commit 59362c80e3a. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: headache on build repeatibility: octave vs BLODA ?
On Wed, 29 Jan 2020 22:46:53 +0900 Takashi Yano wrote: > On Wed, 29 Jan 2020 13:19:11 +0100 > Marco Atzeri wrote: > > As Octave uses gnulib, it is possible that the changes in MS are causing > > a different subset of gnulib to be used than before, may be exposing > > a latent bug or race. > > > > Unfortunately my old build tree was polluted by mistake, so I can > > not directly compare a good build tree versus a failing one. > > I found suspicious difference between the working build and the > not-working build. > > The not-working build has fflush.o, fseek.o and fseeko.o in > build/libgnu/.libs > directory, while the working build does not. > > Also, cygoctave-7.dll of not-working build exports rpl_fflush, > rpl_fseek and rpl_fseeko, while that of the working build does > not. > > As a test, I used following patch to forcibly remove the code > setting REPLACE_FSEEKO to 1 in configure script, and rebuilt > octave. This works without segmentation fault. > > I do not look into the reason why this difference causes yet. Perhaps, the cause of this behaviour change is: commit 59362c80e3a02c011fd0ef3d7f07a20098d2a9d5 Author: Bastien Bouclet Date: Sat Nov 9 17:28:04 2019 +0100 newlib: fix fseek optimization with SEEK_CUR The call to fflush was invalidating the read buffer, preventing relative seeks to positions that would have been inside the read buffer from being optimized. The call to srefill would then re-read mostly the same data that was initially in the read buffer. Recently, I executed make only in winsup/cygwin, so this newlib change did not affect. Therefore this change was not included in my local cygwin1.dll binary. As for Win10 Home machine, which causes the problem, cygwin1.dll is v3.1.2, so this is affected. -- Takashi Yano -- 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: headache on build repeatibility: octave vs BLODA ?
Hi Marco, On Wed, 29 Jan 2020 13:19:11 +0100 Marco Atzeri wrote: > As Octave uses gnulib, it is possible that the changes in MS are causing > a different subset of gnulib to be used than before, may be exposing > a latent bug or race. > > Unfortunately my old build tree was polluted by mistake, so I can > not directly compare a good build tree versus a failing one. I found suspicious difference between the working build and the not-working build. The not-working build has fflush.o, fseek.o and fseeko.o in build/libgnu/.libs directory, while the working build does not. Also, cygoctave-7.dll of not-working build exports rpl_fflush, rpl_fseek and rpl_fseeko, while that of the working build does not. As a test, I used following patch to forcibly remove the code setting REPLACE_FSEEKO to 1 in configure script, and rebuilt octave. This works without segmentation fault. I do not look into the reason why this difference causes yet. I would be happy if this could help. --- m4/fseeko.m4.orig 2020-01-29 21:39:37.280507900 +0900 +++ m4/fseeko.m42020-01-29 21:36:29.263747100 +0900 @@ -30,16 +30,19 @@ HAVE_FSEEKO=0 else if test $WINDOWS_64_BIT_OFF_T = 1; then - REPLACE_FSEEKO=1 + dnl REPLACE_FSEEKO=1 + REPLACE_FSEEKO=0 fi if test $gl_cv_var_stdin_large_offset = no; then - REPLACE_FSEEKO=1 + dnl REPLACE_FSEEKO=1 + REPLACE_FSEEKO=0 fi m4_ifdef([gl_FUNC_FFLUSH_STDIN], [ gl_FUNC_FFLUSH_STDIN case "$gl_cv_func_fflush_stdin" in *yes) ;; -*) REPLACE_FSEEKO=1 ;; +dnl *) REPLACE_FSEEKO=1 ;; +*) REPLACE_FSEEKO=0 ;; esac ]) fi --- m4/fflush.m4.orig 2020-01-29 21:40:07.546238000 +0900 +++ m4/fflush.m42020-01-29 21:38:02.079793700 +0900 @@ -16,7 +16,8 @@ gl_FUNC_FFLUSH_STDIN case "$gl_cv_func_fflush_stdin" in *yes) ;; -*) REPLACE_FFLUSH=1 ;; +dnl *) REPLACE_FFLUSH=1 ;; +*) REPLACE_FFLUSH=0 ;; esac ]) -- Takashi Yano -- 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: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 10:44 schrieb Corinna Vinschen: On Jan 28 07:41, Marco Atzeri wrote: Am 27.01.2020 um 12:33 schrieb Takashi Yano: On Mon, 27 Jan 2020 07:45:08 +0100 Marco Atzeri wrote: Can you and Takashi provide me your cygcheck.out so that I can look on possible difference that could influence the build behaviour. Attached. Thanks Takashi, I duplicated your installation from scratch on my W10 Home and it fails again in the same place. So I am now almost sure that the recent MS updates changed/broke something in W10 Home. :-(( Assuming it does not break German systems and left immune Japanese ones :-? I will try to install the same in a W10 Pro and if that does not segfault I can try the lengthy process to compare the object/dll/exec files to see where is the difference. Corinna, there are specific code differences in Cygwin DLL between W10 Home and Pro ? Sorry for the late reply, Marco. No, there are no code differences in Cygwin based on "Home" vs. "Pro" vs. "Enterprise" editions. Differences are mainly based on Windows versions, as in W10 1803, W10 1809, etc. Other differences in code execution are based on workstation vs. server (evaluating scheduling timing from registry) or stand-alone vs. domain machine (passwd/group stuff). Of course, even small differences in your setup (Windows permissions, etc.) may lead to very different code execution. If you suspect a Cygwin bug, it would be helpful to see an strace of the crash. Corinna If is a BUG, it seems at compilation time as it produces binary with different behaviour than before. I was not able to segfault the old binary, I have problem in all new built binaries. I assume the 1909 build 18363.592 2020-01-14 arisen it. As Octave uses gnulib, it is possible that the changes in MS are causing a different subset of gnulib to be used than before, may be exposing a latent bug or race. Unfortunately my old build tree was polluted by mistake, so I can not directly compare a good build tree versus a failing one. Just noticed that MS released yesterday a 18363.628 2020-01-28 unusually just 2 weeks after previous one. https://docs.microsoft.com/en-us/windows/release-information/ Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
On Jan 28 07:41, Marco Atzeri wrote: > Am 27.01.2020 um 12:33 schrieb Takashi Yano: > > On Mon, 27 Jan 2020 07:45:08 +0100 > > Marco Atzeri wrote: > > > Can you and Takashi provide me your cygcheck.out so that I can look on > > > possible difference that could influence the build behaviour. > > > > Attached. > > > > Thanks Takashi, > > I duplicated your installation from scratch on my W10 Home > and it fails again in the same place. > > So I am now almost sure that the recent MS updates changed/broke > something in W10 Home. :-(( > > Assuming it does not break German systems and left immune > Japanese ones :-? > > I will try to install the same in a W10 Pro and if that > does not segfault I can try the lengthy process to compare > the object/dll/exec files to see where is the difference. > > > Corinna, > there are specific code differences in Cygwin DLL between > W10 Home and Pro ? Sorry for the late reply, Marco. No, there are no code differences in Cygwin based on "Home" vs. "Pro" vs. "Enterprise" editions. Differences are mainly based on Windows versions, as in W10 1803, W10 1809, etc. Other differences in code execution are based on workstation vs. server (evaluating scheduling timing from registry) or stand-alone vs. domain machine (passwd/group stuff). Of course, even small differences in your setup (Windows permissions, etc.) may lead to very different code execution. If you suspect a Cygwin bug, it would be helpful to see an strace of the crash. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
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.
Nice toy. Here just a notebook with i5 4-core
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.
there are only 2 gigant dll`s
$ find . -name "cyg*dll" -exec du -sh {} \;
55M ./libgui/.libs/cygoctgui-5.dll
536M./libinterp/.libs/cygoctinterp-7.dll
213M./liboctave/.libs/cygoctave-7.dll
the rest is penauts
$ find . -name "*oct" -exec du -sh {} \;
67M ./libgui/graphics/__init_qt__.oct
1.3M./libinterp/dldfcn/amd.oct
3.0M./libinterp/dldfcn/audiodevinfo.oct
1.8M./libinterp/dldfcn/audioread.oct
1.4M./libinterp/dldfcn/ccolamd.oct
1.6M./libinterp/dldfcn/chol.oct
1.5M./libinterp/dldfcn/colamd.oct
1.4M./libinterp/dldfcn/convhulln.oct
1.2M./libinterp/dldfcn/dmperm.oct
1.2M./libinterp/dldfcn/fftw.oct
1.3M./libinterp/dldfcn/gzip.oct
1.7M./libinterp/dldfcn/qr.oct
1.3M./libinterp/dldfcn/symbfact.oct
1.3M./libinterp/dldfcn/symrcm.oct
1.4M./libinterp/dldfcn/__delaunayn__.oct
2.6M./libinterp/dldfcn/__eigs__.oct
1.3M./libinterp/dldfcn/__fltk_uigetfile__.oct
1.4M./libinterp/dldfcn/__glpk__.oct
3.8M./libinterp/dldfcn/__init_fltk__.oct
2.8M./libinterp/dldfcn/__init_gnuplot__.oct
2.5M./libinterp/dldfcn/__ode15__.oct
1.5M./libinterp/dldfcn/__voronoi__.oct
on the x86 build takes longer :-(
So while I waited, I decided to try it with the distributed octave.exe
instead.
It passes the critical tests without issue.
my experience also. I was not able to make crash the old (by one month)
version
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...
I had also the fresh executable installed and it also can fail.
My guess is that it is in someplace different as behaviour than the old
one.
So libtool can help to trigger but it is not necessary.
Regards
Marco
--
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: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker: 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... This is getting curiouser. I was intrigued that the stackdump file written was not from 'octave' per se, but rather 'octave-cli'. And indeed some further experiments shows that ../../inst/usr/bin/octave-cli-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test fails, while ../../inst/usr/bin/octave-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test passes. I don't see how 'run-octave' would end up running octave-cli, though, unless it had been given the option '-cli'. -- 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: headache on build repeatibility: octave vs BLODA ?
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
Re: headache on build repeatibility: octave vs BLODA ?
Marco Atzeri writes: > I just found that my W10 Home is 1909 build 18363.592 so probably was > updated as your around mid Jan > > https://docs.microsoft.com/en-us/windows/release-information/ > > But Corporate versions have different time table and patch Enterprise is, yes. > the one I have is Version 1709 Build 16299.15 > It seems Corporate IT is forgetting to update it at all. They currently have at least three different release branches which are supported (for the clients, server versions is yet another story). At my company they switched us to 1803 recently. Going forward I think there will be fewer supported options even for Enterprise if I read things correctly. But MS will have to wait out until the current support periods end. > This release had caused problems to some AV, so may be is changing > the play in area that are causing problems also to us. I still think it's a latent bug that manifests just now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: headache on build repeatibility: octave vs BLODA ?
Am 28.01.2020 um 18:25 schrieb ASSI: Achim Gratz writes: Same thing here… Since some of the discussion revolved on Windows versions: that is on Win10 Pro 1909, fully patched. I no longer have a system with 1809 since the period where you could hold up the update has expired recently. There is an ISO image for Windows Server 2016 LTS (essentially 1709 I think) that you can use for free for 90 days (you can install it into a VHD and then boot that). To (offixcially) get other Windows versions for testing you'd either have to have the licenses or have some sort of subscription with MSDN. If you do have older install media or ISO, then of course you can do the install into the VHD trick again. A Win 10 Pro can boot the VHD in a Hyper-V instance. Regards, Achim. Ok Achim, you destroyed my theory I just found that my W10 Home is 1909 build 18363.592 so probably was updated as your around mid Jan https://docs.microsoft.com/en-us/windows/release-information/ But Corporate versions have different time table and patch the one I have is Version 1709 Build 16299.15 It seems Corporate IT is forgetting to update it at all. May be Takashi one is also behind in update and currently free from the new bug/behaviour. What I found interesting is that https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1909 This release had caused problems to some AV, so may be is changing the play in area that are causing problems also to us. Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
Achim Gratz writes: > Same thing here… Since some of the discussion revolved on Windows versions: that is on Win10 Pro 1909, fully patched. I no longer have a system with 1809 since the period where you could hold up the update has expired recently. There is an ISO image for Windows Server 2016 LTS (essentially 1709 I think) that you can use for free for 90 days (you can install it into a VHD and then boot that). To (offixcially) get other Windows versions for testing you'd either have to have the licenses or have some sort of subscription with MSDN. If you do have older install media or ISO, then of course you can do the install into the VHD trick again. A Win 10 Pro can boot the VHD in a Hyper-V instance. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: headache on build repeatibility: octave vs BLODA ?
On Tue, 28 Jan 2020 07:41:43 +0100 Marco Atzeri wrote: > So I am now almost sure that the recent MS updates changed/broke > something in W10 Home. :-(( I have tried now in Win10 Home 1909, and segmentagion fault has occured at the same place as you. Microsoft Windows [Version 10.0.18363.592] -- Takashi Yano -- 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: headache on build repeatibility: octave vs BLODA ?
Am 27.01.2020 um 12:33 schrieb Takashi Yano: On Mon, 27 Jan 2020 07:45:08 +0100 Marco Atzeri wrote: Can you and Takashi provide me your cygcheck.out so that I can look on possible difference that could influence the build behaviour. Attached. Thanks Takashi, I duplicated your installation from scratch on my W10 Home and it fails again in the same place. So I am now almost sure that the recent MS updates changed/broke something in W10 Home. :-(( Assuming it does not break German systems and left immune Japanese ones :-? I will try to install the same in a W10 Pro and if that does not segfault I can try the lengthy process to compare the object/dll/exec files to see where is the difference. Corinna, there are specific code differences in Cygwin DLL between W10 Home and Pro ? Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
Am 25.01.2020 um 19:15 schrieb Brian Inglis: On 2020-01-25 09:55, Marco Atzeri wrote: Now I am seriously thinking about BLODA, but I have not noted any difference from the two AVs I was using Antivir and MS Defender, so I am wandering if last update for W10 Home x64 is the culprit. Also what W10 feature release YYMM and/or build N are you on? Betriebssystemname:Microsoft Windows 10 Home Betriebssystemversion: 10.0.18363 Nicht zutreffend Build 18363 Can anyone try to rebuild the Octave package and let me know if the segfault during test is present or not in your system ? Be aware that build time is very long (~ 4 hours) and requires a ton of mathematical libraries. Any suggestion will be appreciated Should this discussion perhaps be handled on cygwin-apps? We don't always want to advertise just how messy the Cygwin package making sausage factory can be. ;^> Sausage and Beer are a serious matter here in Munich; and both production must be clean and transparent ;-) I believe the following Cygwin tools and libraries packages, pulled from the package doc build dependencies, and found and filtered using apt-cyg listall, to be sufficient, but may not all be necessary, and should be added to octave.cygport, where it can be used as a build dependency install package list for apt-cyg or setup: DEPEND="autoconf automake bison flex gcc-core gcc-fortran gcc-g++ gperf gnuplot libtool make texinfo libopenblas liblapack-devel libpcre-devel libarpack-devel libparpack-devel libcurl-devel libfftw3-devel libfltk-devel libfontconfig-devel libfreetype-devel libglpk-devel libgl2ps-devel libGraphicsMagick-devel libhdf5-devel libllvm-devel libportaudio-devel libQtOpenGL4-devel libqhull-devel libqrupdate-devel libqscintilla2-devel libqscintilla2_qt4-devel libqscintilla2_qt5-devel libqt3-devel libsuitesparseconfig-devel libsundials-devel zlib-devel" Are there any changes you would make, especially for arpack, OpenGL, qt, scintilla? As I mentioned it needs a ton of libraries but I built with QT5 $ grep "libraries:" config.log Fortran libraries: -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0 -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../.. -lm -lsuitesparseconfig -lgfortran -lquadmath -lcygwin -ladvapi32 -lshell32 -luser32 Lex libraries: AMD libraries: -lamd -lsuitesparseconfig ARPACK libraries: -larpack BLAS libraries:-lblas BZ2 libraries: -lbz2 CAMD libraries:-lcamd -lsuitesparseconfig CARBON libraries: CCOLAMD libraries: -lccolamd -lsuitesparseconfig CHOLMOD libraries: -lcholmod -lsuitesparseconfig COLAMD libraries: -lcolamd -lsuitesparseconfig CURL libraries:-lcurl CXSPARSE libraries:-lcxsparse -lsuitesparseconfig DL libraries: FFTW3 libraries: -lfftw3_threads -lfftw3 FFTW3F libraries: -lfftw3f_threads -lfftw3f FLTK libraries:-lfltk_gl -lfltk fontconfig libraries: -lfontconfig -lfreetype FreeType2 libraries: -lfreetype GLPK libraries:-lglpk HDF5 libraries:-lhdf5 Java libraries: KLU libraries: -lklu -lsuitesparseconfig LAPACK libraries: -llapack LLVM libraries: Magick++ libraries:-lGraphicsMagick++ -lGraphicsMagick OpenGL libraries: -lGL -lGLU PCRE libraries:-lpcre PortAudio libraries: -lportaudio -lwinmm -lm PTHREAD libraries: QHULL libraries: -lqhull QRUPDATE libraries:-lqrupdate Qt GUI libraries: -lQt5Network -lQt5PrintSupport -lQt5Help -lQt5Widgets -lQt5Gui -lQt5Sql -lQt5Xml -lQt5Core -lqscintilla2-qt5 Qt OpenGL libraries: -lQt5OpenGL -lQt5Widgets -lQt5Gui -lQt5Core READLINE libraries:-lreadline Sndfile libraries: -lsndfile SuiteSparse config libraries: -lsuitesparseconfig SUNDIALS IDA libraries:-lsundials_ida SUNDIALS NVECTOR libraries:-lsundials_nvecserial TERM libraries:-lncurses UMFPACK libraries: -lumfpack -lamd -lsuitesparseconfig X11 libraries: -lX11 Z libraries: -lz Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
Am 26.01.2020 um 09:38 schrieb Marco Atzeri:
Am 26.01.2020 um 09:05 schrieb ASSI:
Marco Atzeri writes:
at least I know that is not just my machine.
When I released the package was
libinterp/corefcn/file-io.cc-tst
... PASS 90/90
Based on the test name there may be an assumption built into the code
about how the filesystem behaves that isn't guaranteed on Windows/Cygwin
or even POSIX. If it's simply an error condition not getting checked it
should be reproducible under debugging, but you're mostly out of luck if
it's relying on a specific order or atomicity of certain operations, as
debugging will almost always serialize the execution to the point where
these types of errors do not manifest.
Regards,
Achim.
the other problem of debugging is that the backtrace is trash
after the segfault and that of course Octave is a
400 Kg gorilla with all its dependencies..
I will try anyway
Thanks
Marco
one thing that I noticed is that the old binary I released and
the new one built are behaving differently.
So whatever is the problem that you and me are seeing and that
Takashi's system seems immune is causing a difference at
compilation time in the executable:
Old binary:
octave:2> run test-round6a.m
octave:3> run test-round6b.m
New binary:
octave:1> run test-round6a.m
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)
octave:1> run test-round6b.m
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)
Can you and Takashi provide me your cygcheck.out so that I can look on
possible difference that could influence the build behaviour.
Of course I have W10 Home and Takashi a W10 Pro an that is already
a difference.
Regards
Marco
f = tempname ();
fid = fopen (f, "w+");
fprintf (fid, "1\n2\n3\n4\n5\n6");
fseek (fid, 0, "bof");
c = textscan (fid, "%f %f", 2);
E = feof (fid);
fclose (fid);
unlink (f);
assert (c, {1, 2});
assert (! E);
f = tempname ();
fid = fopen (f, "w+");
fprintf (fid, "1\r\n2\r3\n4\r\n5\n6");
fseek (fid, 0, "bof");
c = textscan (fid, "%f %f", 4);
fclose (fid);
unlink (f);
assert (c, {[1;3], [2;4]});
--
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: headache on build repeatibility: octave vs BLODA ?
On Sun, 26 Jan 2020 11:24:50 +0100 Marco Atzeri wrote: > Am 26.01.2020 um 06:11 schrieb Takashi Yano: > > On Sun, 26 Jan 2020 11:42:28 +0900 > > Takashi Yano wrote: > >> In my environment, at least segmentation fault does not occur. > >> When I built octave, many of non-mandatory libraries were not > >> installed. This might affect. > > > > Now I added all libraries warned in config.log, and rebuilt. > > Some of tests seems to fail, however, segmentation fault does not > > occur in 'make check' this time too. > > > > interesting, what Windows system do you have ? > Mine is > > Betriebssystemname: Microsoft Windows 10 Home > Betriebssystemversion: 10.0.18363 Nicht zutreffend Build 18363 Windows 10 Pro 64bit 1909 Microsoft Windows [Version 10.0.18363.592] gcc version: 7.4.0 -- Takashi Yano -- 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: headache on build repeatibility: octave vs BLODA ?
Am 26.01.2020 um 06:11 schrieb Takashi Yano: On Sun, 26 Jan 2020 11:42:28 +0900 Takashi Yano wrote: In my environment, at least segmentation fault does not occur. When I built octave, many of non-mandatory libraries were not installed. This might affect. Now I added all libraries warned in config.log, and rebuilt. Some of tests seems to fail, however, segmentation fault does not occur in 'make check' this time too. interesting, what Windows system do you have ? Mine is Betriebssystemname: Microsoft Windows 10 Home Betriebssystemversion: 10.0.18363 Nicht zutreffend Build 18363 Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
Am 26.01.2020 um 09:05 schrieb ASSI: Marco Atzeri writes: at least I know that is not just my machine. When I released the package was libinterp/corefcn/file-io.cc-tst ... PASS 90/90 Based on the test name there may be an assumption built into the code about how the filesystem behaves that isn't guaranteed on Windows/Cygwin or even POSIX. If it's simply an error condition not getting checked it should be reproducible under debugging, but you're mostly out of luck if it's relying on a specific order or atomicity of certain operations, as debugging will almost always serialize the execution to the point where these types of errors do not manifest. Regards, Achim. the other problem of debugging is that the backtrace is trash after the segfault and that of course Octave is a 400 Kg gorilla with all its dependencies.. I will try anyway Thanks Marco -- 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: headache on build repeatibility: octave vs BLODA ?
Marco Atzeri writes: > at least I know that is not just my machine. > When I released the package was > > > libinterp/corefcn/file-io.cc-tst > ... PASS 90/90 Based on the test name there may be an assumption built into the code about how the filesystem behaves that isn't guaranteed on Windows/Cygwin or even POSIX. If it's simply an error condition not getting checked it should be reproducible under debugging, but you're mostly out of luck if it's relying on a specific order or atomicity of certain operations, as debugging will almost always serialize the execution to the point where these types of errors do not manifest. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: headache on build repeatibility: octave vs BLODA ?
Am 25.01.2020 um 21:36 schrieb Achim Gratz: Marco Atzeri writes: Than I passed to build the next version and started to see unexpected segfault during the package test. Trying to investigate I rebuilt the 5.1.0 and now I see also there the same thing: 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 make[3]: *** [Makefile:31176: check-local] Error 139 Same thing here… libinterp/corefcn/file-io.cc-tst ...fatal: caught signal Segmentation fault -- stopping myself... /bin/sh: line 1: 33811 Segmentation fault (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /mnt/share/packages/octave.x86_64/build/test/mex /mnt/share/packages/octave.x86_64/src/octave-5.1.0/test/fntests.m /mnt/share/packages/octave.x86_64/src/octave-5.1.0/test Regards, Achim. Thanks, at least I know that is not just my machine. When I released the package was libinterp/corefcn/file-io.cc-tst ... PASS 90/90 Regards Marco -- 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: headache on build repeatibility: octave vs BLODA ?
On Sun, 26 Jan 2020 11:42:28 +0900 Takashi Yano wrote: > In my environment, at least segmentation fault does not occur. > When I built octave, many of non-mandatory libraries were not > installed. This might affect. Now I added all libraries warned in config.log, and rebuilt. Some of tests seems to fail, however, segmentation fault does not occur in 'make check' this time too. -- Takashi Yano Integrated test scripts: liboctave/array/Array.cc-tst ... PASS 21/21 liboctave/array/CMatrix.cc-tst . PASS 11/11 liboctave/array/CSparse.cc-tst . PASS 10/10 liboctave/array/Sparse.cc-tst .. PASS 107/107 liboctave/array/dMatrix.cc-tst . PASS 10/10 liboctave/array/dSparse.cc-tst . PASS 12/12 liboctave/array/fCMatrix.cc-tst PASS 11/11 liboctave/array/fMatrix.cc-tst . PASS8/8 liboctave/array/idx-vector.cc-tst .. PASS2/2 liboctave/util/oct-inttypes.cc-tst . PASS 28/28 libinterp/corefcn/Cell.cc-tst .. PASS4/4 libinterp/corefcn/__contourc__.cc-tst .. PASS1/1 libinterp/corefcn/__dsearchn__.cc-tst .. PASS1/1 libinterp/corefcn/__ichol__.cc-tst . PASS1/1 libinterp/corefcn/__ilu__.cc-tst ... PASS1/1 libinterp/corefcn/__lin_interpn__.cc-tst ... PASS1/1 libinterp/corefcn/__magick_read__.cc-tst ... PASS4/4 libinterp/corefcn/__pchip_deriv__.cc-tst ... PASS1/1 libinterp/corefcn/__qp__.cc-tst PASS1/1 libinterp/corefcn/besselj.cc-tst ... PASS 191/191 libinterp/corefcn/bitfcns.cc-tst ... PASS 60/60 libinterp/corefcn/bsxfun.cc-tst PASS 77/77 libinterp/corefcn/call-stack.cc-tst PASS3/3 libinterp/corefcn/cellfun.cc-tst ... PASS 130/130 libinterp/corefcn/colloc.cc-tst PASS 12/12 libinterp/corefcn/conv2.cc-tst . PASS 48/51 (reported bug) XFAIL 3 libinterp/corefcn/dassl.cc-tst . PASS4/4 libinterp/corefcn/data.cc-tst .. PASS 1144/1150 (reported bug) XFAIL 6 libinterp/corefcn/debug.cc-tst . PASS1/1 libinterp/corefcn/defaults.cc-tst .. PASS6/6 libinterp/corefcn/det.cc-tst ... PASS6/6 libinterp/corefcn/dirfns.cc-tst PASS1/1 libinterp/corefcn/dlmread.cc-tst ... PASS8/10 REGRESSION 2 libinterp/corefcn/dot.cc-tst ... PASS 23/23 libinterp/corefcn/eig.cc-tst ... PASS 73/73 libinterp/corefcn/ellipj.cc-tst PASS 18/18 libinterp/corefcn/environment.cc-tst ... PASS6/6 libinterp/corefcn/error.cc-tst . PASS3/3 libinterp/corefcn/errwarn.cc-tst ... PASS1/1 libinterp/corefcn/fft.cc-tst ... PASS 19/19 libinterp/corefcn/fft2.cc-tst .. PASS4/4 libinterp/corefcn/file-io.cc-tst ... PASS 90/90 libinterp/corefcn/filter.cc-tst PASS 14/14 libinterp/corefcn/find.cc-tst .. PASS 22/22 libinterp/corefcn/gcd.cc-tst ... PASS9/9 libinterp/corefcn/getrusage.cc-tst . PASS1/1 libinterp/corefcn/givens.cc-tst PASS6/6 libinterp/corefcn/graphics.cc-tst .. PASS 49/49 (run-time condition) SKIP4 libinterp/corefcn/gsvd.cc-tst .. PASS 17/18 (reported bug) XFAIL 1 libinterp/corefcn/hash.cc-tst .. PASS 53/53 libinterp/corefcn/help.cc-tst .. PASS1/1 libinterp/corefcn/hess.cc-tst .. PASS5/5 libinterp/corefcn/hex2num.cc-tst
Re: headache on build repeatibility: octave vs BLODA ?
On Sat, 25 Jan 2020 17:55:31 +0100 Marco Atzeriwrote: >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 > make[3]: *** [Makefile:31176: check-local] Error 139 Does this occur when you execute make check in build directory? In my environment, at least segmentation fault does not occur. When I built octave, many of non-mandatory libraries were not installed. This might affect. Attached is the output of 'make check' in my environment. Windows version: Windows 10 1909 Microsoft Windows [Version 10.0.18363.592] Cygwin version: CYGWIN_NT-10.0 3.1.3(0.340/5/3) 2020-01-25 12:20 x86_64 Cygwin (The version which is applied a few patches not accepted yet. Should be very close to snapshot 2020-01-24.) -- Takashi Yano Integrated test scripts: liboctave/array/Array.cc-tst ... PASS 21/21 liboctave/array/CMatrix.cc-tst . PASS 11/11 liboctave/array/CSparse.cc-tst . PASS 10/10 liboctave/array/Sparse.cc-tst .. PASS 107/107 liboctave/array/dMatrix.cc-tst . PASS 10/10 liboctave/array/dSparse.cc-tst . PASS 12/12 liboctave/array/fCMatrix.cc-tst PASS 11/11 liboctave/array/fMatrix.cc-tst . PASS8/8 liboctave/array/idx-vector.cc-tst .. PASS2/2 liboctave/util/oct-inttypes.cc-tst . PASS 28/28 libinterp/corefcn/Cell.cc-tst .. PASS4/4 libinterp/corefcn/__contourc__.cc-tst .. PASS1/1 libinterp/corefcn/__dsearchn__.cc-tst .. PASS1/1 libinterp/corefcn/__ichol__.cc-tst . PASS1/1 libinterp/corefcn/__ilu__.cc-tst ... PASS1/1 libinterp/corefcn/__lin_interpn__.cc-tst ... PASS1/1 libinterp/corefcn/__magick_read__.cc-tst ... PASS4/4 libinterp/corefcn/__pchip_deriv__.cc-tst ... PASS1/1 libinterp/corefcn/__qp__.cc-tst PASS1/1 libinterp/corefcn/besselj.cc-tst ... PASS 191/191 libinterp/corefcn/bitfcns.cc-tst ... PASS 60/60 libinterp/corefcn/bsxfun.cc-tst PASS 77/77 libinterp/corefcn/call-stack.cc-tst PASS3/3 libinterp/corefcn/cellfun.cc-tst ... PASS 130/130 libinterp/corefcn/colloc.cc-tst PASS 12/12 libinterp/corefcn/conv2.cc-tst . PASS 48/51 (reported bug) XFAIL 3 libinterp/corefcn/dassl.cc-tst . PASS4/4 libinterp/corefcn/data.cc-tst .. PASS 1144/1150 (reported bug) XFAIL 6 libinterp/corefcn/debug.cc-tst . PASS1/1 libinterp/corefcn/defaults.cc-tst .. PASS6/6 libinterp/corefcn/det.cc-tst ... PASS6/6 libinterp/corefcn/dirfns.cc-tst PASS1/1 libinterp/corefcn/dlmread.cc-tst ... PASS8/10 REGRESSION 2 libinterp/corefcn/dot.cc-tst ... PASS 23/23 libinterp/corefcn/eig.cc-tst ... PASS 73/73 libinterp/corefcn/ellipj.cc-tst PASS 18/18 libinterp/corefcn/environment.cc-tst ... PASS6/6 libinterp/corefcn/error.cc-tst . PASS3/3 libinterp/corefcn/errwarn.cc-tst ... PASS1/1 libinterp/corefcn/fft.cc-tst ... PASS1/1 (missing feature) SKIP 18 libinterp/corefcn/fft2.cc-tst .. PASS0/0 (missing feature) SKIP4 libinterp/corefcn/file-io.cc-tst
Re: headache on build repeatibility: octave vs BLODA ?
Marco Atzeri writes: > Than I passed to build the next version and started to see > unexpected segfault during the package test. > Trying to investigate I rebuilt the 5.1.0 and now I see also > there the same thing: > > 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 > make[3]: *** [Makefile:31176: check-local] Error 139 Same thing here… libinterp/corefcn/file-io.cc-tst ...fatal: caught signal Segmentation fault -- stopping myself... /bin/sh: line 1: 33811 Segmentation fault (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /mnt/share/packages/octave.x86_64/build/test/mex /mnt/share/packages/octave.x86_64/src/octave-5.1.0/test/fntests.m /mnt/share/packages/octave.x86_64/src/octave-5.1.0/test Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: headache on build repeatibility: octave vs BLODA ?
On 2020-01-25 09:55, Marco Atzeri wrote: > Hi All, > I have recently released Octave 5.1.0 > > https://cygwin.com/ml/cygwin-announce/2020-01/msg00010.html > https://cygwin.com/ml/cygwin-announce/2020-01/msg00011.html > > that I built and packaged around 28 of December without > any compilation and test issue. > > Than I passed to build the next version and started to see > unexpected segfault during the package test. > Trying to investigate I rebuilt the 5.1.0 and now I see also > there the same thing: > > 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 > > make[3]: *** [Makefile:31176: check-local] Error 139 > > > I do not see any new cygwin package released in the last month that I > installed that could cause the simple file tests to fail > > %!test > %! f = tempname (); > %! fid = fopen (f, "w+"); > %! fprintf (fid, "1\n2\n3\n4\n5\n6"); > %! fseek (fid, 0, "bof"); > %! c = textscan (fid, "%f %f", 2); <- here comes the segfault > > I also tried the cygwin release 3.1.1 and 2020-01-14 snapshot > in addition to the 3.1.2 to see if something different was > coming with no difference in the outcome. > > Now I am seriously thinking about BLODA, but I have not > noted any difference from the two AVs I was using > Antivir and MS Defender, so I am wandering if last > update for W10 Home x64 is the culprit. Also what W10 feature release YYMM and/or build N are you on? > Can anyone try to rebuild the Octave package and let me know > if the segfault during test is present or not in your system ? > > Be aware that build time is very long (~ 4 hours) and requires > a ton of mathematical libraries. > > Any suggestion will be appreciated Should this discussion perhaps be handled on cygwin-apps? We don't always want to advertise just how messy the Cygwin package making sausage factory can be. ;^> I believe the following Cygwin tools and libraries packages, pulled from the package doc build dependencies, and found and filtered using apt-cyg listall, to be sufficient, but may not all be necessary, and should be added to octave.cygport, where it can be used as a build dependency install package list for apt-cyg or setup: DEPEND="autoconf automake bison flex gcc-core gcc-fortran gcc-g++ gperf gnuplot libtool make texinfo libopenblas liblapack-devel libpcre-devel libarpack-devel libparpack-devel libcurl-devel libfftw3-devel libfltk-devel libfontconfig-devel libfreetype-devel libglpk-devel libgl2ps-devel libGraphicsMagick-devel libhdf5-devel libllvm-devel libportaudio-devel libQtOpenGL4-devel libqhull-devel libqrupdate-devel libqscintilla2-devel libqscintilla2_qt4-devel libqscintilla2_qt5-devel libqt3-devel libsuitesparseconfig-devel libsundials-devel zlib-devel" Are there any changes you would make, especially for arpack, OpenGL, qt, scintilla? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
