Re: Not running into expected SIGSEGV

[Samuel Thibault]

Justus Winter, on Tue 23 Feb 2016 23:43:58 +0100, wrote:
> Quoting Samuel Thibault (2016-02-23 23:27:26)
> > Justus Winter, on Tue 23 Feb 2016 23:24:08 +0100, wrote:
> > > Quoting Samuel Thibault (2016-02-23 23:04:25)
> > > > Samuel Thibault, on Tue 23 Feb 2016 22:22:02 +0100, wrote:
> > > > > Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > > > > > > I couldn't figure out any pattern from looking at the diffs 
> > > > > > > between the
> > > > > > > respective Hurd packages' sources.
> > > > > 
> > > > > I've digged a bit, the difference that matters between -2 and -3
> > > > > is about the protected payload optimization. -2 used to disable it
> > > > > because we had issues with pflocal. -3 fixed the pflocal issue and 
> > > > > thus
> > > > > re-enabled the optimization.
> > > > > 
> > > > > So apparently there is at least another issue with it.
> > > > 
> > > > I have thus disabled it again at least in the Debian package, for now.
> > > 
> > > You should also be able to disable it in the kernel, just ignore
> > > mach_port_set_protected_payload requests by making them return early.
> > 
> > No, that's not the culprit, see the patch detail: this is the case where
> > the kernel didn't record a protected payload, libports then makes the
> > hash lookup, and stores the result so the translator demuxer doesn't do
> > this again.
> 
> Ah, I hadn't seen that patch.  I fixed that issue in master.

Ok, I'll upload that instead.

> > Apparently the translator demuxer does not expect that and does
> > crazy things.
> 
> Is there a problem with a specific translator?

I hadn't checked which, but most probably the issue was the lost "other"
bits.

Samuel

Re: Not running into expected SIGSEGV

[Justus Winter]

Quoting Samuel Thibault (2016-02-23 23:27:26)
> Justus Winter, on Tue 23 Feb 2016 23:24:08 +0100, wrote:
> > Quoting Samuel Thibault (2016-02-23 23:04:25)
> > > Samuel Thibault, on Tue 23 Feb 2016 22:22:02 +0100, wrote:
> > > > Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > > > > > I couldn't figure out any pattern from looking at the diffs between 
> > > > > > the
> > > > > > respective Hurd packages' sources.
> > > > 
> > > > I've digged a bit, the difference that matters between -2 and -3
> > > > is about the protected payload optimization. -2 used to disable it
> > > > because we had issues with pflocal. -3 fixed the pflocal issue and thus
> > > > re-enabled the optimization.
> > > > 
> > > > So apparently there is at least another issue with it.
> > > 
> > > I have thus disabled it again at least in the Debian package, for now.
> > 
> > You should also be able to disable it in the kernel, just ignore
> > mach_port_set_protected_payload requests by making them return early.
> 
> No, that's not the culprit, see the patch detail: this is the case where
> the kernel didn't record a protected payload, libports then makes the
> hash lookup, and stores the result so the translator demuxer doesn't do
> this again.

Ah, I hadn't seen that patch.  I fixed that issue in master.

> Apparently the translator demuxer does not expect that and does
> crazy things.

Is there a problem with a specific translator?

Justus

Re: Not running into expected SIGSEGV

[Samuel Thibault]

Justus Winter, on Tue 23 Feb 2016 23:24:08 +0100, wrote:
> You cannot specify an in-translation without also specifying the
> payload version.  Though I must admit I don't know how or if that is
> enforced.

At least

libtreefs/fs-mutate.h:#define FILE_INTRAN treefs_handle_t 
treefs_begin_using_handle_port (file_t)
libtreefs/fs-mutate.h:#define IO_INTRAN treefs_handle_t 
treefs_begin_using_handle_port (io_t)

don't seem to have one (though libtreefs is not used so perhaps that's
never used).

Samuel

Re: Not running into expected SIGSEGV

[Samuel Thibault]

Justus Winter, on Tue 23 Feb 2016 23:24:08 +0100, wrote:
> Quoting Samuel Thibault (2016-02-23 23:04:25)
> > Samuel Thibault, on Tue 23 Feb 2016 22:22:02 +0100, wrote:
> > > Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > > > > I couldn't figure out any pattern from looking at the diffs between 
> > > > > the
> > > > > respective Hurd packages' sources.
> > > 
> > > I've digged a bit, the difference that matters between -2 and -3
> > > is about the protected payload optimization. -2 used to disable it
> > > because we had issues with pflocal. -3 fixed the pflocal issue and thus
> > > re-enabled the optimization.
> > > 
> > > So apparently there is at least another issue with it.
> > 
> > I have thus disabled it again at least in the Debian package, for now.
> 
> You should also be able to disable it in the kernel, just ignore
> mach_port_set_protected_payload requests by making them return early.

