Comment 1 Natsuki Miyamoto 2006-03-20 01:41:38 EST

Created attachment 36585 [details]
Screen capture to show the operation and error message

Comment 2 Natsuki Miyamoto 2006-03-20 01:46:41 EST

Created attachment 36586 [details]
Log and trace files when getting the error with IBM Java

This ZIP file includes 
- ivmjava_core.log : The information displayed in console log
- javacore.20060320.142259.20057.txt : java core file in text format- Snap0001.20060320.142259.20057.trc : Trace file

I didn't package the core dump file in this zip, since it is too big to attach. 
If you need that file, please let me know. I can send you the file : 
  Core.20060320.142259.20057.dmp (471MB)

Comment 3 Natsuki Miyamoto 2006-03-20 01:48:19 EST

Created attachment 36587 [details]
Error log file when having this problem with Sun JRE 1.5

Comment 4 Chris Brealey 2006-03-24 10:16:28 EST

Miyamoto-san,
just to confirm, it's the RHEL4 operating system together with the embedded browser in Eclipse that yields this problem, correct? Do you know if the problem occurs on RHEL configured with the en_US locale, or does the locale appear to be a factor as well? Could you also try accessing a different UDDI registry, such as XMethods, to see if the same problem occurs?

I'm not sure where to go with this, but if the problem only happens on RHEL4, then I have to suspect something is amiss deep within the JRE(s). They should never core dump.

Kathy,
would you please hunt down a RHEL4 system and see if you can reproduce this? If you can, let's try to determine what line of code in the WSE is being executed when the core dump happens. Based on the visible symptom and stack traces in the core dump, I'm a bit suspicious of a socket-level explosion at the point the SAP registry responds to the WSE, though this is a totally wild guess on my part.

Comment 5 Natsuki Miyamoto 2006-03-30 00:36:30 EST

Hello, Sorry for the delay of my confirmation. 

My system is RHEL V4 U3
and I confirmed this problem with the following locales : 
- Ja_JP.UTF-8
- en_US.ISO-8859-1
- en_US.UTF-8
So, I suspect this problem would not be sensitive with the locale information.

I tried several UDDI registry and confirmed this problem occurred for all following registry: 
 - SAP UDDI Test Registry
 - SAP UDDI Registry
 - XMethods Registry
 - NTT Communications Registry
So, I suspect this problem would not be sensitive with the type of UDDI Registry.
I confirmed this problem with both JRE 1.5 and JRE 1.4.2, so this is not sensitive with JRE level. 
 - IBM J2RE 1.4.2 IBM Build cxia32i42ifx 20060209 (SR4-1)
 - IBM J2RE 1.5.0 IBM Linux build pxi32dev 20060222 (SR1)

The problem occured when using the following browser internally, 
   - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060130 
     Red Hat/1.0.7-1.4.3 Firefox/1.0.7:,
and I confirmed that the problem didn't occur with the following external 
browsers. 
   - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060130 
     Red Hat/1.0.7-1.4.3 Firefox/1.0.7
   - Mozilla/5.0 (X11; U; Linux i686; en_US; rv:1.8.0.1) Gecko/20060124 
     Firefox/1.5.0.1
Therefore, it looks like the problem is related with the internal/external of eclipse, and the browser version seems not sensitive this problem. 

If you need the further information, please let me know. 

Comment 6 Kathy Chan 2006-03-30 18:12:43 EST

Since this problem only occurs with the Eclipse internal browser and not the external browser, it is very likely that this is an Eclipse internal browser problem.  Please reassign if platform.ui is not the right component.

Comment 7 Eric Moffatt 2006-03-31 09:57:02 EST

Could you folks check this out to determine whether the issue is inside the 'internal browser'?

Thanks

