If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Assertion failure: -1 != pt_book.minPrio, at ptthread.c:818

RESOLVED WONTFIX

Status

NSPR
NSPR
P2
critical
RESOLVED WONTFIX
17 years ago
13 years ago

People

(Reporter: hrp, Assigned: Wan-Teh Chang)

Tracking

({crash})

other
x86
FreeBSD
crash

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (X11; U; FreeBSD 3.4-RELEASE i386)
BuildID:    0.8

During the build, the regchrome step fails.  Here is the tail of the Make
output:

	RegSelf Unicode to x-mathematica5 converter complete
	RegSelf Unicode to x-mtextra converter complete
	*** Deferring registration of sample JS components
	registerSelf for remoteControl
	*** Registering sample JS components
	*** Unloading sample JS components
	Segmentation fault - core dumped
	*** Error code 139

Regchrome tipped over trying to create a pthread.  Here is the backtrace from
GDB on the corefile:

	#0  0x281c368d in _pq_insert_tail () from /usr/lib/libc_r.so.3
	#1  0x28191ab1 in pthread_create () from /usr/lib/libc_r.so.3
	#2  0x28095022 in _PR_CreateThread ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libnspr4.so
	#3  0x280951fe in PR_CreateThread ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libnspr4.so
	#4  0x2812970b in nsThread::Init ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#5  0x28129809 in NS_NewThread ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#6  0x284ee47a in nsSocketTransportService::Init ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libnecko.so
	#7  0x284ee269 in nsSocketTransportService::Create ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libnecko.so
	#8  0x2811e047 in nsGenericFactory::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#9  0x2811b9e9 in nsComponentManagerImpl::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#10 0x28123432 in nsComponentManager::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#11 0x281240be in nsServiceManagerImpl::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#12 0x281246ba in nsServiceManager::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#13 0x284e8e3f in nsIOService::Init ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libnecko.so
	#14 0x284e922b in nsIOService::Create ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libnecko.so
	#15 0x2811e047 in nsGenericFactory::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#16 0x2811b9e9 in nsComponentManagerImpl::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#17 0x28123432 in nsComponentManager::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#18 0x281240be in nsServiceManagerImpl::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#19 0x281246ba in nsServiceManager::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#20 0x281238ac in nsGetServiceByCID::operator() ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#21 0x2812fc58 in nsCOMPtr_base::assign_from_helper ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#22 0x28356a2a in RDFXMLDataSourceImpl::Init ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/librdf.so
	#23 0x2821eec8 in nsChromeRegistry::LoadDataSource ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libchrome.so
	#24 0x28226af8 in nsChromeRegistry::AddToCompositeDataSource ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libchrome.so
	#25 0x282278f6 in nsChromeRegistry::CheckForNewChrome ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libchrome.so
	#26 0x2821c8a2 in nsChromeRegistry::Init ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libchrome.so
	#27 0x2821b834 in nsChromeRegistryConstructor ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/components/libchrome.so
	#28 0x2811e047 in nsGenericFactory::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#29 0x2811b9e9 in nsComponentManagerImpl::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#30 0x28123432 in nsComponentManager::CreateInstance ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#31 0x281240be in nsServiceManagerImpl::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#32 0x28124523 in nsServiceManagerImpl::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#33 0x281247d6 in nsServiceManager::GetService ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#34 0x2812391c in nsGetServiceByContractID::operator() ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#35 0x2812fc58 in nsCOMPtr_base::assign_from_helper ()
	   from /usr/ports/www/mozilla/work/mozilla/dist/bin/./libxpcom.so
	#36 0x804889e in main ()
	#37 0x804873d in _start ()



Reproducible: Always
Steps to Reproduce:
1. Get FreeBSD port of Mozilla (Makefile v1.57)
2. Get Mozilla source from
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.8/src/mozilla-source-0.8.tar.bz2
3. Unpack and build using the FreeBSD port makefile
4. Watch the compilation die in the "post-build" stage.

Actual Results:  Core dump from regchrome.  Build did not complete.

Expected Results:  It should have finished compiling.

Comment 1

17 years ago
Adding crash keyword.
Keywords: crash

Comment 2

17 years ago
Reporter is this still occruing in the latest nightlies?
Severity: blocker → critical
(Reporter)

Comment 3

17 years ago
I haven't tried nightlies.  I've pulled a fresh CVS tree and I'll try to build
from that.  It may take a day or two, but I'll let you know when I have a
result.
(Reporter)

Comment 4

