Linux mozilla won't run if DISPLAY set to costarica.mcom.com

VERIFIED FIXED

Status

P1
major
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: slogan, Assigned: slogan)

Tracking

Trunk
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

19 years ago
The failure is caused by a call to CopyOffscreenBits() on line 592 of
nsViewManager.cpp. This seems to only happen when DISPLAY is set to costarica,
it won't happen on my Linux box. I determined that in fact it has nothing to do
with costarica being 8-bit. The protocol error that is failing is XCopyArea().
CVS blame shows leaf touched this line last, so I am assigning to him for
comment. Stack crawl is:

#0  0x408bb696 in XCopyArea ()
#1  0x405e7bd5 in ?? () from /usr/lib/libgdk-1.2.so.0
#2  0x40ac398d in nsRenderingContextGTK::CopyOffScreenBits (this=0x82e9a40,
    aSrcSurf=0x82f1970, aSrcX=0, aSrcY=0, aDestBounds=@0xbfffef60,
    aCopyFlags=0) at nsRenderingContextGTK.cpp:1594
#3  0x41437b01 in nsViewManager::Refresh (this=0x82d7ea0, aView=0x82de498,
    aContext=0x82e9a40, rect=0xbfffefc8, aUpdateFlags=1)
    at nsViewManager.cpp:588
#4  0x4143b9f5 in nsViewManager::DispatchEvent (this=0x82d7ea0,
    aEvent=0xbffff0ec, aStatus=@0xbffff00c) at nsViewManager.cpp:1634
#5  0x4142e204 in HandleEvent (aEvent=0xbffff0ec) at nsView.cpp:68
#6  0x4074524b in nsWidget::DispatchEvent (this=0x82de500, aEvent=0xbffff0ec,
    aStatus=@0xbffff0a8) at nsWidget.cpp:1410
#7  0x40744e7c in nsWidget::DispatchWindowEvent (this=0x82de500,
    event=0xbffff0ec) at nsWidget.cpp:1301
#8  0x40749953 in nsWindow::DoPaint (this=0x82de500, aX=0, aY=0, aWidth=101,
    aHeight=101, aClipRegion=0x822bf18) at nsWindow.cpp:330
#9  0x40749a25 in nsWindow::Update (this=0x82de500) at nsWindow.cpp:349
#10 0x4143b34b in nsViewManager::Composite (this=0x82d7ea0)
    at nsViewManager.cpp:1405
#11 0x4143b648 in nsViewManager::UpdateView (this=0x82d7ea0, aView=0x82de498,
    aRect=@0xbffff210, aUpdateFlags=0) at nsViewManager.cpp:1525
#12 0x4143b260 in nsViewManager::ProcessPendingUpdates (this=0x82d7ea0,
    aView=0x82de498) at nsViewManager.cpp:1387
#13 0x4143d4a9 in nsViewManager::EnableRefresh (this=0x82d7ea0)
    at nsViewManager.cpp:2363
#14 0x4108b280 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtml.so
#15 0x4108a78f in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtml.so
#16 0x41089939 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtml.so
#17 0x41334014 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#18 0x41334624 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#19 0x4133161d in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#20 0x41331f36 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#21 0x41330e1a in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#22 0x413308b8 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#23 0x4133eddc in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#24 0x4133ec8c in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#25 0x4133f815 in ?? ()
   from /opt/raptor/ns/dist/bin/components/libraptorhtmlpars.so
#26 0x40ae6b2a in ?? () from /opt/raptor/ns/dist/bin/libraptorwebwidget.so
#27 0x40ae7414 in ?? () from /opt/raptor/ns/dist/bin/libraptorwebwidget.so
#28 0x40552fd2 in ?? () from /opt/raptor/ns/dist/bin/components/libnecko.so
#29 0x4053e8dd in ?? () from /opt/raptor/ns/dist/bin/components/libnecko.so
#30 0x4053e13a in ?? () from /opt/raptor/ns/dist/bin/components/libnecko.so
#31 0x401b036b in ?? () from /opt/raptor/ns/dist/bin/libplds3.so
#32 0x401b027c in ?? () from /opt/raptor/ns/dist/bin/libplds3.so
#33 0x40168399 in ?? () from /opt/raptor/ns/dist/bin/libxpcom.so
#34 0x4072da9c in event_processor_callback (data=0x80a6738, source=7,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:233
#35 0x4072d3af in our_gdk_io_invoke (source=0x82270e8, condition=G_IO_IN,
    data=0x822e700) at nsAppShell.cpp:54