(feel free to punt back if you think there's a better location for this.

Comment 8 Cam-Thu Le 2006-04-03 11:49:41 EDT

This bug has been identified as a major bug by the enablement
testers. If at all possible, please find a fix or workaround asap because the
testers need to verify the fix (or finish the test) by Fri Apr 7.  

Comment 9 Curtis d'Entremont 2006-04-03 12:03:00 EDT

Seems to be crashing at:
at org/eclipse/swt/internal/gtk/OS._g_main_context_iteration(Native Method)

SWT, could you take a look?

Comment 10 Karice McIntyre 2006-04-07 13:23:21 EDT

This bug is on IES's list of critical bugs.  What's the status of this one?

Comment 11 Karice McIntyre 2006-04-07 13:32:23 EDT

This is a pretty easy fix.  All you need to do is override IWorkbenchPartOrientation#getOrientation() 
to 
return SWT.LEFT_TO_RIGHT 
for the editor part class the implements the compare editor (is it the CompareEditor class).  Can someone please look at this bug?

Comment 12 Karice McIntyre 2006-04-07 13:34:32 EDT

Sorry, that last comment was supposed to go into another bug. <blush>

Comment 13 Grant Gayed 2006-04-07 14:52:32 EDT

I cannot reproduce the crash.  My setup is:

- RHEL 4 running with locale ja_JP.UTF8
- mozilla 1.7.12
- wtp-sdk-I-I200603100726-200603100726.zip and its stated dependencies, except:
  -> eclipse 0307 is no longer available, so I used eclipse 3.2M6 instead (0330)

I'll revisit this issue next week.

Comment 14 Natsuki Miyamoto 2006-04-10 03:05:35 EDT

We tried this on several different machines, and confirmed that the problem can be recreatabla on all systems. 

Here is the additional findings : 
- The default browser for RHEL 4.3 with the typical/minimum installation is   
  Firefox. Then, the problem can be recretable easily. 
- When using the old RHEL (such as RHEL 4.1) or RHEL 4.3 full installation,  
  then the system use Mozilla as the default browser. Then the problem is not   
  recretable. However, once setting Firefox as the default by 
  modifying /et/gre.d/gre.conf, then the problem occurred. 

Comparison : 
                  | Typical installation   |   Full installation
------------------+------------------------+---------------------
Def browser       |  Firefox 1.0.7         | Mozilla 1.7.12
------------------+------------------------+---------------------
/etc/gre.d        |  no this directory     | directory exists.
                  |  available in the sys  |
------------------+------------------------+---------------------
To recreate this  |      (as-is)           | Modify GRE_PATH in gre.conf
problem           |                        | from mozilla lib to firefox lib.
------------------+------------------------+---------------------

** Default browser for Eclipse is clarified with java.library.path 
   in the information of Help > About Eclipse SDK > Configuration Details

Comment 15 Masayuki Fuse 2006-04-17 03:14:56 EDT

I've updated FireFox to 1.0.8 by the RedHat Network and confirmed that had the same crash problem.

Comment 16 Grant Gayed 2006-04-17 14:00:14 EDT

Ok, I can reproduce this crash now.  Investigating...

Comment 17 Grant Gayed 2006-04-21 09:33:01 EDT

Just to update, I spent time looking at this earlier in the week and could not determine the problem.  I will revisit this next week, before RC2.

Comment 18 Karice McIntyre 2006-04-25 14:30:40 EDT

Grant, what's the status of this one?  Is it possible to fix this for RC2 or RC3?  

Comment 19 Grant Gayed 2006-04-25 14:48:09 EDT

I will be looking at this again tomorrow.  This is currently my highest priority bug, but in my initial investigation I could not determine what the problem was.

Comment 20 Karice McIntyre 2006-04-25 15:05:25 EDT

Great - thanks, Grant! :)

Comment 21 Karice McIntyre 2006-05-01 18:29:46 EDT

Will this be fixed for RC3? 

Comment 22 Grant Gayed 2006-05-02 15:49:47 EDT

Yikes, this appears to be happening as a result of the Browser not using profiles.  This is a pretty large fix to attempt at this stage of development.  Am talking to team leads to determine what to do here.

