124958 - (openbsd) Crash on startup in OpenBSD in static constructor calls

Status: VERIFIED DUPLICATE of bug 236599

(Core :: XPCOM, defect)

Description

[Richard Runds]

Compiled mozilla 0.9.8 and got Memory Fault on startup and a core dump.

.mozconfig:
ac_add_options --with-pthreads
ac_add_options --without-system-nspr
ac_add_options --without-system-zlib
ac_add_options --without-system-jpeg
ac_add_options --without-system-png
ac_add_options --without-system-mng
ac_add_options --enable-crypto
ac_add_options --enable-optimize=-g
ac_add_options --enable-double-buffer
ac_add_options --disable-mailnews
ac_add_options --disable-editor
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --disable-xterm-updates
ac_add_options --disable-pedantic
ac_add_options --disable-cpp-exceptions

gdb output:
# gdb mozilla-bin mozilla-bin.core
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.0"...
Core was generated by `mozilla-bin'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /tmp/mozilla/dist/bin/./libgkgfx.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libjsj.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libmozjs.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libxpcom.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libplds4.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libplc4.so.1.0...done.
Reading symbols from /tmp/mozilla/dist/bin/./libnspr4.so.1.0...done.
Reading symbols from /usr/local/lib/libgtk.so.1.2...done.
Reading symbols from /usr/local/lib/libgdk.so.1.2...done.
Reading symbols from /usr/local/lib/libgmodule.so.1.2...done.
Reading symbols from /usr/local/lib/libglib.so.1.2...done.
Reading symbols from /usr/local/lib/libintl.so.1.1...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6.4...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6.2...done.
Reading symbols from /usr/lib/libm.so.0.1...done.
Reading symbols from /usr/lib/libstdc++.so.30.0...done.
Reading symbols from /usr/lib/libc_r.so.6.0...done.
Reading symbols from /usr/local/lib/libiconv.so.2.4...done.
#0  0x4017b6d6 in nsVoidArray::InsertElementAt (this=0x402bb4c0,
    aElement=0x40242c40, aIndex=0) at nsVoidArray.cpp:408
408         if (!GrowArrayBy(1))


gdb backtrace:
(gdb) bt
#0  0x4017b6d6 in nsVoidArray::InsertElementAt (this=0x402bb4c0,
    aElement=0x40242c40, aIndex=0) at nsVoidArray.cpp:408
#1  0x4017e1b0 in nsVoidArray::AppendElement (this=0x402bb4c0,
    aElement=0x40242c40) at nsVoidArray.h:112
#2  0x40157948 in NS_RegisterXPCOMExitRoutine (
    exitRoutine=0x40242c40 <FreeGlobalMemory(void)>, priority=0)
    at nsXPComInit.cpp:475
#3  0x40242ce6 in SetupGlobalMemory () at nsMemory.cpp:67
#4  0x40242e0c in nsMemory::Free (ptr=0x4e4c0) at nsMemory.cpp:96
#5  0x4022e427 in XPCOM_StringAllocator<char>::Deallocate (this=0x402bb710,
    aBuffer=0x4e4c0 "/tmp/mozilla/dist/bin") at nsReadableUtils.cpp:50
#6  0x40230851 in nsSharedBufferHandle<char>::~nsSharedBufferHandle (
    this=0x51310, __in_chrg=3)
    at ../../dist/include/string/nsBufferHandle.h:381
#7  0x402308db in nsSharedBufferHandle<char>::ReleaseReference (this=0x51310)
    at ../../dist/include/string/nsBufferHandle.h:393
#8  0x40231e6c in nsAutoBufferHandle<char>::operator= (this=0x55370,
    rhs=0x54f80) at ../../dist/include/string/nsBufferHandleUtils.h:74
#9  0x4022ff35 in nsSharableCString::SetCapacity (this=0x5536c,
    aNewCapacity=35) at nsSharableString.cpp:227
#10 0x402301cf in nsSharableCString::SetLength (this=0x5536c, aNewLength=35)
    at nsSharableString.cpp:268
#11 0x4022306c in nsACString::do_AppendFromReadable (this=0x5536c,
    aReadable=@0xdfbfd3e8) at nsAString.cpp:877
#12 0x40222ed3 in nsACString::AppendFromPromise (this=0x5536c,
    aReadable=@0xdfbfd3e8) at nsAString.cpp:856
#13 0x40225045 in nsACString::Append (this=0x5536c, aReadable=@0xdfbfd3e8)
    at ../../dist/include/string/nsAString.h:672
#14 0x401b8322 in nsLocalFile::AppendRelativePath (this=0x55300,
    fragment=0x4018b2d1 "component.reg") at nsLocalFileUnix.cpp:455
#15 0x401b8231 in nsLocalFile::Append (this=0x55300,
    fragment=0x4018b2d1 "component.reg") at nsLocalFileUnix.cpp:439
#16 0x4018b424 in nsDirectoryService::GetFile (this=0x4e260,
    prop=0x401d61c8 "ComRegF", persistent=0xdfbfd5e4, _retval=0xdfbfd5e0)
    at nsDirectoryService.cpp:806
#17 0x4018a873 in FindProviderFile (aElement=0x4e268, aData=0xdfbfd5dc)
    at nsDirectoryService.cpp:655
#18 0x4018ac5f in nsDirectoryService::Get (this=0x4e260,
    prop=0x401d61c8 "ComRegF", uuid=@0x401d5588, result=0xdfbfd69c)
    at nsDirectoryService.cpp:697
#19 0x401d634b in nsRegistry::OpenWellKnownRegistry (this=0x4e440, regid=1)
    at nsRegistry.cpp:537
#20 0x401c33e4 in nsComponentManagerImpl::PlatformInit (this=0x52100)
    at nsComponentManager.cpp:682
#21 0x401c2d79 in nsComponentManagerImpl::Init (this=0x52100)
    at nsComponentManager.cpp:565
#22 0x401571c0 in NS_InitXPCOM2 (result=0x0, binDirectory=0x0,
    appFileLocationProvider=0x0) at nsXPComInit.cpp:379
#23 0x8633 in main (argc=1, argv=0xdfbfd98c) at nsAppRunner.cpp:1607

Comment 1

[Matt Behrens]

Confirming with CVS as of yesterday.  There is a segmentation fault at the call
to GrowArrayBy (not actually in the function itself, but trying to call it.)

Comment 2

[hacker formerly known as [e-mail]]

Also confirming.  I'm seeing the same problem on the test OpenBSD 3.0 tinderbox.
 FWIW, TestXPTCInvoke works fine.  

Comment 3

[Doug Turner (:dougt)]

something funny is going on.  SetupGlobalMemory should not have been called so
late.  

Any have a build that I can set some breakpoint on?  

Comment 4

[hacker formerly known as [e-mail]]

This is so screwy.  First, how does anyone debug on OpenBSD at all?  gdb seems
to have this nice bug where your stack goes off into _GLOBAL_OFFSET_TABLE_
territory if any of your main app is built with pic (that seems to be the
condition that most triggers the bug).  

After fixing a build issue in NSPR (bug 145560), I'm hitting another problem
specifically wrt the global gMemory variable.  Assuming that gdb isn't just
having another mental breakdown, we're having a problem with global variables
being used outside of the file that they are declared in:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /builds/cltbld/obj-dbg/dist/bin/./TestFactory 

Breakpoint 6, nsMemoryImpl::Startup ()
    at ../../../mozilla/xpcom/base/nsMemoryImpl.cpp:502
502         EnsureGlobalMemoryService();
(gdb) p gMemory
$10 = (nsMemoryImpl *) 0x0
(gdb) n
503         if (! gMemory)
(gdb) p gMemory
$11 = (nsMemoryImpl *) 0x11180
(gdb) n
521         return NS_OK;
(gdb) p gMemory
$12 = (nsMemoryImpl *) 0x11180
(gdb) n
522     }
(gdb) p gMemory
$13 = (nsMemoryImpl *) 0x11180
(gdb) n
NS_InitXPCOM2 (result=0xdfbfd6d0, binDirectory=0x0, 
    appFileLocationProvider=0x0)
    at ../../../mozilla/xpcom/build/nsXPComInit.cpp:333
333         if (NS_FAILED(rv)) return rv;
(gdb) p gMemory
$14 = (nsIMemory *) 0x0
(gdb) 

Hrm.  We seem to have gMemory declared in at least 3 different places within
xpcom; twice as a static variable and once as a global variable.  If I change
the static declarations to extern, then the test apps work (well, some of them).  

Comment 5

[hacker formerly known as [e-mail]]

So along the same vein, the next crash is from regxpcom in nsTimerImpl::Shutdown.  

gdb) r
Starting program: /builds/cltbld/obj-dbg/dist/bin/./regxpcom 
Type Manifest File: /builds/cltbld/obj-dbg/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)

Program received signal SIGSEGV, Segmentation fault.
0x40108d07 in nsTimerImpl::Shutdown ()
    at ../../../mozilla/xpcom/threads/nsTimerImpl.cpp:189
189       if (PR_LOG_TEST(gTimerLog, PR_LOG_DEBUG)) {
(gdb) bt
#0  0x40108d07 in nsTimerImpl::Shutdown ()
    at ../../../mozilla/xpcom/threads/nsTimerImpl.cpp:189
#1  0x40029306 in NS_ShutdownXPCOM (servMgr=0x0)
    at ../../../mozilla/xpcom/build/nsXPComInit.cpp:574
#2  0x269c in main (argc=1, argv=0xdfbfd720)
    at ../../../../mozilla/xpcom/tools/registry/regxpcom.cpp:202
(gdb) p gTimerLog
$1 = (PRLogModuleInfo *) 0x0
(gdb) 

gTimerLog is declared as a static variable in nsTimerImpl.h, which is also used
by TimerThread.cpp.  Is OpenBSD's linker being braindead when it clobbers these
static variables from separate files that are in the same library?  Or should we
not be using this initially confusing but apparently useful technique?

Comment 6

[hacker formerly known as [e-mail]]

Argh.  Braindead toolkit.  The timers issue appears to be a problem with static
constructors, or rather, the lack thereof.  It seems that the problem has been
around for awhile, http://www.monkey.org/openbsd/archive/bugs/0009/msg00013.html
.  For some reason, linking xpcom using 'gcc -shared' instead of 'ld
-Bshareable' causes apps to not be able to initialize the shared library:

shrike:bin {498} ./run-mozilla.sh ./regxpcom
failed to initialize shared libraries [Service unavailable]
Abort (core dumped) 

The NSPR tests still work fine when libnspr is linked using 'gcc -shared'.

Comment 7

[hacker formerly known as [e-mail]]

Attachment: tgz of static constructor test

So we definitely have a problem with static constructors not working properly
when using ld to link.	The OpenBSD ld.so manpage seems to infer that it's
possible to get them working if you also explicitly link in /usr/lib/c++rt0.o,
but I can't seem to get that to work. 

I'm attaching the testcase that I used to verify that the static constructors
aren't being called when ld is used to create the shared lib but they are being
called when 'gcc -shared' is used to link the shared lib.  I've only tested it
on openbsd but if you compare the output of 'gmake run' vs 'gmake run
LD_LINK=1', then it's fairly obvious that the static constructor isn't being
called.

Since 'gcc -shared' allows the static constructors in the testcase to work, I'm
wondering if we're not just dying inside a static constructor inside of xpcom. 
Since gdb won't even load the library, I don't know of anyway to test this.

Comment 8

[Matt Behrens]

Attachment: use gcc -shared on OpenBSD a.out arches where supported

With the attached patch to configure.in, and if I comment out the dlopen test
in nsprpub/pr/src/linking/prlink.c, I get

[manos bin]$ ./run-mozilla.sh ./regxpcom
Type Manifest File: /usr/home/matt/src/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
*** Registering nsTestDynamicModule components (all right -- a generic module!)

*** Registering nsTestDynamicModule components (all right -- a generic module!)

*** Registering nsTestDynamicModule components (all right -- a generic module!)

nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt ==
0', file nsXPComInit.cpp, line 592
Break: at file nsXPComInit.cpp, line 592

(Note I am on OpenBSD-current, but I don't think it matters much for this
discussion...)
I am not clear why the dlopen(0, RTLD_LAZY) call is failing (returning NULL); a
real short testcase succeeds.
I'm in the process of building everything else right now.

Comment 9

[Matt Behrens]

Still no joy:

[manos bin]$ ./run-mozilla.sh ./viewer
Type Manifest File: /usr/home/matt/src/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
Unable to instantiate Cookie Manager
WARNING: NS_ENSURE_TRUE(mWindow) failed, file nsBrowserWindow.cpp, line 377
Memory fault (core dumped) 

[manos bin]$ ./run-mozilla.sh ./mozilla-bin
Type Manifest File: /usr/home/matt/src/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)

I gather there are some ld.so problems that need fixing on OpenBSD for this to work.

Comment 10

[Stuart Lamble]

FYI: Still seeing this, running OpenBSD 3.1, Mozilla 1.0RC2. (Okay, _trying_ to
run Mozilla 1.0RC2 :-) i386 platform.

Comment 11

[Matt Behrens]

http://groups.google.com/groups?selm=87lmaoon4z.fsf%40kaka.blahonga.org.lucky.openbsd.misc

has some patches for OpenBSD that may get people a little further.  I will try
them later today.

Comment 12

[Matt Behrens]

Done.  Still no go.  Same messages as above, but I don't need the prlink.c hack
anymore.

Comment 13

[Doug Turner (:dougt)]

this bug needs to be owned by someone that has the time to support OpenBSD 3.0.
 When this hero steps forward, please reassign and retarget the milestone.

Comment 14

[timeless]

can you attach the stack trace from viewer (w/ line numbers) from comment 9?

Comment 15

[hacker formerly known as [e-mail]]

*** Bug 61970 has been marked as a duplicate of this bug. ***

Comment 16

[hacker formerly known as [e-mail]]

*** Bug 57454 has been marked as a duplicate of this bug. ***

Comment 17

[Matt Behrens]

[e-mail]: my test system does not currently exist.  If anyone out
there following this bug can repro what I got in comment #9 (shouldn't be too
tough, apply art@openbsd's patch from the google groups post, plus my
configure.in patch, rerun autoconf, then build as usual), please run

$ ./run-mozilla.sh -g -d gdb ./viewer

then at the gdb prompt, type run, then when it crashes, bt.  This will give the
trace.

dougt@: Sorry, I am not the hero, just a hopefully helpful bystander.

Also, will someone with sufficient powers please reflect reality in the summary?
 This issue, be it Mozilla's or OpenBSD's, affects all versions of OpenBSD
including -current, though I do think it would be quite reasonable to target 2.8
on up, since before 2.8 a.out arches did not support 'cc -shared'.

Comment 18

[Artur Grabowski]

I have made some progress making mozilla to run on OpenBSD.

This particular bug is caused by the shared library being linked with
ld -Bshareable instead of cc -shared.

The reason for that is pretty simple. a.out doesn't have any built in support
for constructors. Instead a special pre-linking program is run by gcc to collect
all constructors (gcc gives them special reserved names) and stuff them into
a table of function pointers that are later run by ld.so. (all this is really
ugly).

Anyway. When that problem is fixed a bunch of other problems surface some with
simple fixes, some that are a real pain. I don't have a running browser yet,
but I have written down everything I had to hack to at least get closer. The
information is at http://www.blahonga.org/~art/openbsd/mozilla-progress

Comment 19

[timeless]

well it sounds like art is the closest thing we have to an assignee, thanks for 
the update.

Comment 20

[hacker formerly known as [e-mail]]

Comment on attachment 84302 [details] [diff] [review]
use gcc -shared on OpenBSD a.out arches where supported

r=cls

Comment 21

[hacker formerly known as [e-mail]]

Trimming the summary as the 'gcc -shared' issue has already been discussed. 
There is still an ldap build change required (bug 145136) to get mozilla-bin
working unless you build with --disable-ldap.  The NSPR fix to use the proper
threading scheme was checked in last night.   I didn't try to debug the browser.
 I had a hard enough time just trying to figure out why xpcshell wasn't working.
 It would die whenever it tried to get the JSRuntime service.

Comment 22

[jolan]

Is anyone still actively working on this?

Comment 23

[Jolan Luff]

There has been some progress with Mozilla & OpenBSD that happened with version
1.1.  Everything is very preliminary, but you can read the archived e-mail
thread at:

http://marc.theaimsgroup.com/?t=103056057200002&r=1&w=2

Comment 24

[Jolan Luff]

Attachment: fix for openbsd ssl/form submission crashes

Comment 25

[hacker formerly known as [e-mail]]

*** Bug 177558 has been marked as a duplicate of this bug. ***

Comment 26

[thebeastwitheyesthatstared]

what´s the current status on this, are there any patches, that could be 
uploaded here? Is it still happening with newer version(s)?
(bug cleaning)

Comment 27

[zoc]

*** Bug 196318 has been marked as a duplicate of this bug. ***

Comment 28

[Han Boetes]

Side comment in reaction to complaints about gdb.

You can find a port of gdb-5.2 on this site:

  http://vedge.com.ar/testing/

Runs as /usr/local/bin/egdb. Hope it helps.

Comment 29

[rich cannings]

for the impatient, I've posted how I got mozilla 1.3 up and running on
openbsd-current and a statically linked binary of it at:

http://pages.cpsc.ucalgary.ca/~cannings/openbsd

It's suprisingly stable, but it's a complete hack since it compiles statically
and uses a not-so-elegant fix in mozilla.in.

Comment 30

[rich cannings]

some permissions set were incorrecting at:

http://pages.cpsc.ucalgary.ca/~cannings/openbsd

they all work now. 

Comment 31

[dot]

I have Phoenix (http://www.mozilla.org/projects/phoenix) working pretty well for
over a month now, I'm using -current and latest mozilla tree from cvs.
To build I used the build instructions for UNIX (from
http://www.mozilla.org/build/unix-details.html).

0. Sometimes it crashes with message: 

"Gdk-ERROR **: BadAccess (attempt to access private resource denied)
  serial 117227 error_code 10 request_code 146 minor_code 1
Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
  serial 117228 error_code 177 request_code 146 minor_code 5"

I found that using the "--no-xshm" (Don't use X shared memory extension) helps
(could be just my imagination though), hopefully I'll debug this soon.

1. Java plugin for Linux doesnt work (gives: "LoadPlugin: failed to initialize
shared library /usr/dot/.mozilla/plugins/libjavaplugin_oji.so [Inappropriate
file type or format]" no matter what I do).


This is my .mozconfig:

export MOZ_PHOENIX=1
mk_add_options MOZ_PHOENIX=1
ac_add_options --disable-shared 
ac_add_options --enable-static
ac_add_options --enable-crypto 
ac_add_options --enable-strip
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-mailnews
ac_add_options --disable-composer
ac_add_options --with-system-zlib
ac_add_options --without-pthreads
ac_add_options --prefix=/usr/local
ac_add_options --enable-toolkit=xlib
ac_add_options --disable-md
ac_add_options --disable-pedantic
ac_add_options --disable-cpp-exceptions 
ac_add_options --disable-cpp-rtti 
ac_add_options --enable-chrome-format=jar
ac_add_options --with-system-png
ac_add_options --disable-ldap
ac_add_options --disable-mailnews
ac_add_options --enable-plaintext-editor-only
ac_add_options --enable-optimize="-O2  -fno-stack-protector "

Comment 32

[Boris Lenko]

Static mozilla seems to work well. Is there anyway to use AA fonts with a static build? 

Comment 33

[David Krause]

This bug is concerned with OpenBSD crashing in static constructor calls.  It is
already known that a static OpenBSD build works.  Please stop wasting developer
time and filling up this bug report with irrelevant information to this
particular bug.  Any off-topic posts just make getting Mozilla running take
longer because the Mozilla developers have to read through all this garbage.

If you have questions about building Mozilla statically or want 
to write a howto about it please post those to [e-mail].  Several
people have already written detailed explanations that are available by
searching the archives at http://www.openbsd.org/mail.html.

Thank you for your future cooperation,
David

Comment 34

[rich cannings]

I've updated the build and binaries so mail and news now run. It required no
patches, just a new .mozconfig. See:

http://pages.cpsc.ucalgary.ca/~cannings/openbsd

In response to that last comment: I agree that misdirected reports slow
development, but (un)fortunately, this bug (124958) has become the de facto
bug for getting mozilla running on openbsd. 

I think my last report did help development and resulted in creating bugs 198461
and 198462, and mirroring/posting the binary on the mozilla site.

We should keep communicating over appropriate channels. May I recommend that we
create a meta-bug to encompass getting mozilla running on openbsd and publishing
major achievemnts with respect to all the openbsd bugs? A place where the
general audience could be relocated? I'll leave that judgement to an experienced
developer, since I'm very new around here.

Comment 35

[Jolan Luff]

In regards to this being the de facto bug for getting Mozilla running on OpenBSD...

Mozilla only works when compiled statically on i386, which is (still) a.out. 
i386 will be switching to ELF in the very near future (in the -current branch of
course).  Once this happens, it is a fairly sure bet that it will not work on
i386 anymore (even statically).  I say this because:

1) It doesn't work on any other OpenBSD platform which is ELF (alpha, macppc, &
sparc64).  AFAIK, Mozilla works fine on these hardware architectures running
different OSes (judging from FreeBSD/NetBSD ports)

2) It was built on a development snapshot of i386/ELF awhile ago and found not
to work then.

It seems people are complacent to use static builds and not try to solve the
real issue(s).  I believe it would be more beneficial to stop toiling with
static builds and help debug dynamic builds.

Some way to pool resources for the right reason (debugging !static builds) is a
great idea.  So great in fact that I will start setting up a mailing list &
bugzilla that is explicitly for moz+obsd.  I will announce it shortly after the
i386->ELF conversion takes place so real work can be reported, pooled, etc.

As for the posting of the binary on the Mozilla site... IMHO, it was extremely
shortsighted.  That package was built upon a development version of OpenBSD, and
the package name does not reflect that at all.  Chances are it will run just
fine on what will be released as 3.3, but it will *not* run on 3.1 and 3.2. The
package should be renamed appopriately to something that includes "3.3", or
maybe even just deleted as it was not built upon "true" 3.3. BTW, this is not a
hypothetical issue, see:

http://marc.theaimsgroup.com/?l=openbsd-misc&m=104861806829575&w=2

I am simply amazed at bug 198461.  The same patch has been attached to this bug
for 5 months and was never committed.

Comment 36

[thebeastwitheyesthatstared]

is the static/dynamic build situation still the same?

Comment 37

[Peter Strömberg]

Mozilla now runs dynamically 
 
patches for 1.4b found in http://wilfried.no-ip.org/mozilla-openbsd/ 
 
patch-xpcom_glue_nsIGenericFactory_h was the show stopper; 
global variables are shared by all shared libraries 
 
the other patches are configuration tweaks. 

Comment 38

[timeless]

Attachment: http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

Comment 39

[Doug Turner (:dougt)]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

why isn't gModuleInfo a problem?

Comment 40

[Doug Turner (:dougt)]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

please land on the trunk first.  I think it should probably land on the 1.4
branch as well.

Comment 41

[timeless]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

checked into trunk

Comment 42

[Asa Dotzler [:asa]]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

moving approval request forward.

Comment 43

[Asa Dotzler [:asa]]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

not enough time to get this in and tested well for 1.4.1 which we're trying to
get out quickly.

Comment 44

[Brendan Eich [:brendan]]

Comment on attachment 125406 [details] [diff] [review]
http://wilfried.no-ip.org/mozilla-openbsd/patch-xpcom_glue_nsIGenericFactory_h

This is a safe patch. I'm approving for 1.4.1.

/be

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmm.  I wonder how I managed never to be cc:ed on this bug.  I did a bit of work
trying to eliminate static constructors in the past (for the reasons I described
in bug 63014 comment 0):
http://bugzilla.mozilla.org/buglist.cgi?short_desc_type=casesubstring&short_desc=%5Bstatic+ctor%5D
and I also wrote some code that caused Mozilla to assert on any static
constructors that triggered nsTraceRefcnt's logging facilities (see bug 62006),
which could be enabled in DEBUG builds on other platforms (assuming it still
works).  I had been under the (mistaken) impression that this wasn't a problem
for OpenBSD anymore, I think due to lack of any interest in bug 49575.

Comment 46

[Mats Palmgren (inactive)]

Attachment: Combined patch

Still crashing on a trunk build on OpenBSD-3.4beta/i386 (2 day old -current).

Applying the "gcc -shared" patch on this bug (attachment 84302 [details] [diff] [review]) plus all the
remaining patches at http://wilfried.no-ip.org/mozilla-openbsd/  EXCEPT the
one for nsprpub/configure.in makes Mozilla run.

Comment 47

[Doug Turner (:dougt)]

Comment on attachment 130341 [details] [diff] [review]
Combined patch

this patch can not be reviewed/approved by me.	secure and nsprpub parts need
to be run by [e-mail] and the build/config change should be run by
[e-mail].

Comment 48

[Mats Palmgren (inactive)]

Attachment: Patch for nsprpub/ and security/

Comment 49

[Wan-Teh Chang]

Comment on attachment 130342 [details] [diff] [review]
Patch for nsprpub/ and security/

1. nsprpub/pr/include/md/_pth.h

>+#elif defined(OPENBSD)
>+#define PT_PRIO_MIN            0
>+#define PT_PRIO_MAX            31

Is this range documented?  If not, and if sched_get_priority_min
and sched_get_priority_max exist in OpenBSD's pthread library, it
is better to use sched_get_priority_min and sched_get_priority_max,
like the code for LINUX and FREEBSD.

2. security/coreconf/OpenBSD.mk

+DSO_LDOPTS		= -shared -fPIC
-Wl,-soname,lib$(LIBRARY_NAME)$(LIBRARY_VERSION).$(DLL_SUFFIX)

Do you really need to pass -fPIC to the linker when we build
a shared library?

Comment 50

[Wan-Teh Chang]

Comment on attachment 130342 [details] [diff] [review]
Patch for nsprpub/ and security/

1. nsprpub/pr/include/md/_pth.h

>+#elif defined(OPENBSD)
>+#define PT_PRIO_MIN            0
>+#define PT_PRIO_MAX            31

Is this range documented?  If not, and if sched_get_priority_min
and sched_get_priority_max exist in OpenBSD's pthread library, it
is better to use sched_get_priority_min and sched_get_priority_max,
like the code for LINUX and FREEBSD.

2. security/coreconf/OpenBSD.mk

+DSO_LDOPTS		= -shared -fPIC
-Wl,-soname,lib$(LIBRARY_NAME)$(LIBRARY_VERSION).$(DLL_SUFFIX)

Do you really need to pass -fPIC to the linker when we build
a shared library?

Comment 51

[Mats Palmgren (inactive)]

Attachment: Patch for nsprpub/ and security/ - rev. 2 (checked in)

> Is this range documented? 

Sort of, in a private header file lib/libpthread/uthread/pthread_private.h:

/*
 * Define the different priority ranges.  All applications have thread
 * priorities constrained within 0-31.	The threads library raises the
 * priority when delivering signals in order to ensure that signal
 * delivery happens (from the POSIX spec) "as soon as possible".
 * In the future, the threads library will also be able to map specific
 * threads into real-time (cooperating) processes or kernel threads.
 * The RT and SIGNAL priorities will be used internally and added to
 * thread base priorities so that the scheduling queue can handle both
 * normal and RT priority threads with and without signal handling.
 *
 * The approach taken is that, within each class, signal delivery
 * always has priority over thread execution.
 */
#define PTHREAD_DEFAULT_PRIORITY		15
#define PTHREAD_MIN_PRIORITY			0
#define PTHREAD_MAX_PRIORITY			31	/* 0x1F */


> If not, and if sched_get_priority_min
> and sched_get_priority_max exist in OpenBSD's pthread library, it

They are not implemented in OpenBSD.


> Do you really need to pass -fPIC to the linker

No, it works fine without it so I have removed it in this patch.
That is the only change compared with the last version of the patch.

Comment 52

[Wan-Teh Chang]

Comment on attachment 131570 [details] [diff] [review]
Patch for nsprpub/ and security/  - rev. 2 (checked in)

I've checked in this patch.  The changes will appear in:

NSPR 4.5
NSS 3.8.2
NSS 3.9
Mozilla 1.6 alpha

Comment 53

[Mats Palmgren (inactive)]

Thank you, could you also check in the change for configure.in?
(attachment 84302 [details] [diff] [review] which already has r+ from seawood in comment 20)

Comment 54

[Mats Palmgren (inactive)]

Comment on attachment 84302 [details] [diff] [review]
use gcc -shared on OpenBSD a.out arches where supported

Leaf, could you check this patch in please, it's has review+
from Seawood in comment 20.
It's for *OpenBSD only* and won't affect any other platform.
Thanks.

Comment 55

[Asa Dotzler [:asa]]

*** Bug 177561 has been marked as a duplicate of this bug. ***

Comment 56

[cls]

All of the fixes here have been rolled into bug 236599


*** This bug has been marked as a duplicate of 236599 ***

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this *bug* a duplicate, or is it just one issue that this bug got sidetracked
into that's a duplicate?  I can't really tell.

Comment 58

[cls]

(In reply to comment #57)
> Is this *bug* a duplicate, or is it just one issue that this bug got sidetracked
> into that's a duplicate?  I can't really tell.

In the strictest sense, it's probably not a duplicate.  However, the primary
goal of both bugs was just to get mozilla working on openbsd again and bug
236599 contains all of the patches which were not checked in here and almost all
of them have been checked in now.