Community
Participate
Eclipse IDE
Build ID: I20090611-1540 Steps To Reproduce: 1. Run the attached main on Ubuntu. 2. Type a letter in to the text field. 3. The application segfaults in pango_layout_new. More information: This bug causes a hard crash on Ubuntu Linux only. The crash happens on Ubuntu 8.04 and 9.04. It does not crash on Centos 5. The correct behavior is for the application to quit on an uncaught exception, not to crash with a segfault. It seems possible (but not certain) that this bug is related to the much-discussed Ubuntu bug 174759: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/174759 The Java VM is 1.6.0_13. The GTK version is 2.16.1.
Created attachment 143541 [details] The hs_err file generated when Java segfaults.
Created attachment 143542 [details] test main illustrating the crash
Praveen, please try this out on your Ubuntu.
This bug happen very often (making eclipse unusable) with libpango-1.0-0 1.26.0-1 (ubuntu karmic) on amd64 architecture (not try on 32bits). Happen either with sun-jdk-6 and openjdk-6. Same eclipse works with previous ubuntu version : libpango1.0-0 (1.24.1-0ubuntu1)
Also affects Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=522187
The test case fails for me with 3.5.1 on Fedora (what will be 12).
Updating version to reflect that it's present in 3.5.1.
Created attachment 150915 [details] Patch v01 Bogdan, please review the patch and suggest if anything else is required. Thanks.
Catching application exceptions do not seem like a good idea to me. Why are not those exceptions fixed instead? The crash log from comment#1 shows Text.gtk_commit() on the stack. The patch has a fix for Text.gtk_text_buffer_insert_text(). It probably fixes the sample app from commnet#2. Does it fixes the original problem?
(In reply to comment #9) > Catching application exceptions do not seem like a good idea to me. Why are not > those exceptions fixed instead? The exception is raised in the user listener handler code. Since that is an uncaught exception, should the exception be handled by JVM to terminate the appl with the exception stack, instead of fixing it ? > The crash log from comment#1 shows Text.gtk_commit() on the stack. The patch > has a fix for Text.gtk_text_buffer_insert_text(). It probably fixes the sample > app from commnet#2. Does it fixes the original problem? The attached exception log somehow doesn't show the native function stack. While I was recreating the problem, with the exception logs occured on my machine, I realized that the exception was due to the gtk_commit() emitting the commit signal, which is inturn invoking the gtk_text_buffer_insert_text() method. The idea of the fix is to block the signal handler only when there is an uncaught exception and before the GTK executes it's default signal handler (with the assumption that SWT finished processing 'commit' signal) leading to crash in native libraries.
I always met such crash on Helios M6 and Ubuntu 9.10. The same code works fine on 3.5.1. Not sure whether they're same.
Created attachment 162380 [details] The hs_err file generated by jvm The hs_err file generated by jvm
hi this seems to be causing JSDT in Helios to crashing pretty easily. See bug 318697 for details.
Created attachment 173294 [details] hs_err_pid3720.log jvm error log generated by JSDT-related crash mentioned in prev. comment.
there's another JSDT issue, probably caused by this: bug 319609 - IDE crashes when editing a particular JavaScript source file.
*** This bug has been marked as a duplicate of bug 322222 ***
Roland Gunther, do you know where is the code that is causing the exception in your product ? If you do, you need to handle the exception before you return from the event handler. That is the real fix for the problem.
(In reply to comment #17) > Roland Gunther, do you know where is the code that is causing the exception in > your product ? > If you do, you need to handle the exception before you return from the event > handler. That is the real fix for the problem. Note: At this point I'm not sure we can fix bug 322222, so it is important that you try to handle the exception on your side (it should be easy).
(In reply to comment #18) > (In reply to comment #17) > > Roland Gunther, do you know where is the code that is causing the exception in > > your product ? > > If you do, you need to handle the exception before you return from the event > > handler. That is the real fix for the problem. > > Note: At this point I'm not sure we can fix bug 322222, so it is important that > you try to handle the exception on your side (it should be easy). Felipe, thanks for the looking at this. We did fix the Java exception long ago. However, it does seem that it would be better if SWT did not segfault. I recently reported bug 321929--from your comments, this seems to be the same bug. The Java exception that caused 321929 was easily fixed, but it was a bug that we ran into at a customer's site. Java exceptions happen on occasion, and it would have been nicer if Java had propagated the exception instead of segfaulting.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=322222#c9 SWT should not crash because of unhandled exception...
