210138 - thread problem and initialisation problem

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Patrick Welche]

User-Agent:       Mozilla/4.74 [en] (X11; U; NetBSD 1.6T i386)
Build Identifier: CVS of Jun 19 2003 16:14GMT  (1.5a)

I'm trying to compile and run firebird from cvs on NetBSD-1.6T/i386 which does
come with a native libpthread. Compilation is apparently successful.
With no .mozilla nor .phoenix directory, I just run MozillaFirebird and either
get

Reproducible: Always

Steps to Reproduce:
1.Fresh build and install.
2.MozillaFirebird
3.

Actual Results:  
Either:

[1]   Segmentation fault (core dumped) "${prog}" ${1+"$...
#0  0x482b2c15 in _PR_CPU_Idle (_cpu=0x806a000) at prucpu.c:383
383                     _PR_MD_SWITCH_CONTEXT(me);
(gdb) bt
#0  0x482b2c15 in _PR_CPU_Idle (_cpu=0x806a000) at prucpu.c:383
#1  0x482b4dbc in _PR_UserRunThread () at pruthr.c:523
Current language:  auto; currently c

or: (I actually ran MozillaFirebird as root before this which is why xpti.dat
is already there..)

Type Manifest File: /usr/local/lib/mozilla-1.5a/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsChromeRegistry.cpp,
line 3190
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsChromeRegistry.cpp,
line 3190
GFX: dpi=75 t2p=0.0526316 p2t=19 depth=24
WEBSHELL+ = 1
LoadPlugin() /usr/local/lib/mozilla-1.5a/plugins/libnullplugin.so returned
81fe940
GetMIMEDescription() returned "*:.*:All types"
###!!! ASSERTION: Error occured reading image preferences: 'NS_SUCCEEDED(rv)',
file nsImgManager.cpp, line 116
Break: at file nsImgManager.cpp, line 116
WEBSHELL+ = 2



Expected Results:  
Hopefully not given me any errors.

By Reproducibilty = "Every time" I mean, every time, I either get the thread
core dump, or the image preferences assert.
I can go into .phoenix...chrome and
cp userChrome-example.css userChrome.css
cp userContent-example.css userContent.css
and that doesn't change the outcome.

I have the core dump - just let me know if you need further info!

Comment 1

[Mike Connor [:mconnor]]

Patrick, can you try this again with a current CVS pull and run firebird with
the -p switch to create a clean profile?  There was some oddity around linux
builds at that time which seem to have been resolved.

Also, this isn't a blocker.

Comment 2

[Mike Connor [:mconnor]]

No response from reporter in one month.  Resolving WORKSFORME pending further
information.

Comment 3

[Simon Paquet [:sipaq]]

verified

Comment 4

[Patrick Welche]

There was quite a bit of work on threads in NetBSD in the meantime, so I just
tried again on NetBSD-1.6ZC with mozilla/phoenix CVS of 17 September.

I have exactly the same outcome. Compilation is successful, and get the same
coredump in prucpu.c:383 as before.

From your suggestions, MozillaFirebird -p doesn't work for me as apparently
MozillaFirebird-bin.pure doesn't get built. (It certainly doesn't appear in
lib/mozilla-1.5b.) I didn't notice any errors to that effect though.

Have those of you say "WORKSFORME" actually tried with NetBSD-current? (ie., a
version of NetBSD with native threads)

From my point of view it is obviously a blocker: I get a coredump every time.

Comment 5

[Mike Connor [:mconnor]]

NetBSD is a tier 3 platform for Mozilla, so this doesn't qualify as a blocker to
development.  http://www.mozilla.org/build/faq.html#supported for more
information on this.

As for marking it WORKSFORME, we don't leave unconfirmed bugs open if there is
no response from the reporter and no confirmation elsewhere.