Comment 23 Grant Gayed 2006-05-03 17:33:30 EDT

This won't be in for RC3.  I'm still looking into the fix, but statically linking to mozilla's profiles library is giving us problems.

Comment 24 Benjamin Smedberg (mozilla) 2006-05-06 14:33:34 EDT

You don't need to do static linking, you could just import the sources from mozilla/profile/dirserviceprovider into your source tree and build them from there.

Comment 25 Grant Gayed 2006-05-11 11:41:14 EDT

We have confirmed that using a profile does make this crash stop happening.  However the nature of this change is quite large to make at this stage in the 3.2 cycle, so we are planning to make this fix in 3.3 and will strongly consider it for 3.2.1, assuming that it proves to work well in the meantime.

Comment 26 David Williams 2006-05-17 16:06:30 EDT

(In reply to comment #25)
> We have confirmed that using a profile does make this crash stop happening. 
> However the nature of this change is quite large to make at this stage in the
> 3.2 cycle, so we are planning to make this fix in 3.3 and will strongly
> consider it for 3.2.1, assuming that it proves to work well in the meantime.
> 

You say "works well in the meantime". Can you make a patch available here? 
To see if it prevents, for example, bug 142320? 

Comment 27 Chris Brealey 2006-05-18 10:47:27 EDT

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

Comment 28 Grant Gayed 2006-05-18 12:34:38 EDT

Created attachment 41905 [details]
org.eclipse.swt project patch

To use the fix apply this patch to the org.eclipse.swt project, and substite the mozilla library attached in the next comment into your org.eclipse.swt.gtk.linux.x86 project.

Note that this library was compiled on my RHEL4 machine against firefox, so it requires:
- libstdc++.so.6 to be present (ie.- may not be on RHEL3)
- 32 bit, not 64
- firefox (also seems to work on mozilla >= 1.7)

Comment 29 Grant Gayed 2006-05-18 12:36:09 EDT

Created attachment 41906 [details]
new swt mozilla library

substite -> substitute <g>

Comment 30 Peter Clemons 2006-05-24 19:38:16 EDT

(In reply to comment #28)
> To use the fix apply this patch to the org.eclipse.swt project

Hmmm.  I clicked on the patch link, but don't know what to do with the result.  It's just a "diff" display.  Copying the new library provided in comment #29 over my own was easy enough.  But I'm a bit stumped as to how to "apply this patch to the org.eclipse.swt project".

Also, as far as comment #29 goes, I found the .so in my eclipse\configuration\org.eclipse.osgl\bundles\96\1\.cp directory.  Is that the same as the "org.eclipse.swt.gtk.linux.x86 project"?

Comment 31 Grant Gayed 2006-05-25 10:58:48 EDT

steps:
- make a CVS connection to Host: dev.eclipse.org Path: /home/eclipse (if you don't have a dev.eclipse.org account then you can use User: anonymous Password: <leaveItBlank> Type: pserver)
- retrieve the org.eclipse.swt and org.eclipse.swt.gtk.linux.x86 projects from HEAD into your workspace
- in the Navigator view rename org.eclipse.swt's .classpath_gtk file to .classpath
- apply the attached patch to the org.eclipse.swt project
- put the attached library into the org.eclipse.swt.gtk.linux.x86 project
- to use the changes, either run an app whose build path includes the swt in your workspace, or alternatively run eclipse self-hosted

Comment 32 Peter Clemons 2006-05-26 17:42:32 EDT

(In reply to comment #31)
I've done all that you suggested.  I had the following results.
1) Hitting our internal HTTPS-based innerweb worked
2) Hitting any other internal HTTPS-based web server did not work
3) Eclipse's internal browser was Mozilla (using the MOZILLA_FIVE_HOME environment variable)
4) Eclipse's external browser was FireFox (1.5 and 1.08, I tried both)
5) Tried to get FireFox to be internal browser, but neither my distro nor the general firefox downloads provide a libgtkembedmoz.so library.  Also, after a bit of research, it seems that Mozilla/FireFox no longer wants embedders/consumers to use this library ...just the libxpcom.so directly.
6) Our InnerWeb didn't ask for any certificate authority confirmation (which is why I suspect it worked)
7) All other internal servers (which didn't work) DID ask for certificate authority confirmations (I think the certs were produced using unknown authorities)
8) Using the internal Mozilla browser (1.7.12; GTK2), I was NOT asked again about the certificates even though I deleted the .mozilla and .mozillaeclipse profile directories and exited the application completely.

