Closed Bug 2128 Opened 26 years ago Closed 25 years ago

[PP] Solaris/gtk+: viewer cores on startup

Categories

(Core Graveyard :: Viewer App, defect, P2)

Product:
Core Graveyard
Component:
Viewer App
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: slamm, Assigned: mcafee)

References

Details

Built with gcc 2.7.2.1. Both with and with out pthreads gives the same stack
trace.

#0  0x0 in _DYNAMIC ()
#1  0xeed60448 in gdk_im_open () at gdkim.c:383
#2  0xeed4b338 in gdk_init (argc=0xeed88e48, argv=0xeed8b094) at gdk.c:417
#3  0xeec469e8 in gtk_init (argc=0xeffff390, argv=0xeffff324) at gtkmain.c:196
#4  0xef715670 in nsAppShell::Create (this=0x8fb60, argc=0xeffff390,
    argv=0xeffff424) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:54
#5  0x29b10 in nsViewerApp::Initialize (this=0x8ecb0, argc=1, argv=0xeffff424)
    at ../../../../mozilla/webshell/tests/viewer/nsViewerApp.cpp:188
#6  0x1fc48 in main (argc=1, argv=0xeffff424)
    at ../../../../mozilla/webshell/tests/viewer/nsGTKMain.cpp:126
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
If you run the testgtk program that comes with the gtk distribution, you'll
notice that this is actually a gtk bug.  Configure and compile gtk with
"--enable-xim=no" as a workaround.
Status: RESOLVED → REOPENED
Summary: [PP] Solaris: viewer cores on startup → [PP] Solaris/gtk+: viewer cores on startup
Bugzilla should track gtk+ bugs on which gecko is dependant. Do not close this
because it is only a gtk+ bug.

Can we make an autoconf test for gtk+ that sets the "--enable-xim" as
appropriate?

Reopening bug.
Resolution: INVALID → ---
gtk developers are looking into the problem.  Mail from owen@redhat.com:

Recently a number of people have been reporting difficulty
with the call to XRegisterIMInstantiateCallback() added to
GDK recently.

The idea of using this call is that a GTK+ application might
be started at the same time as the XIM server, and so the IM
might not be available when the app starts up, but would be
available later.

For GTK+, this often does no good, since entries created
between the time that GDK was initialized and the time that
the IM starts up will not be created with input contexts and
won't get them later either. I don't see any way of fixing
this without major changes to the way that GDK input
contexts, because we the Entry needs to be able to get
information about the details of the input context created.

Now, this in itself wouldn't be a reason to remove the call,
but XRegisterIMInstantiateCallback() seems to be a
portability problem - it doesn't exist under X11R5, while
without it, the old XIM stuff worked, I think, on at least
some X11R5 platforms.

And, also, on Solaris under X11R6, XRegisterIMInstantiateCallback()
apparently coredumps. It's possible this is a symptom
of something that GDK is doing wrong, but it's not
obvious to me from the documentation what this is.

But I'm not sure if there isn't some reason why this
is really necessary. If so, it might be worth trying
to figure out what is going wrong on Solaris, and
conditionally using it on non-X11R5 platforms.

Other thoughts?
                                        Owen
Assignee: rickg → slamm
Status: REOPENED → NEW
Reassigning to me. I will take a closer look. I may need to use a different
compiler.
Status: NEW → ASSIGNED
Building with egcs-2.91.57 produces a viewer comparable to the Linux build.
solaris 2.6, egcc 2.91.57, similar problem when using gtk 1.1.12 and 1.1.13, gtk
1.1.6 was fine.
Brad, try configuring glib/gtk with "--enable-xim=no". I was able to build and
run well with 1.1.12. I am trying 1.1.13 now.
Yes.. I saw that and it does work.. assuming that xim is definitly not needed.
I mostly wanted to indicate that egcs wasn't the solution to this.. its still a
gtk xim problem on solaris
Inserting Milestone info.
Setting all current Open Critical and Major to M3
The problem with XIM no longer exists as of at least gtk+-1.1.15.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Target Milestone: M3 → M4
Changed target milestone to M4.

Steve, the component for this bug is the Viewer.  This also happens with
Apprunner, doesn't it?  Should we change the component?
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
I far as I know, this is working now.
Mcafee may know more.
Status: RESOLVED → REOPENED
Assigning to mcafee per his request.
Assignee: slamm → mcafee
Status: REOPENED → NEW
Resolution: FIXED → ---
So, mcafee, is this Fixed?
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
this was fixed by upstream gtk changes.
*** Bug 2591 has been marked as a duplicate of this bug. ***
slamm, could you mark Verified please if your cool with this now?
Status: RESOLVED → VERIFIED
I just built and ran fine on Solaris, yeah i think this is fixed.
Yeah, what he said.

I am having problems building on Solaris right now, but I think it is a problem
with my linker stet up.
This only appears on my 2.6 systems if I compile with egcs 1.1.2.  The sun cc
compiler works.
This bug is way-fixed.  Jody if you have another problem,
post to mozilla.unix and ask for help, or file another bug.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.