Project

General

Profile

Actions

Bug #1072

closed

Firefox/libthread_xu issue with pthread_attr_setschedparam

Added by jgordeev over 16 years ago. Updated about 16 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I have a Firefox problem caused by DragonFly and/or libthread_xu.
sched_get_priority_min(SCHED_OTHER) and
sched_get_priority_max(SCHED_OTHER) return values PRIO_MIN (-20) and
PRIO_MAX(20), both defined in sys/sys/resource.h.
When pthread_attr_setschedparam is called to set scheduling priority for
scheduling policy SCHED_OTHER, the priority value is checked if it is
within range by comparing it to THR_MIN_PRIORITY(0) and
THR_MAX_PRIORITY(31), both defined in
lib/libthread_xu/thread/thr_private.h. When a value in the range [-20;
-1] is used, pthread_attr_setschedparam returns an error code of
ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is
compiled with the 'debug' pkgsrc option, an assert fails, abort() is
called and a coredump written.

Actions #1

Updated by corecode over 16 years ago

I thought we had fixed that some time ago already?

Actions #2

Updated by dillon over 16 years ago

:I have a Firefox problem caused by DragonFly and/or libthread_xu.
:sched_get_priority_min(SCHED_OTHER) and
:sched_get_priority_max(SCHED_OTHER) return values PRIO_MIN (-20) and
:PRIO_MAX(20), both defined in sys/sys/resource.h.
:When pthread_attr_setschedparam is called to set scheduling priority for
:scheduling policy SCHED_OTHER, the priority value is checked if it is
:within range by comparing it to THR_MIN_PRIORITY(0) and
:THR_MAX_PRIORITY(31), both defined in
:lib/libthread_xu/thread/thr_private.h. When a value in the range [-20;
:-1] is used, pthread_attr_setschedparam returns an error code of
:ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is
:compiled with the 'debug' pkgsrc option, an assert fails, abort() is
:called and a coredump written.

Nice catch.  I'll clean up the priority handling code right now.
-Matt
Matthew Dillon
<>
Actions #3

Updated by dillon over 16 years ago

:...
:> THR_MAX_PRIORITY(31), both defined in
:> lib/libthread_xu/thread/thr_private.h. When a value in the range [-20;
:> -1] is used, pthread_attr_setschedparam returns an error code of
:> ENOTSUPP, which NSPR doesn't like. More precisely, when Firefox is
:> compiled with the 'debug' pkgsrc option, an assert fails, abort() is
:> called and a coredump written.
:
:I thought we had fixed that some time ago already?

Nope, I'm looking at the code and it is definitely a problem.  There
are a bunch of THR_ defines that are essentially not used by
the library at all, except for that (broken) range check.
The only thing that uses THR_MAX_PRIORITY is the m_ceiling
attribute in the mutex attribute structure, which we don't use
at all (and I think it operates in a private scheduling domain
anyway).
I'll have a patch for people w/ the firefox setup to try in a moment.
-Matt
Matthew Dillon
<>
Actions #4

Updated by dillon over 16 years ago

Please try the following patch to libthread_xu and tell me if it
fixes firefox:

fetch http://apollo.backplane.com/DFlyMisc/schedp01.patch
-Matt
Actions #5

Updated by corecode over 16 years ago

for the record, this seems to be related to

http://bugs.dragonflybsd.org/issue622

cheers
simon

Actions #6

Updated by wa1ter over 16 years ago

On Mon, 14 Jul 2008, Matthew Dillon wrote:

Yes, it works for me. Thanks to Jordan for tracking this down!

Actions #7

Updated by dillon over 16 years ago

:On Mon, 14 Jul 2008, Matthew Dillon wrote:
:
:> Please try the following patch to libthread_xu and tell me if it
:> fixes firefox:
:>
:> fetch http://apollo.backplane.com/DFlyMisc/schedp01.patch
:
:Yes, it works for me. Thanks to Jordan for tracking this down!

Ok, I've committed it.
-Matt
Matthew Dillon
<>
Actions

Also available in: Atom PDF