Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1011 closed bug (fixed)

wait_for_thread doesn't seem to work.

Reported by: mmu_man Owned by: axeld
Priority: high Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

wait_for_thread() doesn't seem to always find death records of dead threads, and gives bad results anyway:

~>thtest err = 00000000 st = 00200aa0 err = 00000000 st = 00200aac ~>thtest err = 80001100 st = 001071ac err = 00000000 st = 00200aac ~>error 0x80001100 0x80001100: Bad thread ID

In Zeta:

$ ./thtest err = 00000000 st = 00000000 err = 00000000 st = 00000000 $ ./thtest err = 00000000 st = 00000000 err = 00000000 st = 00000000

Attachments (1)

thtest.c (477 bytes ) - added by mmu_man 13 years ago.
wait_for_thread test

Download all attachments as: .zip

Change History (8)

by mmu_man, 13 years ago

Attachment: thtest.c added

wait_for_thread test

comment:1 by axeld, 13 years ago

Status: newassigned

The result of the first wait_for_thread() is random even under BeOS - to make it safe you have to remove the resume_thread(). To let it always fail, just add a short delay before wait_for_thread().

I'll look into the wrong return code, though; I guess I recently broke that when fixing arch_thread_enter_userspace(). It does work correctly in the case of the fibo_* tests, BTW.

comment:2 by mmu_man, 13 years ago

The first one doesn't seem very random to me (yes I tried other values), but maybe it got fixed in Dano.

comment:3 by axeld, 13 years ago

Resolution: fixed
Status: assignedclosed

It's not a bug in BeOS nor Dano - it's a bug in *your* code. As I said, to make it clearer, just add a delay after resume_thread() but before wait_for_thread(). Dano's wait_for_thread() will then fail as well (as it should).

Anyway, the actual bug in Haiku is fixed in hrev20060, thanks for noticing! :)

comment:4 by mmu_man, 13 years ago

Actually I tried sleep5&) after resume_thread and it didn't fail.

I didn't dig the Haiku code, but BeOS keeps the death reason and return code around until the team dies in a list of struct death_rec (and the parent team inherits the last one... or rather the one from the first thread IIRC. which I think is why sometimes the tty gets mad, because the shell doesn't get the ret code it expected). Now I remember I wanted to extend death_rec to keep the kernel and user times to be able to implement the missing wait3 or wait4, whichever.

comment:5 by mmu_man, 13 years ago

sleep(1) I meant

comment:6 by axeld, 13 years ago

I tested with sleep(1) on Dano, and the same thing happens as on Haiku and on R5. If it doesn't happen with Zeta, then it got changed after Dano got "published". Nevertheless, it's not a bug, just a different behaviour. The shell doesn't have anything to do with this, as teams collect the death entries of their children (but not single threads, only teams).

comment:7 by mmu_man, 13 years ago

I know I did some changes in the thread code in Zeta, but I'm sure I didn't change that. Now currently wait_for_thread searches in the death_recs for the calling thread's team.

And yes it does have to do with teams as well, at least in BeOS since it's handled with the same death_rec list, a diing team leaving its own death_rec (that of it's first thread actually) in testimony to its parent team. The fact that the team's return value is arbitrarily that of its first thread makes me think it has to do with the tty getting messed up, as I suspect the shell might actually want another thread's rec but doesn't get it.

Note: See TracTickets for help on using tickets.