394214 - using nsTArray<T> breaks linking if debug is on

Status: RESOLVED DUPLICATE of bug 387584

(Core :: XPCOM, defect)

Description

[Sergey Yanovich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070723 Iceweasel/2.0.0.6 (Debian-2.0.0.6-1)
Build Identifier: hg 64d9dbec8991 (2007-08-29)

An attempt to use nsTArray in a xul-app/extension with debugging on will cause an error at link stage if xulrunner is built w/ --disable-debug:

symbol lookup error: /path/to/lib: undefined symbol: _ZN13nsTArray_baseC2Ev

Reproducible: Always

Steps to Reproduce:
1. build and install a nightly XR w/ --disable-debug
2. #include "nsTArray.h"
3. $(CC) $FLAGS -DDEBUG somefile.cpp
Actual Results:  
symbol lookup error: /path/to/lib: undefined symbol: _ZN13nsTArray_baseC2Ev

Expected Results:  
somefile lib

'nsTArray_base' constructor has two variant depending on the value of NS_BUILD_REFCNT_LOG macro, which is switched on/off by DEBUG macro. Non-debug version is in-line, and debug version is not. As a result, if XR is built as normally with --disable-debug, an in-line version is used and 'xpcomglue' library doesn't contain a constructor for 'nsTArray_base'.

When later someone tries do switch debugging on, 'nsTArray' clients begin to search for the constructor that does not exist.

Comment 1

[Benjamin Smedberg]

What you want is a debug version of the xpcom glue library. I believe that if you link your debug component against a debug glue, it will run correctly on a release XR.

I don't think we're going to be in the business of releasing debug xpcom glue libraries though... you'll have to compile your own.

Comment 2

[Sergey Yanovich]

Attachment: always use in-line constructor/destructor

Moving constructor/destructor code to class declaration fixes this bug. Clients that what debugging will now log refcnt info in their bodies.

In cases when --disable-debug is used, there is no change of behavior, since MOZ_COUNT_* are no-op.

Comment 3

[Sergey Yanovich]

(In reply to comment #1)
> I don't think we're going to be in the business of releasing debug xpcom glue
> libraries though... you'll have to compile your own.

Well, you post a comment faster than I typed a description for the patch. That is impressive :)

Comment 4

[Benjamin Smedberg]

see also bug 387584 which I think will fix this particular issue the other way round (always outlining).

Comment 5

[Sergey Yanovich]

(In reply to comment #4)
> see also bug 387584 which I think will fix this particular issue the other way
> round (always outlining).
> 
Right. That is exactly the same issue. My fault.