#36 0x40891d6a in ?? () from /usr/lib/libglib-1.2.so.0
#37 0x408932c6 in ?? () from /usr/lib/libglib-1.2.so.0
#38 0x40893801 in ?? () from /usr/lib/libglib-1.2.so.0
#39 0x40893979 in ?? () from /usr/lib/libglib-1.2.so.0
#40 0x407f6f3a in ?? () from /usr/lib/libgtk-1.2.so.0
#41 0x4072e095 in nsAppShell::Run (this=0x80b5d38) at nsAppShell.cpp:404
#42 0x403ae9e1 in ?? () from /opt/raptor/ns/dist/bin/libnsappshell.so
#43 0x804c704 in main1 (argc=1, argv=0xbffffad4) at nsAppRunner.cpp:588
#44 0x804c9a9 in main (argc=1, argv=0xbffffad4) at nsAppRunner.cpp:638
#45 0x402b1cb3 in ?? () from /lib/libc.so.6
(Assignee)

Updated

19 years ago
Severity: normal → major
Priority: P3 → P1

Comment 1

19 years ago
Kevin, I backed out some changes of yours, and syd is getting a crash in the
code i put back in... i backed the changes out because of some memory leaks it
was causing, is it possible for you to do what you had before without the leaks
now?
(Assignee)

Comment 3

19 years ago
Added jdunn at his request to CC list.

Updated

19 years ago
Assignee: leaf → kmcclusk

Comment 5

19 years ago
cvs backout is a red herring, reassigning to kmcclusk
to get the ball rolling again.
(Assignee)

Comment 6

19 years ago
The reports are starting to indicate to me that perhaps this problem only
happens when X server/mozilla are running on separate machines (I have not heard
of it happening when X server/client are on same host). Blizzard: any chance
that shared memory support was whacked about the 15th +/- of November? Or there
is a dependency now on the shared memory extension to execute?
(Assignee)

Comment 7

19 years ago
Eh, jdunn tells me he also sees the problem on HP/UX with display set to :0, and
it has MIT_SHM extension.
I do all of my development from a remote machine so I know it works on remote
displays.  However, I think that some Solaris machines have odd displays in that
the root window is 8 bit and the default window depth is 24.  This might cause a
bad match if the pixmap that it's copying from has a different bit depth than
the target window.
(Assignee)

Comment 9

19 years ago
*** Bug 20347 has been marked as a duplicate of this bug. ***
Can we try a test, real quick?  On your solaris machine ( which I assume is
running the X server ) try doing an xwininfo and clicking on the root window.
On my machine it is listed as have a visual class of "TrueColor."  Then try
clicking on another, normal window.  On my machine it's also "TrueColor."  I
want to see if they are different on the Solaris machine in question.  It might
be a clue.
Assignee: kmcclusk → blizzard
(Assignee)

Comment 11

19 years ago
(gdb) print image_info
$1 = (GdkRgbInfo *) 0x813a958
(gdb) print *image_info
$2 = {visual = 0x80cd4ac, cmap = 0x810d268, color_pixels = 0x0,
  gray_pixels = 0x0, reserved_pixels = 0x0, nred_shades = 6,
  ngreen_shades = 6, nblue_shades = 4, ngray_shades = 24, nreserved = 0,
  bpp = 4, cmap_alloced = 1, gamma = 1, stage_buf = 0x0, gray_cmap = 0x0,
  dith_default = 0, bitmap = 0, own_gc = 0x0,
  conv = 0x4075b29c <gdk_rgb_convert_0888_br>,
  conv_d = 0x4075b29c <gdk_rgb_convert_0888_br>,
  conv_32 = 0x4075c148 <gdk_rgb_convert_32_generic>,
  conv_32_d = 0x4075c1a0 <gdk_rgb_convert_32_generic_d>,
  conv_gray = 0x4075c268 <gdk_rgb_convert_gray_generic>,
  conv_gray_d = 0x4075c2c0 <gdk_rgb_convert_gray_generic_d>,
  conv_indexed = 0x4075c3e0 <gdk_rgb_convert_indexed_generic>,
  conv_indexed_d = 0x4075c43c <gdk_rgb_convert_indexed_generic_d>}
