Mail Archives: cygwin/2020/01/29/10:40:08
| X-Recipient: | archive-cygwin AT delorie DOT com
|
| DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
|
| :list-unsubscribe:list-subscribe:list-archive:list-post
|
| :list-help:sender:subject:references:to:from:message-id:date
|
| :mime-version:in-reply-to:content-type
|
| :content-transfer-encoding; q=dns; s=default; b=kTfO20FnXyUaLbwH
|
| 85ihbXyMRKQQb2OLp5LWgiFj43aATAtZScLAx2wCjKY+VxzWL8lj8Ajq2/Oi1IMV
|
| CjvhUeEj9HfXc7vbNnQgvoX0a9tYwXAEdKyVT3755x3XInt0Hy/wk9/zkyrD4pE4
|
| Ub21avKqCNWOw+zLuReE/Bb+u/M=
|
| DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
|
| :list-unsubscribe:list-subscribe:list-archive:list-post
|
| :list-help:sender:subject:references:to:from:message-id:date
|
| :mime-version:in-reply-to:content-type
|
| :content-transfer-encoding; s=default; bh=gfmTsH7bWxg6+IHoj1WUs0
|
| 1OQUM=; b=ozlT2Rn4B876xjjlxFh3pbq93A+ILn+c5mfFpVUSLyhzHh6uB2orQM
|
| M0U5DfCO3024lxPm0m+q4dvlvRtWVdEATOuRnWFgbliuS+ETedxw24bHW3w/AZzf
|
| uySJxYPaL1WOT0+Avouali081T8lFUKkB49CLLCQLpqctVQW+jxHc=
|
| Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
| List-Id: | <cygwin.cygwin.com>
|
| List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
| List-Archive: | <http://sourceware.org/ml/cygwin/>
|
| List-Post: | <mailto:cygwin AT cygwin DOT com>
|
| List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
| Sender: | cygwin-owner AT cygwin DOT com
|
| Mail-Followup-To: | cygwin AT cygwin DOT com
|
| Delivered-To: | mailing list cygwin AT cygwin DOT com
|
| Authentication-Results: | sourceware.org; auth=none
|
| X-Spam-SWARE-Status: | No, score=-0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL autolearn=no version=3.3.1 spammy=isp, internal-error, internalerror, whence
|
| X-HELO: | mailout09.t-online.de
|
| Subject: | Fwd: Re: headache on build repeatibility: octave vs BLODA ?
|
| References: | <5a944c6b-8499-754e-0825-e95f7859e7d2 AT t-online DOT de>
|
| To: | cygwin AT cygwin DOT com
|
| From: | =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= <HBBroeker AT t-online DOT de>
|
| X-Forwarded-Message-Id: | <5a944c6b-8499-754e-0825-e95f7859e7d2 AT t-online DOT de>
|
| Message-ID: | <7f071c05-22d2-1493-e37e-68c990b9854f@t-online.de>
|
| Date: | Wed, 29 Jan 2020 16:39:10 +0100
|
| User-Agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
|
| MIME-Version: | 1.0
|
| In-Reply-To: | <5a944c6b-8499-754e-0825-e95f7859e7d2@t-online.de>
|
| X-IsSubscribed: | yes
|
[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 0x0000000000000000 in ?? ()
#1 0x000000018019b9c7 in __sflush_r (ptr=ptr AT entry=0xffffd680,
fp=fp AT entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:179
#2 0x000000018019baeb in _fflush_r (ptr=ptr AT entry=0xffffd680,
fp=fp AT entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:278
#3 0x000000018019fd67 in _fseeko_r (ptr=0xffffd680, fp=0x800080ae8,
offset=4, whence=0) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fseeko.c:314
#4 0x00000001801346bb in _sigfe () at sigfe.s:35
#5 0x000000042cdc77d9 in c_file_ptr_buf::seekoff (this=0x800223dc0,
offset=<optimized out>, dir=<optimized out>) at
/usr/src/debug/octave-5.1.0-1/libinterp/corefcn/c-file-ptr-stream.cc:118
#6 0x00000003d7fd72b3 in cygstdc++-6!_ZNSi5tellgEv () from
/usr/bin/cygstdc++-6.dll
#7 0x000000042d0881da in octave::textscan::scan
(this=this AT entry=0xffffb470, isp=..., fmt=..., ntimes=ntimes AT entry=2,
options=..., count=@0xffffb6f8: 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)
58 if ((fp->_flags & __SL64) == 0)
(gdb)
42 {
(gdb)
58 if ((fp->_flags & __SL64) == 0)
(gdb)
70 if (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:
<http://www.gnu.org/software/gdb/bugs/>.
=============================
Hm, so stepping's no good. But the actual trigger is clear enough in
the segfault backtrace:
=============================
(gdb) frame 1
#1 0x000000018019b9c7 in __sflush_r (ptr=ptr AT entry=0xffffd680,
fp=fp AT entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:179
179 curoff = fp->_seek64 (ptr, fp->_cookie, curoff,
SEEK_SET);
(gdb) l
174 curoff -= fp->_ur;
175 }
176 /* Now physically seek to after byte last read. */
177 #ifdef __LARGE64_FILES
178 if (fp->_flags & __SL64)
179 curoff = fp->_seek64 (ptr, fp->_cookie, curoff,
SEEK_SET);
180 else
181 #endif
182 curoff = fp->_seek (ptr, fp->_cookie, curoff, SEEK_SET);
183 if (curoff != -1 || ptr->_errno == 0
(gdb) p *fp
$3 = {_p = 0x8004b1883 "3\n4\n5\n66", _r = 7, _w = 0, _flags = -17260,
_file = 3, _bf = {_base = 0x8004b1880 "\n2\n3\n4\n5\n66", _size =
65536}, _lbfsize = 0, _data = 0x0, _cookie = 0x800080ae8,
_read = 0x1801accd0 <__sread>, _write = 0x1801acd80 <__swrite>, _seek
= 0x1801ace40 <__sseek>, _close = 0x1801ace80 <__sclose>, _ub = {_base =
0x0, _size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000",
_nbuf = "", _lb = {_base = 0x0, _size = 0}, _blksize = 65536, _flags2
= 0, _offset = 11, _seek64 = 0x0, _lock = 0x800220e10, _mbstate =
{__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}}
=============================
Note that fp->_seek64 is actually null, so this is calling a null
pointer, possibly caused by gnulib interfering with the call sequence?
--
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
- Raw text -