Community
Participate
Working Groups
Created attachment 141611 [details] JVM error log Build ID: I20090611-1540 Steps To Reproduce: To reproduce: 1. create the following class: import javax.servlet.ServletContext; public class Some { public static void main( String[] args ) { ServletContext ctx; ctx. } } 2. Invoke content assist after "ctx.", scroll down to log(String,Throwable) method and click on it. Immediately after selecting this entry eclipse crashes. More information: Env: Win32 XP SP3, Sun 1.6.0_14 Looks like somebody has been having similar problem here: http://dev.eclipse.org/newslists/news.eclipse.dsdp.mtj/msg00504.html
Works for me. This is probably a bug in the version of USP.DLL on your system. If I was to send you some code to try, could be able to load SWT from CVS, apply the patch, self-host eclipse, and reproduce the steps in comment 1 ? see http://eclipse.org/swt/cvs.php for instruction on how to download SWT from HEAD.
(In reply to comment #1) > If I was to send you some code to try, could be able to load SWT from CVS, > apply the patch, self-host eclipse, and reproduce the steps in comment 1 ? Self-host = run eclipse with some plugins loaded directly from workspace? (I haven't found definition anywhere). If I'm correct then yes, there won't be any problems to patch SWT and try it.
Created attachment 142161 [details] JVM crash log 1
I have also come across the same crash three times now in the same day. My JVM error logs look the same as Vadim's.
I also see this error. I am running windows xp SP2 32bit. I have tried USP10.dll versions 1.420.2600.2180, 1.471.4063.0, 1.626.5756.0 (All versions of USP10.dll on my system). They all crash. I managed to find USP10.dll version 1.175.0.1 on the internet. The crash does not occur. I can email any version of USP10.dll for testing if you like. I just put the dll file in c:\program files\eclipse to test it out. I'm just glad I found a workaround because this was REALLY bugging the hell out of me. I had many (>10) crashes per day!
*** Bug 288185 has been marked as a duplicate of this bug. ***
*** Bug 297279 has been marked as a duplicate of this bug. ***
I replaced USP10.DLL under Windows/System with version 1.175.0.1, and I also put it under the eclipse directory. The crash is still occurring.
I am experiencing this problem as well.
What is your windows version and service pack level ? Do you have support for complex scripts and right-to-left languages installed ? Do you have east asian languages support installed ? (see Control-Panel->Regional and Language Settings->Languages). Do you have fixed set of steps that always reproduce the problem ?
(In reply to comment #10) > What is your windows version and service pack level ? > > Do you have support for complex scripts and right-to-left languages installed ? > Do you have east asian languages support installed ? > (see Control-Panel->Regional and Language Settings->Languages). > > Do you have fixed set of steps that always reproduce the problem ? Windows XP - SP3 No No The crash only occurs when using the content assist (automatic or by pressing ctrl-space). It doesn't happen every time but it happens fairly often. I'm attaching my crash log as well.
Created attachment 157418 [details] Eclipse crash log
*** Bug 301450 has been marked as a duplicate of this bug. ***
I'm having the same problem (bug 301450). My USP10.DLL version is 1.0420.2600.5512 (xpsp.080413-2105). Complex/right-to-left language support is enabled; east asian is not. Windows XP Pro SP3.
Is there any update to this issue?
(In reply to comment #15) > Is there any update to this issue? Sorry, I do not know why this problem occurs for some people but not for others. It can be a different font, system locale, Uniscribe version (USP10.dll), some other program that affects how Uniscribe works (like ClearType Tuning). This works for me on all my machines, I never had the chance to debug the problem and write a fix.
*** Bug 305584 has been marked as a duplicate of this bug. ***
*** Bug 308230 has been marked as a duplicate of this bug. ***
Created attachment 165336 [details] Source code changes and fixed jar that stops Eclipse from crashing This file contains source code changes and tweaked jar file that can be used immediately to patch this problem in existing installations. If you can the following error in your JVM crash log, this will fix it. I am not sure if this is a good fix or not, because I have no idea how it works, but at least it does not crash anymore. I hope developers will integrate it in some form into main code. C [USP10.dll+0x13a13] C [swt-win32-3557.dll+0xd452] j org.eclipse.swt.internal.win32.OS.ScriptGetLogicalWidths(Lorg/eclipse/swt/internal/win32/SCRIPT_ANALYSIS;IIIII[I)I+0 J org.eclipse.swt.graphics.TextLayout.computeRuns(Lorg/eclipse/swt/graphics/GC;)V j org.eclipse.swt.graphics.TextLayout.getBounds()Lorg/eclipse/swt/graphics/Rectangle;+6 j org.eclipse.jface.internal.text.html.BrowserInformationControl.computeSizeHint()Lorg/eclipse/swt/graphics/Point;+172 j org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(Lorg/eclipse/swt/graphics/Rectangle;Ljava/lang/Object;)V+236
(In reply to comment #19) > Created an attachment (id=165336) [details] > Source code changes and fixed jar that stops Eclipse from crashing > This file contains source code changes and tweaked jar file that can be used > immediately to patch this problem in existing installations. > If you can the following error in your JVM crash log, this will fix it. I am > not sure if this is a good fix or not, because I have no idea how it works, but > at least it does not crash anymore. I hope developers will integrate it in some > form into main code. Your fix breaks word wrapping completely.
(In reply to comment #20) > (In reply to comment #19) > > Created an attachment (id=165336) [details] [details] > > Source code changes and fixed jar that stops Eclipse from crashing > > This file contains source code changes and tweaked jar file that can be used > > immediately to patch this problem in existing installations. > > If you can the following error in your JVM crash log, this will fix it. I am > > not sure if this is a good fix or not, because I have no idea how it works, but > > at least it does not crash anymore. I hope developers will integrate it in some > > form into main code. > > Your fix breaks word wrapping completely. Well, I have no idea how this code works. However, it should really avoid entering Microsoft native code that is known to crash. Is there any way to emulate ScriptGetLogicalWidths? Can you make me a special version of TextLayout.java that can output all values given to ScriptGetLogicalWidths to some kind of log file, I can run it on my system and get this log back to you for analysis.
Can you reproduce this crash everytime ? Can you debug the code and see what parameters are being passed to ScriptGetLogicalWidths() ? See the doc for ScriptGetLogicalWidths() http://msdn.microsoft.com/en-us/library/dd368552(v=VS.85).aspx In TextLayout, ScriptGetLogicalWidths() is used to implement wrapping (to find what is the last character in the run that fits in the line). Let me know if you can reproduce the problem everytime, I can send you a special version of TextLayout.java with debug information.
(In reply to comment #22) > Can you reproduce this crash everytime ? Can you debug the code and see what > parameters are being passed to ScriptGetLogicalWidths() ? > See the doc for ScriptGetLogicalWidths() > http://msdn.microsoft.com/en-us/library/dd368552(v=VS.85).aspx > > In TextLayout, ScriptGetLogicalWidths() is used to implement wrapping (to find > what is the last character in the run that fits in the line). > > Let me know if you can reproduce the problem everytime, I can send you a > special version of TextLayout.java with debug information. Yes, reproducable 100%. I tried to find some guidelines how to debug Eclipse, but could not find anything useful and understandable. The easiest for us probably is to inject some code in TextLayout.java and write it to a file. I tried to recompile this jar with build.bat but realized that I don't have all the needed setup and compiler tools, so I just used javac to recompile only TextLayout.java and inject .class files into old jar, this worked. However, if you have better suggestions to debug it, I am open.
(In reply to comment #23) I also wonder, since it does crash inside MS code, can we use wine implementation? http://source.winehq.org/source/dlls/usp10/usp10.c
1. Start a new (empty) workspace 2. download SWT from the CVS http://eclipse.org/swt/cvs.php 3. Select the eclipse project and in the context menu, select Debug As->Eclipse application 4. A new instance of Eclipse will start, do whatever you have to do to this new eclipse to reproduce bug (create projects, java class file, etc). 5. Once you are able to reproduce the problem in your self-hosted Eclipse, go to your first Eclipse, open TextLayout.java and add a break point in computeRuns() (right before ScriptGetLogicalWidths() is called). Let me know when you have the above working for you.
Created attachment 166010 [details] Source code changes and more debug info - try2 Thanks Felipe, this was helpful. I really struggled with CVS at first, it was interrupting connection all the time. Installed Git plugin and it worked. Attachment contains captured variable values, suggested fix for TextLayout.java and this text in readme.txt ------------------------------------------------------------------------- First, due to internal properties of the problematic StyleItem (run) instance, this gets executed in TextLayout->getBounds()->computeRuns(GC)->shape and return happens right away. --------------------------------------------- if (run.tab || run.lineBreak) return; --------------------------------------------- Thus, later code in shape function for creating 'advances' (specifically - run.advances = OS.HeapAlloc(hHeap, OS.HEAP_ZERO_MEMORY, run.glyphCount * 4) ) is not executed and run.advances pointer is still set to null for this run. Further on, in this code: if (wrapWidth != -1 && lineWidth + run.width > wrapWidth && !run.tab) { int start = 0; int[] piDx = new int[run.length]; if (run.style != null && run.style.metrics != null) { piDx[0] = run.width; } else { OS.ScriptGetLogicalWidths(run.analysis, run.length, run.glyphCount, run.advances, run.clusters, run.visAttrs, piDx); } We execute OS.ScriptGetLogicalWidths(run.analysis, run.length, run.glyphCount, run.advances, run.clusters, run.visAttrs, piDx) with these parameters: run TextLayout$StyleItem (id=163) advances 0 analysis SCRIPT_ANALYSIS (id=192) clusters 0 glyphCount 0 length 2 lineBreak true visAttrs 0 ( I am attaching files with text debug information, one captured at the end of this loop for (int i=0; i<allRuns.length - 1; i++) { StyleItem run = allRuns[i]; OS.SelectObject(srcHdc, getItemFont(run)); shape(srcHdc, run); } second captured exactly before the crash at OS.ScriptGetLogicalWidths(run.analysis, run.length, run.glyphCount, run.advances, run.clusters, run.visAttrs, piDx); ) So, three null pointers (advances,clusters,visattrs) are given to Windows function and result in access violation and crashing of JVM (really it is Microsoft problem in first place) The simplest fix that comes to my mind is to just avoid entering OS.ScriptGetLogicalWidths when null pointers are used, but it seems that it will only hide the real problem. I think what is happening is that condition 'if (wrapWidth != -1 && lineWidth + run.width > wrapWidth && !run.tab) {' is not good enough because in shape function we return at the beginning in more cases ( when run.lineBreak is true and glypth!=0 ), so may be we should extract this check into separate function as I did in provided TextLayout.java bool skipRun(StyleItem run) { return run.tab || run.lineBreak; } and use it at the beginning of shape function: if(skipRun(run)) return; and in computeRunGC ( I also added null point check, so that there is no chance for it to crash ) if (wrapWidth != -1 && lineWidth + run.width > wrapWidth && (!skipRun(run))) { int start = 0; int[] piDx = new int[run.length]; if (run.style != null && run.style.metrics != null) { piDx[0] = run.width; } else { if(run.advances == 0) SWT.error(SWT.ERROR_NO_HANDLES,null,"TextLayout: run.advances is null and can not be passed to OS.ScriptGetLogicalWidths"); if(run.clusters == 0) SWT.error(SWT.ERROR_NO_HANDLES,null,"TextLayout: run.clusters is null and can not be passed to OS.ScriptGetLogicalWidths"); if(run.visAttrs == 0) SWT.error(SWT.ERROR_NO_HANDLES,null,"TextLayout: run.visAttrs is null and can not be passed to OS.ScriptGetLogicalWidths"); OS.ScriptGetLogicalWidths(run.analysis, run.length, run.glyphCount, run.advances, run.clusters, run.visAttrs, piDx); } ---------------------------------------------------------- Let me know if this looks like a valid fix or if you need more info.
Thank you so much, using the information you provided I was able to understand the problem, write a snippet, and fix the problem. Here is the snippet to reproduce the crash: import org.eclipse.swt.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.widgets.*; public class PR283503 { public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); shell.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { // When the line ends with tab stop followed by a break line, and the line width exceeds the wrap width // by the width of the last tab stop, it causes the wrap algorithm to try to move the line break to the // next line. This causes ScriptGetLogicalWidths to crash because line breaks don't have glyphs. // The fix is to change the wrap algorithm to ignore line breaks. // Note: wrap algorithm didn't explicitly ignore line breaks in the past because the width of line breaks // are always zero and it never cause the line to wrap. In this case it does because the total line width // was incremented by the precending tab stop, which was ignored as it should (tabs at the end of the line // should not be moved the next line). GC gc = event.gc; TextLayout l = new TextLayout (display); l.setText("Hi there\t\n"); l.setWidth(100); l.setTabs(new int [] {102}); l.draw(gc, 10, 70); l.dispose(); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Created attachment 166096 [details] patch
Fixed in HEAD > 20100426 Bog, please make sure this fix is in for M7. I'm happy this is fixed, this problem has bothered me for quite some time. Thanks again for all your help debuging this crash.
What about error checking lines preventing it from crashing and reporting error to the log?
(In reply to comment #30) > What about error checking lines preventing it from crashing and reporting error > to the log? Not needed. Did you try the fix ?
*** Bug 314565 has been marked as a duplicate of this bug. ***
*** Bug 317105 has been marked as a duplicate of this bug. ***
*** Bug 320866 has been marked as a duplicate of this bug. ***
What is the status of this issue, it can be very detrimental to productivity?
(In reply to comment #35) > What is the status of this issue, it can be very detrimental to productivity? This bug's status is set to RESOLVED/FIXED. Hence, it has been fixed as far as we know. Its target milestone is set to 3.6M7, which means 3.6M7 and any builds after it (such as 3.6 final) should have the fix included with it. http://download.eclipse.org/eclipse/downloads/
We are seeing a crash very similar but not identical to this one on eclipse 3.7.2. The native access violation always happens here: J org.eclipse.swt.internal.win32.OS.HeapAlloc(JII)J j org.eclipse.swt.graphics.TextLayout.shape(JLorg/eclipse/swt/graphics/TextLayout$StyleItem;)V+1224 J org.eclipse.swt.graphics.TextLayout.computeRuns(Lorg/eclipse/swt/graphics/GC;)V I know a fix was applied for the issue related to TextLayout.computeRuns() calling OS.GetLogicalWidths(), but is it possible there is a similar problem with TextLayout.shape() calling OS.HeapAlloc()? Thanks, Scott