No, that's not the culprit, see the patch detail: this is the case where
the kernel didn't record a protected payload, libports then makes the
hash lookup, and stores the result so the translator demuxer doesn't do
this again. Apparently the translator demuxer does not expect that and
does crazy things.

Samuel

Re: Not running into expected SIGSEGV

[Justus Winter]

Quoting Samuel Thibault (2016-02-23 23:04:25)
> Samuel Thibault, on Tue 23 Feb 2016 22:22:02 +0100, wrote:
> > Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > > > I couldn't figure out any pattern from looking at the diffs between the
> > > > respective Hurd packages' sources.
> > 
> > I've digged a bit, the difference that matters between -2 and -3
> > is about the protected payload optimization. -2 used to disable it
> > because we had issues with pflocal. -3 fixed the pflocal issue and thus
> > re-enabled the optimization.
> > 
> > So apparently there is at least another issue with it.
> 
> I have thus disabled it again at least in the Debian package, for now.

You should also be able to disable it in the kernel, just ignore
mach_port_set_protected_payload requests by making them return early.

> I'm wondering: what is supposed to happen if some translator didn't set
> an INTRAN_PAYLOAD?

You cannot specify an in-translation without also specifying the
payload version.  Though I must admit I don't know how or if that is
enforced.

The worst thing that can happen (and that happened in the pflocal case
iirc) is that some server function expected a receiver of type
mach_port_t and got a payload instead, and the compiler didn't notice
because the file implementing the server function didn't include the
generated header file.  It then went on to lookup the payload in the
hash table mapping port names to objects, which failed.

Justus

Re: Not running into expected SIGSEGV

[Samuel Thibault]

Samuel Thibault, on Tue 23 Feb 2016 22:22:02 +0100, wrote:
> Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > > I couldn't figure out any pattern from looking at the diffs between the
> > > respective Hurd packages' sources.
> 
> I've digged a bit, the difference that matters between -2 and -3
> is about the protected payload optimization. -2 used to disable it
> because we had issues with pflocal. -3 fixed the pflocal issue and thus
> re-enabled the optimization.
> 
> So apparently there is at least another issue with it.

I have thus disabled it again at least in the Debian package, for now.

I'm wondering: what is supposed to happen if some translator didn't set
an INTRAN_PAYLOAD?

Samuel

Re: Not running into expected SIGSEGV

[Samuel Thibault]

Thomas Schwinge, on Tue 23 Feb 2016 12:02:36 +0100, wrote:
> > I couldn't figure out any pattern from looking at the diffs between the
> > respective Hurd packages' sources.

I've digged a bit, the difference that matters between -2 and -3
is about the protected payload optimization. -2 used to disable it
because we had issues with pflocal. -3 fixed the pflocal issue and thus
re-enabled the optimization.

So apparently there is at least another issue with it.

Samuel

Re: Not running into expected SIGSEGV

[Justus Winter]

Hi :)

