On Sat, Aug 29, 2015 at 04:41:30PM +0300, Konstantin Belousov wrote:
> On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote:
> > Looks good to me, except that I think a vforked child (in system() and
> > posix_spawn*()) should use the system calls and not libthr's wrappers.
> > This redu
On Sat, Aug 29, 2015 at 04:02:43PM +0200, Michiel Boland wrote:
> I verified the patch. The getumask part of lib/libc/gen/setmode.c part was
> rejected on stable/10 (probably due to other changes in ^/head.)
Thank you. The setmode bits are from the Jilles' r280713. I will merge
this revision wh
On 08/29/2015 15:41, Konstantin Belousov wrote:
On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote:
Looks good to me, except that I think a vforked child (in system() and
posix_spawn*()) should use the system calls and not libthr's wrappers.
This reduces the probability of weird thi
On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote:
> Looks good to me, except that I think a vforked child (in system() and
> posix_spawn*()) should use the system calls and not libthr's wrappers.
> This reduces the probability of weird things happening between vfork and
> exec, and a
On Fri, Aug 28, 2015 at 07:18:47PM +0300, Konstantin Belousov wrote:
> On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
> > set -e
> > for a in `seq 1000`
> > do
> > echo -n "$a "
> > xterm -e ssh nonexisting
> > done
> > echo ""
> > (The idea here is that 'ssh nonexisting' should d
On Sat, Aug 29, 2015 at 01:43:36PM +0200, Michiel Boland wrote:
> Do I understand correctly that the problem is that if you install a signal
> handler with signal() (which is what xterm does) and pull in libthr.so
> somehow,
> then there is no thr_sighandler inserted?
Yes. The problem does not
On 08/28/2015 18:18, Konstantin Belousov wrote:
On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
set -e
for a in `seq 1000`
do
echo -n "$a "
xterm -e ssh nonexisting
done
echo ""
(The idea here is that 'ssh nonexisting' should do some work and then exit,
"xterm -e false", etc. do
On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
> set -e
> for a in `seq 1000`
> do
> echo -n "$a "
> xterm -e ssh nonexisting
> done
> echo ""
>
> (The idea here is that 'ssh nonexisting' should do some work and then exit,
> "xterm -e false", etc. don't appear to trigger the bug.
On 08/28/2015 12:01, Konstantin Belousov wrote:
[...]
I probably have an idea what is going wrong. Please try the patch
below. Libc does not used interposed sig{procmask,action,suspend}
entries itself, which resulted in e.g. signal(3) breaking libthr
hooks.
I'm trying now, and it did appear t
On Fri, Aug 28, 2015 at 08:08:27AM +0200, Michiel Boland wrote:
> On 08/27/2015 22:16, Konstantin Belousov wrote:
> [...]
> > I just verified that the signal handler is correctly wrapped for me, on
> > the latest stable/10. Both with the pre-linked libthr.so and with the
> > library loaded dynamic
On 08/27/2015 22:16, Konstantin Belousov wrote:
[...]
I just verified that the signal handler is correctly wrapped for me, on
the latest stable/10. Both with the pre-linked libthr.so and with the
library loaded dynamically at runtime. I used the test program at the
end of the message, put break
On Thu, Aug 27, 2015 at 08:53:09PM +0200, Michiel Boland wrote:
> The xterm program has a SIGCHLD signal handler that calls wait().
> If the handler is invoked while xterm is exiting, a deadlock occurs in rtld.
>
> Cheers
> Michiel
>
> #0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_
The xterm program has a SIGCHLD signal handler that calls wait().
If the handler is invoked while xterm is exiting, a deadlock occurs in rtld.
Cheers
Michiel
#0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
#1 0x00080305a2b0 in __thr_rwlock_rdlock (rwlock=0x8032
On Thu, Aug 27, 2015 at 06:06:26PM +0100, Pete French wrote:
> > Try to obtain the backtrace from the hung xterm. Ideally, you would
> > rebuild xterm and the system libraries (rtld+libc+libthr) with debug
> > symbols and get the backtraces after that.
>
> I can try this tomorrow - what do I need
> Try to obtain the backtrace from the hung xterm. Ideally, you would
> rebuild xterm and the system libraries (rtld+libc+libthr) with debug
> symbols and get the backtraces after that.
I can try this tomorrow - what do I need to set in src.conf to add
debug symbols in when I do a buidlworld (that
On Thu, Aug 27, 2015 at 02:04:05PM +0200, Mark Martinec wrote:
> Pete French wrote:
>
> > I updated to stable yesterday, plus updated all my porst to
> > the latest pecompiled packages, but I am now seeing odd problems
> > with bash on exit. Sometimes it quits, but leaves a zombie
> > process... e
> I can reproduce this easily, although not every time.
Ah, thats good to hear, as it means I am not going completely mad,
thanks! :)
> Running 10.2 under KDE, with bash as a default shell:
> start xterm from a KDE 'konsole', then move to within the xterm
> and try closing it (^D or exit). More o
Pete French wrote:
I updated to stable yesterday, plus updated all my porst to
the latest pecompiled packages, but I am now seeing odd problems
with bash on exit. Sometimes it quits, but leaves a zombie
process... e.g
PID TT STATTIME COMMAND
44308 v0 IW 0:00.00 -bash (bash)
44312 v0 I
> Hi Pete!
>
> I cannot reproduce the error, but I'm using fvwm. Can you give a step-bystep
> instruction to reproduce the error?
>
> nik
Hello Nik, thanks for looking at this for me - I havent yet found a reliable way
to reproduce it unfortunately. It seems to happen on wiindows where I have
run
Am Mittwoch, 26. August 2015 schrieb Pete French:
> As noted yestterday, this issue only happens in an xterm
> as far as I can make out. When back becomes a zombie
> then the xtrem enters state urdlck according to ps. I
> tried removing and reinstalling all ports today, in the hopes that
> might fi
As noted yestterday, this issue only happens in an xterm
as far as I can make out. When back becomes a zombie
then the xtrem enters state urdlck according to ps. I
tried removing and reinstalling all ports today, in the hopes that
might fix it, but the problem is still there.
Is anyone else seeing
I updated to stable yesterday, plus updated all my porst to
the latest pecompiled packages, but I am now seeing odd problems
with bash on exit. Sometimes it quits, but leaves a zombie
process... e.g
PID TT STATTIME COMMAND
44308 v0 IW 0:00.00 -bash (bash)
44312 v0 IW+ 0:00.00 /bin/sh /
22 matches
Mail list logo
