Re: ext2fs crash

[Justus Winter]

Hi,

Quoting Thomas Schwinge (2016-05-13 23:02:08)
> Hi!
> 
> On Mon, 09 May 2016 16:11:52 +0200, Justus Winter 
> <4win...@informatik.uni-hamburg.de> wrote:
> > Quoting Thomas Schwinge (2016-04-27 22:53:33)
> > > [...]
> > > I suppose we want to fix (or, at least understand) that problem before
> > > making the releases?
> > 
> > No.  Let's take what we have and release it.  Even though some people
> > are having trouble with ext2fs, for most people it is working really
> > well (e.g. the build daemons).
> 
> So, the ext2fs issues (bogus port deallocations, crash) are something to
> look into (later, I agree), [...]

I believe I can shed some light on the former problem:

$ settrans -ac hi /hurd/hello ; cat hi ; pkill hello ; rm hi
Hello, world!
(kernel complaining about ext2fs doing bogus port operations)

The problem is that libfshelp doesn't handle translators dying right.
I added code for the recursive mtab translator to do that, assuming
that the existing code copes with translators going away, but it does
not.  This merely needs to be implemented.

Justus

Re: ext2fs crash

[Thomas Schwinge]

Hi!

On Mon, 09 May 2016 16:11:52 +0200, Justus Winter 
<4win...@informatik.uni-hamburg.de> wrote:
> Quoting Thomas Schwinge (2016-04-27 22:53:33)
> > [...]
> > I suppose we want to fix (or, at least understand) that problem before
> > making the releases?
> 
> No.  Let's take what we have and release it.  Even though some people
> are having trouble with ext2fs, for most people it is working really
> well (e.g. the build daemons).

So, the ext2fs issues (bogus port deallocations, crash) are something to
look into (later, I agree), and the GCC/libstdc++ testsuite issue in fact
is not related to "our" packages (Hurd et al.):

Current status:

$ make check-target-libstdc++-v3 
RUNTESTFLAGS=conformance.exp=27_io/basic_filebuf/showmanyc/char/9533-1.cc

i686-unknown-gnu0.7/libstdc++-v3/testsuite/libstdc++.log:

[...]
PASS: 27_io/basic_filebuf/showmanyc/char/9533-1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to [...]
Execution timeout is: 300
spawn [open ...]
WARNING: program timed out.
[Hangs here.]
[C-c]
got a INT signal, interrupted by user 

=== libstdc++ Summary ===

# of expected passes1
runtest completed at [...]

Downgrading dejagnu from 1.6-1 back to the previous 1.5.3-2 resolves the
problem:

[...]
PASS: 27_io/basic_filebuf/showmanyc/char/9533-1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to [...]
spawn [open ...]
WARNING: program timed out.
FAIL: 27_io/basic_filebuf/showmanyc/char/9533-1.cc execution test
testcase [...]/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
completed in 632 seconds

=== libstdc++ Summary ===

# of expected passes1
# of unexpected failures1
runtest completed at [...]

(The timeout and FAIL are currently to be expected.)  Phew.  So, I'll
(later) try to figure out what's going on there...


> Do you need help with the announcements?

Thanks for having prepared the NEWS files updates already.  I'm working
on the releases; these won't go out today, but tomorrow, I suppose.
"Timeout, server git.savannah.gnu.org not responding."  ;-)


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: ext2fs crash

[Justus Winter]

Hi :)

Quoting Thomas Schwinge (2016-04-27 22:53:33)
> Before preparing the next set of releases, I wanted to sort-of
> sanity-check what we currently got (at least in terms of Debian
> packages), so yesterday dist-upgraded my Debian GNU/Hurd system to the
> latest packages, and started a GCC bootstrap build and testsuite run.
> That one didn't complete successfully...
> 
> I can confirm that the
> 
> issue appears to be fixed -- yay, thanks!

:)

> [...]
> I suppose we want to fix (or, at least understand) that problem before
> making the releases?

No.  Let's take what we have and release it.  Even though some people
are having trouble with ext2fs, for most people it is working really
well (e.g. the build daemons).

Do you need help with the announcements?

Justus

ext2fs crash

[Thomas Schwinge]

Hi!

Before preparing the next set of releases, I wanted to sort-of
sanity-check what we currently got (at least in terms of Debian
packages), so yesterday dist-upgraded my Debian GNU/Hurd system to the
latest packages, and started a GCC bootstrap build and testsuite run.
That one didn't complete successfully...

