728500 - xulrunner 10.0.2 segfault under pyxpcom / hulahop

Status: RESOLVED DUPLICATE of bug 678977

(Core :: General, defect)

Description

[lkcl]

Attachment: typescript

User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110430 Iceweasel/3.5.9 (like Firefox/3.5.9)
Build ID: 20100414091236

Steps to reproduce:

installed xulrunner 10.0.1-1 under debian/amd64.  compiled python-hulahop.  installed it. installed pyjamas-desktop.  ran demo application.


Actual results:

segfault (attached stacktrace)

Comment 1

[lkcl]

the exact same code (python-hulahop) worked successfully *without* segfaults, for
version xulrunner-9.0.1-1.  which was kinda nice.  james asked me to help get things
up to xulrunner-10 which is the latest in debian, and that's where the problem is.

bugreport linked here for completeness:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660178

Comment 2

[Josh Matthews [:jdm]]

The crash here is occurring in the startup of the storage service. I'm inclined to believe that jemalloc interactions might be the problem here, given my limited understanding of the interactions of the SDK and python-hulahop. Justin/Nick, does a NULL dereference in or around sqliteMemRoundup ring any bells? lckl, what happens if you build the SDK with --disable-jemalloc?

Comment 3

[lkcl]

ok, i tried building xulrunner-13.0a1 (latest trunk) from the mozilla central git and oops, after 12 hours whoopsie there are errors building pyxpcom, unrecognised type "PRBool".

so i'm now setting off err i _was_ going to set off with this:
https://github.com/harthur/mozilla-central/tree/2f748c31792d2d640e263d87eeaae1ae73519d60

but have run smack into this:

/home/lkcl/oe/src/gecko/obj-x86_64-unknown-linux-gnu/config/nsinstall -R -m 644 /home/lkcl/oe/src/gecko/xpcom/proxy/public/nsProxiedService.h ../../../dist/include
nsIProxyObjectManager.idl
/usr/bin/python2.7 /home/lkcl/oe/src/gecko/config/pythonpath.py \
          -I/home/lkcl/oe/src/gecko/other-licenses/ply \
          -I/home/lkcl/oe/src/gecko/xpcom/idl-parser \
          /home/lkcl/oe/src/gecko/xpcom/idl-parser/header.py --cachedir=/home/lkcl/oe/src/gecko/xpcom/idl-parser -I/home/lkcl/oe/src/gecko/xpcom/proxy/public -I../../../dist/idl /home/lkcl/oe/src/gecko/xpcom/proxy/public/nsIProxyObjectManager.idl -d .deps/nsIProxyObjectManager.h.pp -o _xpidlgen/nsIProxyObjectManager.h
Traceback (most recent call last):
  File "/home/lkcl/oe/src/gecko/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/lkcl/oe/src/gecko/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/lkcl/oe/src/gecko/xpcom/idl-parser/header.py", line 509, in <module>
    outfd = open(options.outfile, 'w')
IOError: [Errno 2] No such file or directory: '_xpidlgen/nsIProxyObjectManager.h'
make[7]: *** [_xpidlgen/nsIProxyObjectManager.h] Error 1


*sigh*.  is there a particular commit revision that is adviseable to use?  i'm having
a hard time finding information that documents exactly which releases are which.  lots
of information about APIs (too much in fact!)  lots of information about how to
download and where to download pre-built releases.  absolutely zero information on
the relationship between tags, releases, versions of xulrunner, etc. etc.

Comment 4

[lkcl]

whilst continuing to search for information, i'm going to try with this tag:
git checkout UPDATE_PACKAGING_R10

clues really appreciated! :)

Comment 5

[lkcl]

darn it!  config/milestone.txt has this, for UPDATE_PACKAGING_R10:
1.9.3a4pre

so that's completely wrongggg.... *floundering*

Comment 6

[lkcl]

ok, after grepping the source code for version numbers, turns out that config/milestone.txt
has the version number.  tracking that file shows revisions in which that file has been
modified, here:
http://hg.mozilla.org/mozilla-central/rev/aba2ac9fe16a

