Cookies don't work on custom-compiled Mozilla (as well as Phoenix)

RESOLVED INVALID

Status

()

Core
XPCOM
RESOLVED INVALID
15 years ago
15 years ago

People

(Reporter: Raja Harinath, Assigned: dougt)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030512 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030512 Mozilla Firebird/0.6

I compile Phoenix daily of the CVS.  I have been unable to use cookies for the
past couple of weeks.  I am using GCC 3.4, if that matters.

* The 'Enable Cookies' checkbox doesn't seem to be working.  I uncheck it, and
the next time I open the "Options" dialog, it is checked again.
* Sites complain that cookies are disabled even though the checkbox is enabled.
* The 'cookies.txt' file is untouched.
* None of my saved cookies from before work.

The closest clue I have is that a debug build shows:

  chrome://browser/content/pref/pref-privacy.js line 15:
Components.classes['@mozilla.org/cookiemanager;1'] has no properties

suggesting that somehow that extension is not being registered.

Reproducible: Always

Steps to Reproduce:

Comment 1

15 years ago
what configure options do you use?  cookies are built as an extension.
(Reporter)

Comment 2

15 years ago
Here's my .mozconfig:

---8<---
MOZ_PHOENIX=1
export MOZ_PHOENIX
mk_add_options MOZ_PHOENIX=1

MOZ_INTERNAL_LIBART_LGPL=1
export MOZ_INTERNAL_LIBART_LGPL
mk_add_options MOZ_INTERNAL_LIBART_LGPL=1

ac_add_options --disable-composer
ac_add_options --disable-ldap
ac_add_options --disable-mailnews
ac_add_options --disable-tests
ac_add_options --enable-crypto
ac_add_options --enable-extensions=default,-irc,-content-packs,-help
ac_add_options --enable-plaintext-editor-only
ac_add_options --enable-svg
ac_add_options --prefix=$HOME
ac_add_options --enable-optimize='-g -O2'
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
---8<---

Comment 3

15 years ago
-> phoenix
Assignee: darin → blaker
Component: Cookies → Preferences
Product: Browser → Phoenix
QA Contact: cookieqa → asa
Version: Trunk → unspecified
(Reporter)

Comment 4

15 years ago
I rebuilt it with the 'cview' extension, and viewed

  chrome://cview/content

Sure enough, the only "cookie" like component was "cookieconsent" or something
like that.

I have a cookies.xpt file in dist/bin/components, and an xpt_dump on it does
seem complete.  A 'strings' on libcookie.so does list

  @mozilla.org/cookiemanager;1

Comment 5

15 years ago
Does this happen if you compile mozilla with gcc 3.4 also?

I just fixed a compilation error on gcc3.4 with the cookie lib, see bug 201407.
Maybe the library did not compile/link correctly when you built?
(Reporter)

Comment 6

15 years ago
I'm reasonably sure it wasn't bug 201407: after all, I submitted that bug, and
wrote the first few revisions of that patch :-)
(Reporter)

Comment 7

15 years ago
I compiled Mozilla too with GCC 3.4.  I got the same problem.  

Component viewer listed a contract ID of '@mozilla.org/cookie-Service;1', but it
didn't have a valid class ID, it appears.  '@mozilla.org/cookiemanager;1' wasn't
to be seen.

The console log has:

  JavaScript error: 
  chrome://cookie/content/cookieNavigatorOverlay.xul line 62:
Components.classes['@mozilla.org/permissionmanager;1'] has no properties

  JavaScript error:
  chrome://communicator/content/wallet/CookieViewer.js line 61:
Components.classes['@mozilla.org/cookiemanager;1'] has no properties

  JavaScript error: 
  chrome://communicator/content/wallet/CookieViewer.js line 128:
kObserverService has no properties
Summary: Cookies don't work on custom-compiled Phoenix → Cookies don't work on custom-compiled Mozilla (as well as Phoenix)
(Reporter)

Comment 8

15 years ago
Here's why.

  1024[8057d08]: nsNativeComponentLoader: SelfRegisterDll(libcookie.so) Load
FAILED with
error:/scratch/mmdbms01/users/harinath/misc/src/mozilla/build/linux/dist/bin/components/libcookie.so:
undefined symbol: 
  nsTHashtable<nsHostEntry>::s_GetKey(PLDHashTable*, PLDHashEntryHdr*)
  1024[8057d08]: nsNativeComponentLoader: Autoregistration FAILED for
"libcookie.so". Skipping...
Component: Preferences → XPCOM
Product: Phoenix → Browser
Version: unspecified → Trunk
(Reporter)

Comment 9

15 years ago
Created attachment 123374 [details] [diff] [review]
explicitly instantiate nsTHashtable<nsHostEntry> template

This seems to be the cleanest solution.  Maybe, we could default to using
'-frepo'  with GCC.

This may have to do with inlining limits, since these symptoms don't seem to
have been reported with older GCCs.  Or, it may be a bona fide GCC 3.4
regression/bug.

Comment 10

15 years ago
I would prefer to avoid explicit instantiation if possible... it leads down a
dark and dangerous road.

I tried building mozilla with a self-build gcc 3.4 from a CVS tarball, but had
all sorts of errors with the configure script and other places... I don't think
I know how to do it correctly without installing into /usr/local which I don't
want to do.

Can you run "nm" on nsPermissionManager.o and libcookie.so and send me the
results, or attach them here?
Assignee: blaker → dougt
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: asa → scc

Comment 11

15 years ago
One other thought: note that I am only taking the address of the s_GetKey
function; I am never calling this function directly (it gets called by pldhash
through the sOps structure).

Perhaps GCC is not properly instantiating the function because it appears that I
never call it? The only time I use it is in a static data initialization...
(Reporter)

Comment 12

15 years ago
I compiled nsPermissionManager w/o the patch using GCC 3.2.  It worked OK.
Seems to be a GCC 3.4 regression.  I'll try to submit it there.

(I can still send you the 'nm' output if you're interested.  Drop me an e-mail).
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.