Quoting Thomas Schwinge (2016-02-23 11:37:58)
>   68<--72(pid-1)-> 2400 (rpctrace: ../../utils/rpctrace.c:863: 
> print_contents: Assertion `inp->msgh_bits & 0x8000U' failed.
> Aborted
> 
> (Yay, another rpctrace issue.)  ;-)

Actually, that is not an rpctrace issue.  rpctrace is rightfully
complaining about the fact that a message carrying rights is not
marked as complex.  I believe the kernel strips that away, and it is
my fault :(

Fwiw, 2400 is the mach kernel sending an exception.

Justus

Re: Not running into expected SIGSEGV

[Thomas Schwinge]

Hi!

Samuel's MTA (labri.fr) told me that it's "not permissible" to attach
*.exe* files to emails.  I you didn't receive that file, you can also
copy it from darnassus:~tschwinge/stack_check1.exe, or ask me to send it
"scrambled".

On Tue, 23 Feb 2016 11:37:58 +0100, I wrote:
> The attached program, stack_check1.exe, is supposed to terminated with a
> SIGSEGV (endless recursion, if I remember correctly the Ada source code
> From the GCC testsuite).  (Samuel, that's the issue that I vaguely/in a
> hurry described to you at FOSDEM, which impacts my GCC testing.)
> 
> I do get the SIGSEGV with old 1:0.6.git20150704-2 Hurd packages
> installed, in a system that is otherwise up to date.  Booting with more
> recent Hurd packages from 
> installed, the stack_check1.exe process then just hangs.  (Need to kill
> -KILL it, C-c will make the session/PTY hang or something.)  If I
> remember correctly (it's been some months...), there also was erratic
> behavior to be observed when I bisected earlier Hurd package versions:
> some worked (SIGSEGV) some didn't (hang).
> 
> I couldn't figure out any pattern from looking at the diffs between the
> respective Hurd packages' sources.  What I did not consider is which
> glibc versions the Hurd packages have been built against (statically
> linked, in part) -- which might be relevant, too.
> 
> With recent 1:0.7.git20160214-2 Hurd packages installed:
> 
> $ ./stack_check1.exe
> [hangs]
> 
> $ rpctrace ./stack_check1.exe
> [...]
> task51(pid1023)->vm_map (0 2097152 0 1  (null) 0 1 0 7 1) = 0 196608
> task51(pid1023)->vm_deallocate (196608 851968) = 0 
> task51(pid1023)->vm_deallocate (2097152 196608) = 0 
> task51(pid1023)->vm_protect (1048576 135168 0 3) = 0 
> task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
> task51(pid1023)->mach_port_deallocate (pn{ 24}) = 0 
>   68<--72(pid-1)-> 2400 (rpctrace: ../../utils/rpctrace.c:863: 
> print_contents: Assertion `inp->msgh_bits & 0x8000U' failed.
> Aborted
> 
> (Yay, another rpctrace issue.)  ;-)
> 
> $ gdb -q ./stack_check1.exe
> Reading symbols from ./stack_check1.exe...done.
> (gdb) r
> Starting program: /media/erich/home/thomas/stack_check1.exe 
> [New Thread 1026.5]
> [New Thread 1026.6]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> 2   
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:
>  No such file or directory.
> (gdb) info threads
>   Id   Target Id Frame 
>   6Thread 1026.6 0x080614ec in stack_check1.consume_stack ()
>   5Thread 1026.5 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> * 4Thread 1026.4 0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
>   3bogus thread id 3 Can't fetch registers from thread bogus thread 
> id 3: No such thread
> 
> (Yay, another GDB issue.)  ;-)
> 
> (gdb) thread apply all bt
> 
> Thread 6 (Thread 1026.6):
> #0  0x080614ec in stack_check1.consume_stack ()
> #1  0x08061540 in stack_check1.consume_stack ()
> #2  0x08061540 in stack_check1.consume_stack ()
> #3  0x08061540 in stack_check1.consume_stack ()
> #4  0x08061540 in stack_check1.consume_stack ()
> #5  0x08061540 in stack_check1.consume_stack ()
> #6  0x08061540 in stack_check1.consume_stack ()
> #7  0x08061540 in stack_check1.consume_stack ()
> [...]
> #251 0x08061540 in stack_check1.consume_stack ()
> #252 0x08061540 in stack_check1.consume_stack ()
> #253 0x08061540 in stack_check1.consume_stack ()
> #254 0x08061639 in stack_check1.t ()
> #255 0x08060f72 in system.tasking.stages.task_wrapper (self_id=0x8082eb0) 
> at s-tassta.adb:1262
> #256 0x01042b1f in entry_point (self=0x8085fb0, start_routine=0x8060e20 
> , arg=0x8082eb0)
> at ./pthread/pt-create.c:64
> #257 0x in ?? ()
> 
> Thread 5 (Thread 1026.5):
> #0  0x0107d92c in mach_msg_trap () at 
> /build/glibc-GlHAly/glibc-2.21/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> #1  0x0107e0c6 in __mach_msg (msg=0x2802f20, option=3, send_size=32, 
> rcv_size=4096, rcv_name=56, timeout=0, notify=0) at msg.c:110
> #2  0x0107e704 in __mach_msg_server_timeout (demux=0x108e4c0 
> , max_size=4096, rcv_name=56, option=0, timeout=0) at 
> msgserver.c:150
> #3  0x0107e7c4 in __mach_msg_server (demux=0x108e4c0 , 
> max_size=4096, rcv_name=56) at msgserver.c:195
> #4  0x0108e5ae in _hurd_msgport_receive () at msgportdemux.c:67
> #5  0x01042b1f in entry_point (self=0x80819b0, start_routine=0x108e550 
> <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:64
> #6  0x00