gdb: failed to set signal flags properly for ast()

[Robert Watson]

While debugging the recent pthreads problem, I've started running into
this:

pid 663 (test), uid 1000: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
pid 709 (test), uid 0: exited on signal 10 (core dumped)
pid 713 (test), uid 0: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()

It appears to happen frequently when running the previously posted test
source code for -pthread under gdb.  When running the test program outside
of gdb, this doesn't happen, suggesting a possible interaction with
ptrace.  To trigger it the first time under gdb, I have to hit Ctrl-T,
then type continue a few times.  Under gdb, Ctrl-T appears to sometimes
cause a sigbus; the rest of the time, it causes this warning to start
being generated while the program continues.  Once the warning has started
to be generated, it gets generated about 12 times almost immediately, and
then intermittently from then onwards.

Source below.  Compiled using -g, -Wall, -pthread. (so not KSE)

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

#include pthread.h
#include stdio.h
#include unistd.h

void *
thread1(void *arg)
{

while (1) {
/* sleep(2); */
pthread_yield();
printf(1\n);
}
}

void *
thread2(void *arg)
{

sleep(1);
while (1) {
/* sleep(2); */
pthread_yield();
printf(2\n);
}
}

int
main(int argc, char *argv[]) {
pthread_t t1, t2;
int error;

error = pthread_create(t1, NULL, thread1, NULL);
error = pthread_create(t2, NULL, thread2, NULL);

error = pthread_join(t1, NULL);
error = pthread_join(t2, NULL);

return (0);
}



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gdb: failed to set signal flags properly for ast()

[phk]

In message [EMAIL PROTECTED], Robe
rt Watson writes:

While debugging the recent pthreads problem, I've started running into
this:

pid 663 (test), uid 1000: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()

I can't remember how I triggered this, but I have personally
run with this patch for some time:

(NB: CutPaste)

Index: kern/subr_trap.c
===
RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v
retrieving revision 1.239
diff -u -r1.239 subr_trap.c
--- kern/subr_trap.c28 Dec 2002 01:23:07 -  1.239
+++ kern/subr_trap.c28 Dec 2002 09:05:22 -
@@ -74,6 +74,7 @@
 {
struct proc *p = td-td_proc;
struct kse *ke = td-td_kse; 
+   static int enough;
 
CTR3(KTR_SYSC, userret: thread %p (pid %d, %s), td, p-p_pid,
 p-p_comm);
@@ -84,7 +85,8 @@
mtx_lock_spin(sched_lock);
if (SIGPENDING(p)  ((p-p_sflag  PS_NEEDSIGCHK) == 0 ||
(td-td_kse-ke_flags  KEF_ASTPENDING) == 0))
-   printf(failed to set signal flags properly for ast()\n);
+   if (++enough  10)
+   printf(failed to set signal flags properly for ast()\n);
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
mtx_unlock(Giant);
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message