firefox 3.0 RC1 can easily deadlock when touching any chrome file while running

Bug #236984 reported by Alexander Sack on 2008-06-03
12
Affects Status Importance Assigned to Milestone
xulrunner-1.9 (Ubuntu)
High
Unassigned
Hardy
High
Unassigned
Intrepid
High
Unassigned

Bug Description

Binary package hint: xulrunner-1.9

quite serious issue in the RC1 packages.

To reproduce:

 1. start firefox
 2. sudo touch /usr/lib/xulrunner-1.9/chrome/*.jar
 3. open menu (edit -> preferences)

result:
  deadlock

expected result:
  should not deadlock

identified reason: debian/patches/bz368428_attachment_308130.patch

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

Could you get a regression range?

Sorry, I was sick.

Scaling worked including version
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008033105 Minefield/3.0pre

It is broken since
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008040106 Minefield/3.0pre

I hope that helps!

In , Kliu (kliu) wrote :

Probably the result of bug 394103

--> Core::GFX/Thebes, I don't think this is a Firefox 3 blocker, but we'll want to fix it in one of the dot-dot updates, probably.

I'm a little worried that this is going to come down to a choice between addressing the concerns of those who filed bug 394103 or this one, though in that case, I think since those running into bug 394103 were hitting it due to kookiness in their Linux configs, this bug is gonna win.

In , Kliu (kliu) wrote :

I had marked bug 424822 as a dependency, as that would allow users to override the behavior added in bug 394103. Alternatively, the new behavior in bug 394103 could be reverted, and bug 424822 could be used to allow Linux users to hack around their problem. Either way, we'll need bug 424822.

I think at this point I'm more about reverting bug 394103, but again, I can wait until after we ship, I think.

Vlad believes that we should #ifdef MOZ_WIDGET_GTK2 the change from bug 394103, since the misrepresentation of DPI appears to be limited to Linux, and that's the conservative play. I have no reason to doubt him.

I guess whiteboard isn't one of the fields that bugzilla lies about in the mid-air message. ;(

Roc: can you implement the fix from comment 8 and put it up for review ASAP? Thanks!

Created an attachment (id=322574)
fix

(From update of attachment 322574)
Sure, add a comment at least referencing this bug number? (Or explaining what's going on, if you understand what the underlying issue is)

You mean something like
   // be more conservative about activating scaling on GTK2, since the dpi
   // information is more likely to be wrong
?

perfect :)

(From update of attachment 322574)
a=beltzner, please land on cvsroot asap

mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp 1.78

...and the comment:
mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp 1.79

Created an attachment (id=322801)
hppa.patch

This should do it(i've tested it)

Alexander Sack (asac) wrote :

Binary package hint: xulrunner-1.9

quite serious issue in the RC1 packages.

To reproduce:

 1. start firefox
 2. sudo touch /usr/lib/xulrunner-1.9/chrome/*.jar
 3. open menu (edit -> preferences)

result:
  deadlock

expected result:
  should not deadlock

identified reason: debian/patches/bz368428_attachment_308130.patch

Alexander Sack (asac) on 2008-06-03
Changed in xulrunner-1.9:
importance: Undecided → High
status: New → Triaged
status: New → Fix Committed
status: Triaged → Fix Committed
importance: Undecided → High
Alexander Sack (asac) wrote :

solution is the update patch debian/patches/bz368428_attachment_308130.patch in the branches.

Martin Pitt (pitti) wrote :

Accepted hardy-proposed upload.

(From update of attachment 322801)
>Index: configure.in
>===================================================================
>- if test "$CPU_ARCH" != "ia64" && test "$CPU_ARCH" != "sparc" \
>+ if test "$CPU_ARCH" != "hppa" && test "$CPU_ARCH" != "ia64" && test "$CPU_ARCH" != "sparc" \
> && test -z "$INTEL_CC"; then
>- # don't use -Wcast-align on ia64 or sparc, it's noisy on those platforms
>+ # don't use -Wcast-align on hppa, ia64 or sparc, it's noisy on those platforms
> # icc doesn't support this flag.
> _WARNINGS_CFLAGS="${_WARNINGS_CFLAGS} -Wcast-align"
> fi

This is getting unwieldy, could you refactor this into a case statement? Same thing with the other bit. Other than that, looks ok.

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in xulrunner-1.9:
status: Fix Committed → Fix Released

Created an attachment (id=324467)
hppa-v2.patch

There we go

Created an attachment (id=324468)
hppa-v3.patch

Wrong patch, this is the good one

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xulrunner-1.9 - 1.9+nobinonly-0ubuntu1

---------------
xulrunner-1.9 (1.9+nobinonly-0ubuntu1) intrepid; urgency=low

  * New upstream release 1.9 (LP: #237690)

  [ Alexander Sack <email address hidden> ]
  * Fix LP: #236266 - "Build Failure on HPPA architecture" by applying patch
    from bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=436133
    - add debian/patches/bz436133_att322801.patch
    - update debian/patches/series
  * drop image scaling patches - previously applied and finally superseeded
    upstream to fix Vista bug https://bugzilla.mozilla.org/show_bug.cgi?id=434157
    - delete debian/patches/bz394103_dont_scale_images.patch
    - delete debian/patches/bz394103_scale_images_for_192+dpi.patch
    - update debian/patches/series
  * update patch for Bug 368428 – "XUL FastLoad cache corruption when
    application running"; fix deadlock by using "antiLockZipGrip".
    (LP: #236984)
    - update debian/patches/bz368428_attachment_308130.patch

  [ Fabien Tassin <email address hidden> ]
  * drop synchronous = NORMAL patch, now applied upstream
    - delete debian/patches/bz421482_att320806_synchronous_NORMAL_for_storage_connections.patch
    - update debian/patches/series
  * Fix regression with venkman accessing chrome by applying patch
    from bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=428848
    - add debian/patches/bz428848_att319775_fix_venkman_chrome_access.patch
    - update debian/patches/series
  * Touch .autoreg in postinst with the exact GRE version as the glob is
    causing troubles when multiple xulrunner are installed
    - update debian/xulrunner-1.9.postinst
    - update debian/xulrunner-1.9-gnome-support.postinst
  * Don't install a libsqlite3.so.0 symlink if we are using system sqlite
    - update debian/rules

 -- Fabien Tassin <email address hidden> Tue, 10 Jun 2008 12:51:56 +0200

Changed in xulrunner-1.9:
status: Fix Committed → Fix Released

Pushed as 15835:101087d57ba5.

this is still an issue on windows xp with 144 dpi. firefox 3.5 worked just great. i upgraded to 3.6.b3 and suddenly the gui collapsed. screenshots with 3.5 and 3.6b3:

http://clip2net.com/page/m0/2714596 (3.6b3) TOO SMALL
http://clip2net.com/page/m0/2714709 (3.5) SLIGHTLY TOO LARGE, BUT IT'S MUCH MORE CONFORTABLE TO THE EYE, working 8 hours a day at 37' from 2 meters distance

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.