Closed Bug 20153 Opened 25 years ago Closed 25 years ago

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

Categories

(Core Graveyard :: GFX, defect, P1)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: slogan, Assigned: slogan)

References

Details

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
Severity: normal → major
Priority: P3 → P1
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?
Added jdunn at his request to CC list.
Assignee: leaf → kmcclusk
cvs backout is a red herring, reassigning to kmcclusk
to get the ball rolling again.
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?
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.
*** 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
(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.
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: blizzard → syd
Yep.  Looks good to me.  Was just looking at that code myself and came to the
same realization.  r=blizzard
*** Bug 20330 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.