Bug #1072

Firefox/libthread_xu issue with pthread_attr_setschedparam

Added by jgordeev over 6 years ago. Updated over 6 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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.

History

#1 Updated by corecode over 6 years ago

I thought we had fixed that some time ago already?

#2 Updated by dillon over 6 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
<>

#3 Updated by dillon over 6 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
<>

#4 Updated by dillon over 6 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

#5 Updated by corecode over 6 years ago

for the record, this seems to be related to

http://bugs.dragonflybsd.org/issue622

cheers
simon

#6 Updated by wa1ter over 6 years ago

On Mon, 14 Jul 2008, Matthew Dillon wrote:

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

#7 Updated by dillon over 6 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
<>

Also available in: Atom PDF