Here's the visual we are playing with:

(gdb) print *image_info->visual
$3 = {type = GDK_VISUAL_TRUE_COLOR, depth = 24, byte_order = GDK_MSB_FIRST,
  colormap_size = 256, bits_per_rgb = 8, red_mask = 16711680, red_shift = 16,
  red_prec = 8, green_mask = 65280, green_shift = 8, green_prec = 8,
  blue_mask = 255, blue_shift = 0, blue_prec = 8}

Breaking in gdk_window_new() we create a 24-bit window.

Later,

#0  gdk_window_new (parent=0x812aa20, attributes=0xbffff4f8,
    attributes_mask=12) at gdkwindow.c:354
#1  0x4062f58c in gdk_superwin_new (parent_window=0x812aa20, x=4294967295,
    y=4294967295, width=1, height=1) at gdksuperwin.c:120
#2  0x4062fee8 in gtk_mozarea_realize (widget=0x8132800) at gtkmozarea.c:86
#3  0x40716e9b in ?? () from /usr/local/lib/libgtk-1.2.so.0
#4  0x406de8ea in ?? () from /usr/local/lib/libgtk-1.2.so.0
#5  0x406dcdbc in ?? () from /usr/local/lib/libgtk-1.2.so.0
#6  0x4070c370 in ?? () from /usr/local/lib/libgtk-1.2.so.0
#7  0x40608243 in ?? () from /opt/raptor/mozilla/dist/bin/libwidget_gtk.so
#8  0x40602149 in ?? () from /opt/raptor/mozilla/dist/bin/libwidget_gtk.so
#9  0x40602340 in ?? () from /opt/raptor/mozilla/dist/bin/libwidget_gtk.so
#10 0x403b2e57 in ?? () from /opt/raptor/mozilla/dist/bin/libnsappshell.so
#11 0x403b1217 in ?? () from /opt/raptor/mozilla/dist/bin/libnsappshell.so
#12 0x403b04fd in ?? () from /opt/raptor/mozilla/dist/bin/libnsappshell.so
#13 0x804c3fb in main1 (argc=1, argv=0xbffffc64) at nsAppRunner.cpp:549
#14 0x804c959 in main (argc=1, argv=0xbffffc64) at nsAppRunner.cpp:638
#15 0x402b3cb3 in ?? () from /lib/libc.so.6

and the window is 8-bit...

Here may be the problem -- throughout mozilla, we call gtk_rgb_get_visual() and
we are getting a 24-bit visual. In gdk_window_new(), the visual is being
obtained by calling gdk_visual_get_system(), which returns 8-bit.
(Assignee)

Comment 12

19 years ago
Here is a patch that fixes the problem:

Index: gdksuperwin.c
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtksuperwin/gdksuperwin.c,v
retrieving revision 1.2
diff -r1.2 gdksuperwin.c
115a116
>   attributes.visual = gdk_rgb_get_visual();
118c119
<   attributes_mask = GDK_WA_X | GDK_WA_Y;
---
>   attributes_mask = GDK_WA_VISUAL | GDK_WA_X | GDK_WA_Y;
(Assignee)

Updated

19 years ago
Assignee: blizzard → syd
Yep.  Looks good to me.  Was just looking at that code myself and came to the
same realization.  r=blizzard

Comment 14

19 years ago
*** Bug 20330 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 15

19 years ago
Marking verified per last comments.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.