pending further advice i'm picking the version that has the log message as follows:
commit 8b14d3beea8634e9123515a841a02faec0ad821c
Author: Christian Legnitto <[e-mail]>
Date:   Tue Dec 20 09:24:38 2011 -0800

    Bug 700000 - Version bump


build underway with that specific version....

Comment 7

[lkcl]

make[6]: Entering directory `/home/lkcl/oe/src/gecko/obj-x86_64-unknown-linux-gnu/xpcom/base'
mkdir -p /home/lkcl/oe/src/gecko/obj-x86_64-unknown-linux-gnu/xpcom/base/.deps
/home/lkcl/oe/src/gecko/obj-x86_64-unknown-linux-gnu/config/nsinstall -R -m 644 /home/lkcl/oe/src/gecko/xpcom/base/nsAgg.h /home/lkcl/oe/src/gecko/xpcom/base/nsAutoRef.h /home/lkcl/oe/src/gecko/xpcom/base/nsCom.h /home/lkcl/oe/src/gecko/xpcom/base/nsDebugImpl.h /home/lkcl/oe/src/gecko/xpcom/base/nsIAllocator.h /home/lkcl/oe/src/gecko/xpcom/base/nsIID.h /home/lkcl/oe/src/gecko/xpcom/base/nsISupportsObsolete.h /home/lkcl/oe/src/gecko/xpcom/base/nsStackWalk.h /home/lkcl/oe/src/gecko/xpcom/base/nsTraceRefcntImpl.h /home/lkcl/oe/src/gecko/xpcom/base/nsWeakPtr.h /home/lkcl/oe/src/gecko/xpcom/base/nsInterfaceRequestorAgg.h /home/lkcl/oe/src/gecko/xpcom/base/dmd.h /home/lkcl/oe/src/gecko/xpcom/base/nsAutoPtr.h /home/lkcl/oe/src/gecko/xpcom/base/nsError.h /home/lkcl/oe/src/gecko/xpcom/base/nsISupportsBase.h /home/lkcl/oe/src/gecko/xpcom/base/nscore.h /home/lkcl/oe/src/gecko/xpcom/base/nsAtomicRefcnt.h /home/lkcl/oe/src/gecko/xpcom/base/nsCycleCollector.h /home/lkcl/oe/src/gecko/xpcom/base/nsObjCExceptions.h ../../dist/include
/home/lkcl/oe/src/gecko/obj-x86_64-unknown-linux-gnu/config/nsinstall -R -m 644 /home/lkcl/oe/src/gecko/xpcom/base/FunctionTimer.h /home/lkcl/oe/src/gecko/xpcom/base/MapsMemoryReporter.h /home/lkcl/oe/src/gecko/xpcom/base/ClearOnShutdown.h /home/lkcl/oe/src/gecko/xpcom/base/AvailableMemoryTracker.h ../../dist/include/mozilla
nsIConsoleListener.idl
/usr/bin/python2.7 /home/lkcl/oe/src/gecko/config/pythonpath.py \
          -I/home/lkcl/oe/src/gecko/other-licenses/ply \
          -I/home/lkcl/oe/src/gecko/xpcom/idl-parser \
          /home/lkcl/oe/src/gecko/xpcom/idl-parser/header.py --cachedir=../../xpcom/idl-parser -I/home/lkcl/oe/src/gecko/xpcom/base -I../../dist/idl /home/lkcl/oe/src/gecko/xpcom/base/nsIConsoleListener.idl -d .deps/nsIConsoleListener.h.pp -o _xpidlgen/nsIConsoleListener.h
Traceback (most recent call last):
  File "/home/lkcl/oe/src/gecko/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/home/lkcl/oe/src/gecko/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/home/lkcl/oe/src/gecko/xpcom/idl-parser/header.py", line 516, in <module>
    outfd = open(options.outfile, 'w')
IOError: [Errno 2] No such file or directory: '_xpidlgen/nsIConsoleListener.h'
make[6]: *** [_xpidlgen/nsIConsoleListener.h] Error 1


nnope - same error.  bizarre! ... did this stuff ever work?? :)

Comment 8

[lkcl]

all right, i gave up and used debian's upstream 10.0.1 release :)
i'm back on track.

Comment 9

[lkcl]

ok yes!  that did the trick - confirmed, after a _lot_ of arseing about :)

compiling with --disable-jemalloc, this was 10.0.2 directly from debian,
which was directly from the "releases", that yes, the startup segfault is gone.

howeverrrr.... unnnnfortunately, there's _another_ error, whoops!  this one
occurs on a mouse event.  it's hard to tell if it's a mouse-move or a mouse-enter.

will raise a separate bugreport for that one because it's nothing to do with
this bug.

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Josh Matthews [:jdm] from comment #2)
> The crash here is occurring in the startup of the storage service. I'm
> inclined to believe that jemalloc interactions might be the problem here,
> given my limited understanding of the interactions of the SDK and
> python-hulahop. Justin/Nick, does a NULL dereference in or around
> sqliteMemRoundup ring any bells? lckl, what happens if you build the SDK
> with --disable-jemalloc?

The problem here is that je_malloc_usable_size_in_advance is a weak symbol and is not present when this code runs.  I think this can happen with a libxul.so built with --enable-jemalloc and an application binary built without --enable-jemalloc.  (I seem to remember njn having a similar problem with xpcshell).

I don't know enough about how XULRunner works to know whether the bug is in XULRunner or lkcl's code.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Also the set of comments starting at https://bugzilla.mozilla.org/show_bug.cgi?id=678977#c46 may be relevant.

Comment 12

[lkcl]

kyle thank you for the reference to a potential resolution of this issue, but please do not refer to *any* code as being "owned by a person".

not only is this in direct contravention of the fundamental tenet of good software programming practice known as "egoless programming" which is *especially* relevant in sofware (libre) development but also you are factually completely wrong about the fact that, even if you take away the implied ego and implied "ownership" and substitute "responsibility for the project known as hulahop", i am not the project manager, leader, nor in fact have anything to do with, the project known as hulahop.

i do not know you, so i have no idea how old you are, how long you have been programming, but the fact that you have a mozilla.com email address tends to indicate that you have certain weight and responsibilities which the mozilla foundation should have made you aware of: if the mozilla foundation is *deliberately* promoting the concept that all mozilla employees should consider code to be *personally owned*, and should view all code external to the mozilla foundation as *also* personally owned then that reflects extremely badly on the mozilla foundation.

successful shared goals have *nothing* to do with the people involved *in* those goals.  the person - the people - *must not* be confused with the goal.

bottom line: don't _ever_ use personal pronouns to refer to code that people have developed.  use "the code that person x is talking about", or "the project that person x is talking about".  better yet don't even mention the person's name *at all* unless it is unavoidable for the sake of disambiguation.

thanks.

Comment 13

[lkcl]

thank you to kyle for pointing out the bugreport 678977 - the stacktrace shown in this bugreport looks pretty much identical to the one shown here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=678977#c46

and that the issue appears also to have been resolved, there.  that just leaves getting those patches upstream and i assume that that has been done, such that xulrunner 10.0.3 or above, or xulrunner 11 will have the required fixes.  as this adversely affects debian's packaging, the relevant debian bugreport will be updated so that they may choose what action to take.

Comment 14

[Nicholas Nethercote [inactive]]

> bottom line: don't _ever_ use personal pronouns to refer to code that people
> have developed.

I think you're tilting at windmills on that one.

Comment 15

[lkcl]

charrrrrge!

*cackle*

... but seriously, would you use a phrase "your line of code"?  it's an alarm-bell for me, when people say "your code", "your project", "your patch".

my favourite one was someone - a developer in webkit - who knew exactly what they were doing (as part of a bullying campaign), when they used the phrase "your pet project" as a denigrating term which allowed them to justify refusal of patches (that were later accepted when presented by other people, in pretty much exactly the same form).

so i am very _very_ wary when people start saying "your" code.  "your" project.  it makes me extremely uncomfortable.  i don't have a piece of code physically attached to my body for goodness sake - not even as a tattoo!

:)