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

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.

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.

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

Reassigning to me. I will take a closer look. I may need to use a different compiler.

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

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?

I far as I know, this is working now. Mcafee may know more.

Assigning to mcafee per his request.

So, mcafee, is this 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?

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.