[Test] short_thread.c: assertion failure: 0 == rv, at ptsynch.c:316

RESOLVED FIXED

Status

defect
P3
normal
RESOLVED FIXED
20 years ago
20 years ago

People

(Reporter: wtc, Assigned: wtc)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

20 years ago
On AIX 4.3.2 (32-bit and 64-bit) and 4.3.3 (32-bit),
the short_thread.c test may hit an assertion failure:
Assertion failure: 0 == rv, at ptsynch.c:316

The stack trace is:
(dbx) where
pthread_kill(??, ??) at 0xd0014b74
_p_raise(??) at 0xd001410c
raise.raise(??) at 0xd016fc4c
abort.abort() at 0xd0169390
PR_Assert(0xd0aab6e4, 0xd0aab6d8, 0x13c), line 467 in "prlog.c"
unnamed block $b92, line 316 in "ptsynch.c"
PR_DestroyCondVar(0x20017778), line 316 in "ptsynch.c"
PR_Cleanup(), line 886 in "ptthread.c"
main(argc = 1, argv = 0x2ff22afc), line 63 in "short_thread.c"
(dbx) up 5
unnamed block $b92, line 316 in "ptsynch.c"
(dbx) print rv
16

The error code 16 is EBUSY.  The failed assertion is
in PR_DestroyCondVar:
312  PR_IMPLEMENT(void) PR_DestroyCondVar(PRCondVar *cvar)
313  {
314      if (0 > PR_AtomicDecrement(&cvar->notify_pending))
315      {
316          PRIntn rv = pthread_cond_destroy(&cvar->cv); PR_ASSERT(0 == rv);
317  #if defined(DEBUG)
318          memset(cvar, 0xaf, sizeof(PRCondVar));
319          pt_debug.cvars_destroyed += 1;
320  #endif
321          PR_DELETE(cvar);
322      }
323  }  /* PR_DestroyCondVar */

Comment 1

20 years ago
PR_DestroyCondVar should return the EBUSY error, instead of asserting that
pthread_cond_destroy succeed, to the application; unfortunately, the return type
is void.
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Assignee

Comment 2

20 years ago
I agree that many of the NSPR functions that return void
should return PRStatus because they may fail.

This particular failure, however, is a bug in my code.
PR_Cleanup() may destroy the condition variable pt_book.cv
when there is still an unjoinable thread waiting on that
condition variable, hence the EBUSY error.  I have a fix
for this.
Assignee

Comment 4

20 years ago
The problem was caused by the fact that _pt_root
(NSPR threads' root function) waits on the pt_book.cv
after it decrements the active user thread count
(pt_book.user).  Therefore, when PR_Cleanup sees that
there is no more user thread and proceeds to destroy
pt_book.cv, that terminating thread may still be waiting
on pt_book.cv, hence the EBUSY error.

The fix is for _pt_root to wait on pt_book.cv before
decrementing active thread count.
Assignee

Comment 5

20 years ago
I checked in the fix on NSPRPUB_RELEASE_4_0_BRANCH.
/cvsroot/mozilla/nsprpub/pr/src/pthreads/ptthread.c, revision 3.32.4.2
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.