17 years ago
I pulled a fresh tree from CVS and got the same result:  regchrome drops core.

Rebuilt with debugging (configure --enable-debug) and now both regchrome and
regxpcom fall over with assertions:

	Assertion failure: -1 != pt_book.minPrio, at ptthread.c:818

I do not know if this is the same problem, but it is suggestive that both the
core dump (without debugging) and the assertion (with debugging) occur in
threading.
(Reporter)

Comment 5

17 years ago
I think that the assertions were red herrings.  The sched_get_priority_min
system call is not implemented (returns ENOSYS) in FreeBSD-3.4.  I modified
nsprpub/pr/src/pthreads/ptthread.c to use constant values (PT_PRIO_MIN and
PT_PRIO_MAX) instead, and the assertions went away.

Now regxpcom runs to completion, or at least it appears to.  There are some
complaints near the end of the run, which I clip here:

================================================================
Runtime mismatch, so leaking context!
JS API usage error: 1 contexts left in runtime upon JS_DestroyRuntime.
JS engine warning: 948 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
JS engine warning: leaking GC root 'res->input' at 0x805b6b0
JS engine warning: 1 GC root remains after destroying the JSRuntime.
                   This root may point to freed memory. Objects reachable
                   through it have not been finalized.
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0',
file nsXPComInit.cpp, line 503
###!!! Break: at file nsXPComInit.cpp, line 503
###!!! ASSERTION: nsDOMEvent not thread-safe: 'owningThread ==
NS_CurrentThread()', file nsDebug.cpp, line 524
###!!! Break: at file nsDebug.cpp, line 524
================================================================

...and regchrome is back to its old trick of dumping core in the guts of
pthread_create.

Comment 6

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

17 years ago
hey jud,

any idea who should own this bug?  I don't think it should be me :-)

-- rick

Comment 8

17 years ago
-> default xpcom owner.
Component: Threading → XPCOM Registry

Comment 9

17 years ago
-> default xpcom owner.
Assignee: rpotts → rayw
QA Contact: rpotts → rayw

Comment 10

17 years ago
Reporter, I just filed Bug 78857, which I think is the same as the current 
problem described at the end of this bug.

After lots of reading, I think the original problem is not the same as the tail 
of this bug report.

wrt nsprpub/pr/src/pthreads/ptthread.c could you please attach a cvs diff to 
this bug so we can get it into NSPR? ... Changing bug to focus on this.
Assignee: rayw → larryh
Component: XPCOM Registry → NSPR
Product: Browser → NSPR
Summary: Regchrome dumps core during FreeBSD build → Assertion failure: -1 != pt_book.minPrio, at ptthread.c:818
Target Milestone: --- → 4.2

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
(Assignee)

Comment 11

17 years ago
Assigned the bug to me.
Assignee: larryh → wtc
Status: ASSIGNED → NEW
Priority: P2 → P1
(Assignee)

Updated

17 years ago
Priority: P1 → P2
(Reporter)

Comment 12

16 years ago
I can no longer reproduce this problem.  It disappeared when I upgraded my
FreeBSD system to release 4.2 from release 3.4.  I suspect (with little
evidence) that it has to do with gcc-2.95.3 being the default compiler
environment in FreeBSD-4.2.
(Assignee)

Comment 13

16 years ago
It makes sense that you can no longer reproduce
this assertion failure after you upgraded to
FreeBSD 4.2 from FreeBSD 3.4.  I bet that
sched_get_priority_min() is implemented on
FreeBSD 4.2, so it no longer fails.

I still want to try and fix this...
Status: NEW → ASSIGNED
(Reporter)

Comment 14

16 years ago
You win the bet:  sched_get_priority_min *is* implemented in current FreeBSD
releases.
what is the current status on this? Is this something that is still an issue?

(trying to help focus on the bugs that are still relevant)

I donĀ“t meant to spam, but should this be marked WORKSFORME or WONTFIX?
(Reporter)

Comment 16

15 years ago
It is no longer an issue for me personally, because I now run a release of
FreeBSD that implements sched_get_priority_min.  I expect that it will be an
issue for anybody who tries to install on old FreeBSD releases.  I guess it's up
to mozilla.org to decide whether to worry about that.
(Assignee)

Comment 17

13 years ago
Marked the bug WONTFIX.  Sorry it fell through the
cracks.  Now it is not worthwhile to fix the bug
for FreeBSD 3.4 or older.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
Target Milestone: 4.2 → 4.6
You need to log in before you can comment on or make changes to this bug.