I can confirm that the

issue appears to be fixed -- yay, thanks!

The GCC testsuite got stuck on libstdc++'s
27_io/basic_filebuf/showmanyc/char/9533-1.cc.  That one compiles fine but
already before has been known to FAIL its execution testing with
"WARNING: program timed out" (probably the sort-of known frame unwinding
"deficiencies"?), but now, the whole testing harness seems to have gotten
stuck.  Manually SIGKILLing the 9533-1 process, testing continued, but
then got stuck on libstdc++'s 30_threads/async/forced_unwind.cc, which
also before has been known to FAIL its execution testing with "WARNING:
program timed out", but without making the testing harness get stuck.
Poking on forced_unwind.exe for a bit with GDB, I found the "standard"
two-threads process stuck in some pthread_cond_wait (lost the backtrace).
Eventually, ext2fs seems to have crashed ("resource lost" messages).
After rebooting, and compiling the 9533-1.cc test case with the system
compiler:

$ g++-5 -Ilibstdc++-v3/testsuite/util 
libstdc++-v3/testsuite/27_io/basic_filebuf/showmanyc/char/9533-1.cc -g

... I got the following backtrace, which unfortunately is not helpful at
all:

$ gdb -q ./a.out
Reading symbols from ./a.out...done.
(gdb) r
Starting program: [...]/a.out
[hangs]
^C[New Thread 1138.5]

Program received signal SIGINT, Interrupt.
0x01253a55 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
132 intr-msg.c: No such file or directory.
(gdb) info threads
  Id   Target Id Frame
  5Thread 1138.5 0x012374fc in mach_msg_trap () at 
/build/glibc-2.22/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
* 4Thread 1138.4 0x01253a55 in _hurd_intr_rpc_msg_in_trap () at 
intr-msg.c:132
  3bogus thread id 3 Can't fetch registers from thread bogus thread id 
3: No such thread
(gdb) thread apply all bt

Thread 5 (Thread 1138.5):
#0  0x012374fc in mach_msg_trap () at 
/build/glibc-2.22/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1  0x01237c96 in __mach_msg (msg=0x145cf60, option=2, send_size=0, 
rcv_size=4096, rcv_name=11, timeout=0, notify=0) at msg.c:110
#2  0x0123825b in __mach_msg_server_timeout (demux=0x1248330 
, max_size=4096, rcv_name=11, option=0, timeout=0) at 
msgserver.c:100
#3  0x01238384 in __mach_msg_server (demux=0x1248330 , 
max_size=4096, rcv_name=11) at msgserver.c:195
#4  0x0124841e in _hurd_msgport_receive () at msgportdemux.c:67
#5  0x66688b92 in ?? ()

Thread 4 (Thread 1138.4):
#0  0x01253a55 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
#1  0x0036 in ?? ()

I then ran that once more, in hope for a better backtrace, and in
parallel copied the existing GCC test log files off of the Hurd system;
shortly after that (?), ext2fs crashed with the following on the console
(manually transcribed):

/hurd/crash: /hurd/ext2fs /dev/hd2(423) crashed, signal {no:11, code:2, 
error:2}, exception {1, code:2, subcode:92671996}, PCs: {0x112a4fc, 0x112a4fc, 
0x112a4fc, 0x112a4fc, 0x112a4fc, 0x112a4fc, 0x112a4fc, 0x132868c, 0x112a4fc}, 
killing task.

I suppose we want to fix (or, at least understand) that problem before
making the releases?

I don't know if that's the actual problem, but building the attached
sources with:

$ g++-5 -I. 9533-1.cc -g

..., and the running that executablerepeatedly, I see stuff like:

$ while :; do echo -n .; ./a.out & p=$!; kill $p; done
[...]
.[1885] 5605
[1884]   Terminated  ./a.out
.[1886] 5609
[1885]   Terminated  ./a.out
*** Error in `./a.out': double free or corruption (!prev): 0x0804e4a8 ***
.[1887] 5613
[1886]   Terminated  ./a.out
.[1888] 5617
[1887]   Terminated  ./a.out

..., and on the console messages about "task /hurd/ext2fs(2090)
deallocating a bogus port [...]", repeating every once in a while.

Have to stop here, unfortunately.


Grüße
 Thomas


// { dg-require-fork "" }
// { dg-require-mkfifo "" }

// Copyright (C) 2003-2016 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.

// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.