Does building Mozilla work?  (i.e. is this a problem specific to Firebird?  as
far as I know, nsChromeRegistry is essentially the same on both products.

Comment 6

[Patrick Welche]

Upgraded everything once again, with no change. Stared at the code, trivial
patch which has nothing to do with this is attached. Just an extra snipped of
info in case the contents of the PRThread shed any light:

Core was generated by `MozillaFirebird-'.
Program terminated with signal 11, Segmentation fault.
#0  0x48246ee1 in _PR_CPU_Idle (_cpu=0x0) at prucpu.c:384
384                     if (!_PR_IS_NATIVE_THREAD(me)) _PR_FAST_INTSON(is);
(gdb) bt
#0  0x48246ee1 in _PR_CPU_Idle (_cpu=0x0) at prucpu.c:384
#1  0x48249051 in _PR_UserRunThread () at pruthr.c:523
(gdb) print *me
$2 = {state = 1, priority = PR_PRIORITY_NORMAL, arg = 0x8068000, 
  startFunc = 0x48246e24 <_PR_CPU_Idle>, stack = 0x8066040, environment = 0x0, 
  dump = 0, dumpArg = 0x0, tpdLength = 0, privateData = 0x0, errorCode = 0, 
  osErrorCode = 0, errorStringLength = 0, errorStringSize = 0, 
  errorString = 0x0, threadLock = {notused = 0 '\0'}, queueCount = 0, 
  waitCount = 0, active = {next = 0x0, prev = 0x0}, links = {next = 0x0, 
    prev = 0x0}, waitQLinks = {next = 0x0, prev = 0x0}, lockList = {
    next = 0x50011f88, prev = 0x50011f88}, sleep = 0, wait = {lock = 0x0, 
    cvar = 0x0}, id = 1, flags = 513, no_sched = 0, term = 0x0, 
  cpu = 0x8068000, threadAllocatedOnStack = 1, io_pending = 0, io_fd = 0, 
  io_suspended = 0, md = {context = {1210347208, 1210419996, 1342250532, 
      1342250576, 0, 1210423984, 8192, 0, 0, 0, 1, 0, 0, 0}, id = 0, 
    errcode = 0}}

Comment 7

[Patrick Welche]

Attachment: underquoted m4 + unused variable

- aclocal will process m4 files more than once, so the macro name in an
AC_DEFUN needs quoting
- _PRSockOptVal_t doesn't appear to be used anywhere, so removing just reduces
the chance of hitting the #error "Cannot determine architecture"

Comment 8

[Simon Paquet [:sipaq]]

Patrick, thanks for the patches, but please open new bugs for the specific
issues, which are fixed by the patches or contribute to already existing bugs
(if they exist).

Comment 9

[Patrick Welche]

I just had another go with fresh cvs of 2004-Feb-21, and now I don't have a core
dump, however this may shed some light:

% firefox
Type Manifest File: /usr/local/lib/mozilla-1.7a/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
*** global extensions startup!
GFX: dpi=75 t2p=0.0526316 p2t=19 depth=24
++WEBSHELL == 1
++DOMWINDOW == 1
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsPermissionManager.cpp,
line 610
++WEBSHELL == 2
++DOMWINDOW == 2

Now the browser appears to hang. Connecting to the process shows:

[Switching to Thread 0]
nbsd_thread_fetch_registers: td_map_id2thr: process callback error

(gdb) 
(gdb) bt
#0  0x486fd474 in pthread_spinlock () from /usr/lib/libpthread.so.0
Error accessing memory address 0x486fd468: Operation not permitted.
(gdb)

Comment 10

[Patrick Welche]

I revisited this on NetBSD 3.99.6 with mozilla-cvs of 20 June 2005 and no longer
see this problem. (Will resubmit the still relevant patches as new bugs as they
are OT)

Comment 11

[Wan-Teh Chang]

I guess this is because we are now using the pthread library on
NetBSD, so the code in question (NSPR's own user-level
thread library) is no longer being compiled and used.