Any help would be appreciated.

Comment 33 Karice McIntyre 2006-05-30 13:21:05 EDT

There is an entry in the 3.2 readme for this bug:
org.eclipse.platform-feature/rootfiles/readme/readme_eclipse.html#I-Platform-SWT

Firefox on Linux can crash when looking for user profile
As a result of profile support not being implemented by the Browser widget on linux, browser crashes can occur in contexts where the embedded Firefox browser assumes that a user profile is present. There is currently one known case of this (see bug 132500). A potential workaround for such cases is to set your MOZILLA_FIVE_HOME environment variable to point at a local Mozilla installation instead of Firefox.

Comment 34 Grant Gayed 2006-05-31 10:15:04 EDT

re: comment 32

I don't know why the certificates aren't working for you, but this is probably a separate pre-existing problem that was not previously seen because the browser did not attempt https hits like the ones that you see failing.  I've logged bug 144672.

Comment 35 Steven Wasleski 2006-06-21 09:17:00 EDT

Note that this bug also blocks bug 91348.  I do not have authority to add this to the "blocks" field.

What are the current thoughts regarding fixing this in 3.2.1?  There is quite a bit of interest in this bug.

Comment 36 Grant Gayed 2006-06-21 09:35:04 EDT

The fix for this is in the HEAD stream (currently 32-bit only, but 64-bit should not be any different).  If it proves to be stable through the summer, which I'm guessing it will, then this is planned for 3.2.1.

Comment 37 Grant Gayed 2006-06-23 10:02:16 EDT

Created attachment 45172 [details]
collection of patches for 3.2.1

These are the patches to use for applying the fix for this to the 3.2.1 stream, assuming that this fix has a successful summer in HEAD.

Comment 38 Grant Gayed 2006-06-23 10:06:03 EDT

Fixed > 0623 in HEAD on linux-gtk, linux-gtk-64 and linux-motif.  Marking target as 3.2.1 so that this fix is not forgotten when 3.2.1 bugs are considered.

Comment 39 Grant Gayed 2006-06-26 15:50:03 EDT

FYI: This functionality will likely be disabled in tomorrow's integration build because it has been causing the unit tests of some other plugins to fail (unless a fix can be found quickly).

Comment 40 Grant Gayed 2006-07-07 16:42:42 EDT

To update, an updated fix for this has been released to HEAD, so it should appear in the next integration build.

Comment 41 Grant Gayed 2006-07-26 13:45:01 EDT

this fix has been added to the 3.2.1 stream

Comment 42 Masayuki Fuse 2006-08-04 05:29:58 EDT

I'm still seeing the crash in Eclipse 3.2.1 M20060802-0800 build. I've tried on two RHEL4 WS U3 machines, one is firefox 1.0.8 installed and the other is firefox 1.5.0.5 installed via Red Hat Network. 

Comment 43 Grant Gayed 2006-08-08 08:12:40 EDT

Yes, swt's build contribution for 3.2.1 was missed last week.  It will be in this week's.

Comment 44 Masayuki Fuse 2006-08-11 05:29:14 EDT

ok, I've verified in M20060810_0800 successfully. thank you very much!!

Miyamoto-san,
Please close this bug.

Comment 45 Natsuki Miyamoto 2006-08-12 09:19:55 EDT

My team lead verified this fix for me. 
Per request of him I close this. 
Thank you.