Community
Participate
Working Groups
Build Identifier: 20100617-1415 Eclipse crashes if using the project explorer you navigate to a directory that contains a file whose name matches *.f*. I also tried with JDK 1.6.0 build 20 with the same result. I use Eclipse Helios for C/C++ Development under Kubuntu 10.04. The bug should be either in SWT or in GTK. A similar report from OpenSuSE is available here: https://bugzilla.novell.com/show_bug.cgi?id=616663 The error in command line: *** glibc detected *** /opt/jdk1.7.0/bin/java: free(): invalid pointer: 0x0000000001d94810 *** ======= Backtrace: ========= /lib/libc.so.6(+0x775b6)[0x7fed342315b6] /opt/jdk1.7.0/jre/lib/amd64/server/libjvm.so(+0x407695)[0x7fed33af7695] /home/espakm/eclipse-helios/configuration/org.eclipse.osgi/bundles/210/1/.cp/libswt-pi-gtk-3650.so(Java_org_eclipse_swt_internal_gtk_OS__1g_1data_1input_1stream_1read_1line+0xe7)[0x7fecfe196a9e] [0x7fed2f1dfc48] ======= Memory map: ======== 00400000-00401000 r-xp 00000000 fc:01 2389290 /opt/jdk1.7.0/bin/java 00600000-00601000 rw-p 00000000 fc:01 2389290 /opt/jdk1.7.0/bin/java 00fc2000-0637e000 rw-p 00000000 00:00 0 [heap] 7fecf7108000-7fecf711e000 r-xp 00000000 fc:01 64797 /lib/libgcc_s.so.1 7fecf711e000-7fecf731d000 ---p 00016000 fc:01 64797 /lib/libgcc_s.so.1 7fecf731d000-7fecf731e000 r--p 00015000 fc:01 64797 /lib/libgcc_s.so.1 7fecf731e000-7fecf731f000 rw-p 00016000 fc:01 64797 /lib/libgcc_s.so.1 7fecf7354000-7fecf735f000 r-xp 00000000 fc:01 179945 /lib/libudev.so.0.6.1 7fecf735f000-7fecf755e000 ---p 0000b000 fc:01 179945 /lib/libudev.so.0.6.1 7fecf755e000-7fecf755f000 r--p 0000a000 fc:01 179945 /lib/libudev.so.0.6.1 7fecf755f000-7fecf7560000 rw-p 0000b000 fc:01 179945 /lib/libudev.so.0.6.1 7fecf7560000-7fecf7578000 r-xp 00000000 fc:01 17001929 /usr/lib/libgvfscommon.so.0.0.0 7fecf7578000-7fecf7777000 ---p 00018000 fc:01 17001929 /usr/lib/libgvfscommon.so.0.0.0 7fecf7777000-7fecf7778000 r--p 00017000 fc:01 17001929 /usr/lib/libgvfscommon.so.0.0.0 7fecf7778000-7fecf7779000 rw-p 00018000 fc:01 17001929 /usr/lib/libgvfscommon.so.0.0.0 7fecf7779000-7fecf77a2000 r-xp 00000000 fc:01 83939308 /usr/lib/gio/modules/libgvfsdbus.so 7fecf77a2000-7fecf79a2000 ---p 00029000 fc:01 83939308 /usr/lib/gio/modules/libgvfsdbus.so 7fecf79a2000-7fecf79a3000 r--p 00029000 fc:01 83939308 /usr/lib/gio/modules/libgvfsdbus.so 7fecf79a3000-7fecf79a4000 rw-p 0002a000 fc:01 83939308 /usr/lib/gio/modules/libgvfsdbus.so 7fecf79a4000-7fecf79a7000 r-xp 00000000 fc:01 118413 /lib/libgpg-error.so.0.4.0 7fecf79a7000-7fecf7ba6000 ---p 00003000 fc:01 118413 /lib/libgpg-error.so.0.4.0 7fecf7ba6000-7fecf7ba7000 r--p 00002000 fc:01 118413 /lib/libgpg-error.so.0.4.0 7fecf7ba7000-7fecf7ba8000 rw-p 00003000 fc:01 118413 /lib/libgpg-error.so.0.4.0 7fecf7ba8000-7fecf7bac000 r-xp 00000000 fc:01 256 /lib/libuuid.so.1.3.0 7fecf7bac000-7fecf7dab000 ---p 00004000 fc:01 256 /lib/libuuid.so.1.3.0 7fecf7dab000-7fecf7dac000 r--p 00003000 fc:01 256 /lib/libuuid.so.1.3.0 7fecf7dac000-7fecf7dad000 rw-p 00004000 fc:01 256 /lib/libuuid.so.1.3.0 7fecf7dad000-7fecf7db4000 r-xp 00000000 fc:01 16904948 /usr/lib/libgailutil.so.18.0.1 7fecf7db4000-7fecf7fb3000 ---p 00007000 fc:01 16904948 /usr/lib/libgailutil.so.18.0.1 7fecf7fb3000-7fecf7fb4000 r--p 00006000 fc:01 16904948 /usr/lib/libgailutil.so.18.0.1 7fecf7fb4000-7fecf7fb5000 rw-p 00007000 fc:01 16904948 /usr/lib/libgailutil.so.18.0.1 7fecf7fb5000-7fecf7fba000 r-xp 00000000 fc:01 17310327 /usr/lib/libORBitCosNaming-2.so.0.1.0 7fecf7fba000-7fecf81ba000 ---p 00005000 fc:01 17310327 /usr/lib/libORBitCosNaming-2.so.0.1.0 7fecf81ba000-7fecf81bb000 r--p 00005000 fc:01 17310327 /usr/lib/libORBitCosNaming-2.so.0.1.0 7fecf81bb000-7fecf81bc000 rw-p 00006000 fc:01 17310327 /usr/lib/libORBitCosNaming-2.so.0.1.0 7fecf81bc000-7fecf8231000 r-xp 00000000 fc:01 118415 /lib/libgcrypt.so.11.5.2 7fecf8231000-7fecf8430000 ---p 00075000 fc:01 118415 /lib/libgcrypt.so.11.5.2 7fecf8430000-7fecf8431000 r--p 00074000 fc:01 118415 /lib/libgcrypt.so.11.5.2 7fecf8431000-7fecf8434000 rw-p 00075000 fc:01 118415 /lib/libgcrypt.so.11.5.2 7fecf8434000-7fecf8444000 r-xp 00000000 fc:01 16777986 /usr/lib/libtasn1.so.3.1.7 7fecf8444000-7fecf8643000 ---p 00010000 fc:01 16777986 /usr/lib/libtasn1.so.3.1.7 7fecf8643000-7fecf8644000 r--p 0000f000 fc:01 16777986 /usr/lib/libtasn1.so.3.1.7 7fecf8644000-7fecf8645000 rw-p 00010000 fc:01 16777986 /usr/lib/libtasn1.so.3.1.7 7fecf8645000-7fecf865c000 r-xp 00000000 fc:01 17829147 /usr/lib/libICE.so.6.3.0 7fecf865c000-7fecf885b000 ---p 00017000 fc:01 17829147 /usr/lib/libICE.so.6.3.0 7fecf885b000-7fecf885c000 r--p 00016000 fc:01 17829147 /usr/lib/libICE.so.6.3.0 7fecf885c000-7fecf885d000 rw-p 00017000 fc:01 17829147 /usr/lib/libICE.so.6.3.0 7fecf885d000-7fecf8860000 rw-p 00000000 00:00 0 7fecf8860000-7fecf8868000 r-xp 00000000 fc:01 16777366 /usr/lib/libSM.so.6.0.1 7fecf8868000-7fecf8a67000 ---p 00008000 fc:01 16777366 /usr/lib/libSM.so.6.0.1 7fecf8a67000-7fecf8a68000 r--p 00007000 fc:01 16777366 /usr/lib/libSM.so.6.0.1 7fecf8a68000-7fecf8a69000 rw-p 00008000 fc:01 16777366 /usr/lib/libSM.so.6.0.1 7fecf8a69000-7fecf8a87000 r-xp 00000000 fc:01 17114188 /usr/lib/libgnome-keyring.so.0.1.1 7fecf8a87000-7fecf8c86000 ---p 0001e000 fc:01 17114188 /usr/lib/libgnome-keyring.so.0.1.1 7fecf8c86000-7fecf8c87000 r--p 0001d000 fc:01 17114188 /usr/lib/libgnome-keyring.so.0.1.1 7fecf8c87000-7fecf8c88000 rw-p 0001e000 fc:01 17114188 /usr/lib/libgnome-keyring.so.0.1.1 7fecf8c88000-7fecf8ce4000 r-xp 00000000 fc:01 16894441 /usr/lib/libORBit-2.so.0.1.0 7fecf8ce4000-7fecf8ee4000 ---p 0005c000 fc:01 16894441 /usr/lib/libORBit-2.so.0.1.0 Reproducible: Always Steps to Reproduce: 1. Create a new file called "test.fl", either from Eclipse or from outside. 2. Open the directory that contains the file from the Project Explorer.
The problem may be related to KDE. It does not occur from an OpenBox session. I use KDE 4.5 RC2.
*** Bug 320501 has been marked as a duplicate of this bug. ***
> The problem may be related to KDE. It does not occur from an OpenBox session. > I use KDE 4.5 RC2. This indeed could be connected. It started happening after I updated KDE.
(In reply to comment #3) > > The problem may be related to KDE. It does not occur from an OpenBox session. > > I use KDE 4.5 RC2. > > This indeed could be connected. It started happening after I updated KDE. I can confirm that KDE 4.5 is indeed the cause. After downgrading to 4.4.4, Eclipse works without any problems.
Strange that this has anything to do with KDE 4.5, but I am also using KDE 4.5 and it didn't happen before.
*** Bug 320931 has been marked as a duplicate of this bug. ***
I can confirm this bug. $ kwin --version Qt: 4.7.0 Plataforma de desarrollo de KDE: 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2)) KWin: 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2)) $ uname -a Linux Lucid 2.6.32-24-generic #38-Ubuntu SMP Mon Jul 5 09:20:59 UTC 2010 x86_64 GNU/Linux With eclipse helios with the latest patches installed.
The backtrace looks similar to Bug 299025. The bug was sometime back, but may be the workaround is worth a try. Is the environment variable MALLOC_CHECK_ set to 3? Does unsetting this prevent the crash?
(In reply to comment #8) > The backtrace looks similar to Bug 299025. The bug was sometime back, but may > be the workaround is worth a try. > Is the environment variable MALLOC_CHECK_ set to 3? Does unsetting this prevent > the crash? Yes, setting it to 0 does fix the crash, however I'm not sure whether that is the correct way of fixing the bug, since as far as I know MALLOC_CHECK_ is supposed to warn you in case of heap corruption.
when I set MALLOC_CHECK_ to 1 I get ~40-70 lines of *** glibc detected *** /usr/bin/java: free(): invalid pointer: 0x0000000000f99bb0 *** every time I expand anything in the project explorer, this makes me think the is something wrong in the native method calling g_data_input_stream_read_line() Now it also makes sense that Eclipse only crashes in a KDE session, since somehow MALLOC_CHECK_ is set to 3 there whereas it is not set in an openbox or LXDE session.
Same problem here; also KDE 4.5 RC2. MALLOC workaround works here too. This is with Eclipse 3.6, btw, as I noted this bug report is tagged 'Version 4.0'.
Happening here too, on both sun and openjdk using Eclipse 3.6 for PHP, and just after upgrading to KDE 4.5. I can also confirm that the MALLOC_CHECK_ workaround is working for me also.
I think it does not depend on filename. I've tried to remove and then add files to project. Eclipse crased every time I launched it "with files". So I launched it "empty". I was able to add some files (pressing F5 in project explorer) until it crashed. Then I removed last added file and tried to launch again. No success. So it just crashes on some file lists.
(In reply to comment #13) > I think it does not depend on filename. I do not see the exact relationship, but Eclipse did not crash for files with the following extensions: .txt, .c, .cpp, .cxx, .h, .hpp, .hxx. Any other extension I tried caused a crash for me. The MALLOC_CHECK_ workaround worked here as well.
(In reply to comment #14) > (In reply to comment #13) > > I think it does not depend on filename. > > I do not see the exact relationship, but Eclipse did not crash for files with > the following extensions: .txt, .c, .cpp, .cxx, .h, .hpp, .hxx. It's likely crashing when you have files with an extension that is not "registered" with an Eclipse editor. In that case, we ask the OS for its icon, which is likely the cause of the crash.
(In reply to comment #14) > I do not see the exact relationship, but Eclipse did not crash for files with > the following extensions: .txt, .c, .cpp, .cxx, .h, .hpp, .hxx. I tried 2 *.c files and ~10 *.cpp files in project. It crashed anyway. Yet this was not proper C++ files. I'm "translating" program from Python/Qt to C++/Qt, so python code was inside. =)
Happening here too: KDE Platform Version: 4.5.00 (KDE 4.5.0) Qt Version: 4.6.3 Operating System: Linux 2.6.34-ARCH x86_64 gtk 1.2.10 Please fix ASAP! Thanks
Happening here too: KDE Platform Version: 4.5.00 (KDE 4.5.0) OpenSUSE 11.3 x86_64 Eclipse PDT Helios 3.6 I've tried with Sun/OpenJDK both crash. I tried with $ export MALLOC_CHECK_=0 and still crash. I don't know if that's the correct way. Workaround: java -jar -verbose eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar Latter works most times, yet some crashes but not as often. But DataUsageCollector is not working with it.
Try with MALLOC_CHECK_=1. Works for me. (In reply to comment #18) > Happening here too: > KDE Platform Version: 4.5.00 (KDE 4.5.0) > OpenSUSE 11.3 x86_64 > Eclipse PDT Helios 3.6 > > I've tried with Sun/OpenJDK both crash. > > I tried with > $ export MALLOC_CHECK_=0 > and still crash. I don't know if that's the correct way.
(In reply to comment #18) > Happening here too: > KDE Platform Version: 4.5.00 (KDE 4.5.0) > OpenSUSE 11.3 x86_64 > Eclipse PDT Helios 3.6 > > I've tried with Sun/OpenJDK both crash. > > I tried with > $ export MALLOC_CHECK_=0 > and still crash. I don't know if that's the correct way. > > Workaround: > java -jar -verbose > eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar > > Latter works most times, yet some crashes but not as often. But > DataUsageCollector is not working with it. If you export it, you have to run Eclipse from the same shell. Alternately put the export statement in your ~/.bashrc. However MALLOC_CHECK could detect real problems and this would disable it for every program. I just used the menu editor and changed the command from "/usr/bin/eclipse" to "MALLOC_CHECK_=0 /usr/bin/eclipse" MALLOC_CHECK_=1 just prints the error to stdout whereas 0 simply ignores it, so that should not be the issue.
(In reply to comment #20) > (In reply to comment #18) > > Happening here too: > > KDE Platform Version: 4.5.00 (KDE 4.5.0) > > OpenSUSE 11.3 x86_64 > > Eclipse PDT Helios 3.6 > > > > I've tried with Sun/OpenJDK both crash. > > > > I tried with > > $ export MALLOC_CHECK_=0 > > and still crash. I don't know if that's the correct way. > > > > Workaround: > > java -jar -verbose > > eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar > > > > Latter works most times, yet some crashes but not as often. But > > DataUsageCollector is not working with it. > > If you export it, you have to run Eclipse from the same shell. Alternately put > the export statement in your ~/.bashrc. However MALLOC_CHECK could detect real > problems and this would disable it for every program. I just used the menu > editor and changed the command from "/usr/bin/eclipse" to "MALLOC_CHECK_=0 > /usr/bin/eclipse" > > MALLOC_CHECK_=1 just prints the error to stdout whereas 0 simply ignores it, so > that should not be the issue. Thank you very much!! That seems to work - for now - Why do you think that running the workaround that I wrote, it works??
*** Bug 323374 has been marked as a duplicate of this bug. ***
*** Bug 323416 has been marked as a duplicate of this bug. ***
*** Bug 323812 has been marked as a duplicate of this bug. ***
$ kwin --version Qt: 4.7.0 KDE Development Platform: 4.5.00 (KDE 4.5.0) KWin: 4.5.00 (KDE 4.5.0) On my system Eclipse Helios crashes everytime the web browser is accessed (e.g. clicking a Learn more link in the marketplace screen). Even hovering over Window -> Web Browser in the menu bar, or over General->Web Browser in the preferences screen initiates a crash. Glad that the MALLOC_CHECK_=0 workaround works for me, otherwise it would have been completely unusable...
Addition (now that, with the MALLOC_CHECK_ workaround, I can see the settings again without a crash): the webbrowser setting in Eclipse was set to Firefox, not to the default Use internal browser.
The workaround will be enabled by default in KDE SC 4.5.1 (see https://bugs.kde.org/show_bug.cgi?id=245815) However this has to be fixed properly inside SWT.
Can we remove the MALLOC_CHECK_ workaround when running KDE 4.5.1 or do we need to wait for a fix in SWT?
(In reply to comment #28) > Can we remove the MALLOC_CHECK_ workaround when running KDE 4.5.1 or do we need > to wait for a fix in SWT? Try running env | grep MALLOC and see if it gives you any output in 4.5.1. On my system MALLOC_CHECK_ is no longer set, so it should work. The problem seems to be an invalid call to free() without consequences, however I would like to hear a statement from the SWT team.
Still happening on my OpenSuSE (64bit) system, KDE 4.4.4. Crashes within seconds with my fairly large project tree. But I noticed that it first started happening after I upgraded the Sun java packages **From** > java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) **To** 1.6.0_23 and, today, to 1.6.0_24: > java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Workaround: Roll back the java package to 1.6.0_22. Works 100% of the time when I do this rollback.
*** Bug 346592 has been marked as a duplicate of this bug. ***
*** Bug 319438 has been marked as a duplicate of this bug. ***
Arun, please take a look at this problem. thank you.
Hello everyone, I'm using KDE 4.7.x (trunk version) and also my java version is 1.6.0_26. So this bug still exist, is anyone still debugging this issue ? thanks, behzat.
(In reply to comment #34) > Hello everyone, > > I'm using KDE 4.7.x (trunk version) and also my java version is 1.6.0_26. So > this bug still exist, is anyone still debugging this issue ? > > thanks, > behzat. Confirmed with latest stable KDE (4.7.3) and MALLOC_CHECK_=0 workaround works for me.
This is still an issue with 3.7.1 . Let me know if I can assist with extra debug information.
Removed myself from the cc-list because I have dropped Linux/KDE as a development platform... (desktop) Now only use it as a server, to run the code.
I can confirm this on KDE 4.7.2 and Eclipse 3.7.1. The workaround works.
*** Bug 364824 has been marked as a duplicate of this bug. ***
*** Bug 364862 has been marked as a duplicate of this bug. ***
I also am seeing this bug. System info: $ kwin --version Qt: 4.7.4 KDE Development Platform: 4.7.2 (4.7.2) "release 5" KWin: 4.7.2 (4.7.2) "release 5" $ uname -a Linux Socrates 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | egrep 'java|glibc' | sort glibc-2.14.1-14.12.5.x86_64 glibc-32bit-2.14.1-14.12.2.x86_64 glibc-devel-2.14.1-14.12.5.x86_64 glibc-locale-2.14.1-14.12.5.x86_64 glibc-locale-32bit-2.14.1-14.12.2.x86_64 jakarta-commons-daemon-java-1.0.7-2.1.2.noarch java-1_6_0-openjdk-1.6.0.0_b22.1.10.4-1.2.x86_64 java-1_6_0-openjdk-devel-1.6.0.0_b22.1.10.4-1.2.x86_64 java-ca-certificates-1-14.12.1.noarch libjavascriptcoregtk-1_0-0-1.6.1-2.1.2.x86_64 libjavascriptcoregtk-3_0-0-1.6.1-2.1.2.x86_64 linux-glibc-devel-3.1_rc5-7.1.1.noarch timezone-java-2011n-1.1.1.noarch Eclipse Build id: 20110916-0149 The system is OpenSuSE 12.1 and the most recent (as of earlier today) security/reliability patches are installed. Note that the pattern appears to be somewhat of a red herring: $ ls *.f* ls: cannot access *.f*: No such file or directory The directory where the project is that is crashing eclipse is a LaTeX book project and I am (trying to) using TeXlipse, not that this last information is likely to be relevant to the bug. Setting MALLOC_CHECK_ to 0 does cause it to not crash. I will attach the crash log momentarily.
Created attachment 207621 [details] Crash log including stack and memory dump I started eclipse, did Help->About eclipse to get the version, and then tried to open the directory. It then crashed with these data.
Confirmed this bug on OpenSuse 12.1 and Gnome 3.2 Apparently this is NOT KDE related then.. Of course it could be something that KDE and GNOME have in common but at least the MALLOCK_CHECK_ = 0 workaround works for me! Strange bug though, it only happened in the configs directory of my php application containing xml and ini files.
*** Bug 365698 has been marked as a duplicate of this bug. ***
I started seeing this crash last week on a Mandriva 2010.2 KDE 4.4.5 system I've been using for two years. I was using Eclipse 3.3, tried upgrading to 3.7.1, but it has the same problem. For me the symptom is really, really clear. I'm doing Java development. As soon as I try to expand a node in the Package Explorer (or any other tree view node), Eclipse just goes away. No crash file, core dump, etc. Just gone. As long as I don't try to manipulate the tree view, I can edit, save, compile, do team updates, install plugins, etc. That suggests to me that this is local to SWT. The good news is that because this is not the latest release of Mandriva, there have been very few updates lately. I believe I can trace it precisely to a glibc update I installed on 28 November. Nothing else I have changed or installed since would be meaningful. The glibc currently installed is 2.11.1, and the Mandriva RPM package is called glibc-2.11.1-8.3mnb2. Other relevant parameters: i7-2700 processor, 8GB RAM, Mandriva 2010.2 with all latest updates. KDE 4.4.5, JDK 1.6.0_29, Eclipse 3.7.1 (M20110909-1335). I hope this helps you narrow it down. Happy to provide more info if I can. And BTW, the MALLOC_CHECK_=0 workaround does get me past the problem. THANKS!
(In reply to comment #45) > I started seeing this crash last week on a Mandriva 2010.2 KDE 4.4.5 system > I've been using for two years. I was using Eclipse 3.3, tried upgrading to > 3.7.1, but it has the same problem. > > For me the symptom is really, really clear. I'm doing Java development. As soon > as I try to expand a node in the Package Explorer (or any other tree view > node), Eclipse just goes away. No crash file, core dump, etc. Just gone. As > long as I don't try to manipulate the tree view, I can edit, save, compile, do > team updates, install plugins, etc. That suggests to me that this is local to > SWT. > > The good news is that because this is not the latest release of Mandriva, there > have been very few updates lately. I believe I can trace it precisely to a > glibc update I installed on 28 November. Nothing else I have changed or > installed since would be meaningful. > > The glibc currently installed is 2.11.1, and the Mandriva RPM package is called > glibc-2.11.1-8.3mnb2. > > Other relevant parameters: i7-2700 processor, 8GB RAM, Mandriva 2010.2 with all > latest updates. KDE 4.4.5, JDK 1.6.0_29, Eclipse 3.7.1 (M20110909-1335). > > I hope this helps you narrow it down. Happy to provide more info if I can. > > And BTW, the MALLOC_CHECK_=0 workaround does get me past the problem. THANKS! I have the same problems here (with x86_64 OpenSuse 11.4). I need to deactivate malloc checks. There might be a relation with bug 358240: the release operation of a combo box releases an object that has already been released by native GTK code. Although the error here is not specific to a combo box, the described behavior looks pretty much the same (some native gtk functions release objects while java still points to them and release them a 2nd time).
This crash seems to happen because Java_org_eclipse_swt_internal_gtk_OS__1g_1data_1input_1stream_1read_1line uses the wrong type for the second parameter to g_data_input_stream_read_line. See [1]: g_data_input_stream_read_line (GDataInputStream *stream, gsize *length, GCancellable *cancellable, GError **error) the second parameter is of type gsize. Which, according to [2], "... is wide enough to hold the numeric value of a pointer ...". However, the argument passed in (lparg1) is derived from an int[] array instead of a long[], which is needed on 64 bit platforms.So, g_data_input_stream_read_line receives a 'length' pointer pointing at a too small memory chunk and ends up writing outside the mallocated memory. When the memory later is released, memory checkers see that the memory has been stomped and we get this crash. [1] https://git.gnome.org/browse/glib/tree/gio/gdatainputstream.c [2] https://git.gnome.org/browse/glib/tree/glib/docs.c
(In reply to comment #47) > This crash seems to happen because > Java_org_eclipse_swt_internal_gtk_OS__1g_1data_1input_1stream_1read_1line > uses the wrong type for the second parameter to > g_data_input_stream_read_line. > Thanks a ton for pointing this out! This indeed seems to be the cause of the crash and I have pushed a fix into the 4.4 stream - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cf7558133e9e953c3fd81604968f20b582949c42 However, I wasn't able to reproduce this crash with Eclipse 4.3 on my Linux setup and so cannot verify the fix. It'll be great if anyone who is actually seeing this crash can test the next N-build or I-build to verify whether this fix works. I'll backport the fix into Eclipse 4.3.1 once it is verified and will leave the bug open till then.
(In reply to comment #48) > (In reply to comment #47) > > This crash seems to happen because > > Java_org_eclipse_swt_internal_gtk_OS__1g_1data_1input_1stream_1read_1line > > uses the wrong type for the second parameter to > > g_data_input_stream_read_line. > > > > Thanks a ton for pointing this out! This indeed seems to be the cause of the > crash and I have pushed a fix into the 4.4 stream - > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=cf7558133e9e953c3fd81604968f20b582949c42 > gsize is not always a java long (only on 64 bit). You needs to be declared like this in OS and Program: long /*int*/ [] count
(In reply to comment #48) > However, I wasn't able to reproduce this crash with Eclipse 4.3 on my Linux > setup and so cannot verify the fix. It'll be great if anyone who is actually > seeing this crash can test the next N-build or I-build to verify whether this > fix works. I'll backport the fix into Eclipse 4.3.1 once it is verified and will > leave the bug open till then. I _think_ that this happens only when _MALLOC_CHECK is set to 2, see http://www.novell.com/support/kb/doc.php?id=3113982 .
(In reply to comment #49) > > gsize is not always a java long (only on 64 bit). You needs to be declared > like this in OS and Program: > > long /*int*/ [] count Sorry my bad! I assumed gsize is always defined as long based on the typedef as defined in [1] - typedef unsigned long gsize; On a closer look, it indeed needs to be 32-bit on 32-bit platforms and 64-bit on 64-bit platforms only. Fixed in master - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=32018a23dcca329752faf81300feb169d09b6240 Thanks for catching it Silenio! [1] https://developer.gnome.org/glib/2.34/glib-Basic-Types.html#gsize
(In reply to comment #50) > (In reply to comment #48) > > > However, I wasn't able to reproduce this crash with Eclipse 4.3 on my Linux > > setup and so cannot verify the fix. It'll be great if anyone who is actually > > seeing this crash can test the next N-build or I-build to verify whether this > > fix works. I'll backport the fix into Eclipse 4.3.1 once it is verified and will > > leave the bug open till then. > > I _think_ that this happens only when _MALLOC_CHECK is set to 2, see > http://www.novell.com/support/kb/doc.php?id=3113982 . Just wanted to update that I wasn't able to reproduce the crash even with 'export MALLOC_CHECK_=2' on Ubuntu 12.04 64-bit machine and Eclipse 4.3 (Build Id: I20130605-2000).
(In reply to comment #52) > Just wanted to update that I wasn't able to reproduce the crash even with > 'export MALLOC_CHECK_=2' on Ubuntu 12.04 64-bit machine and Eclipse 4.3 (Build > Id: I20130605-2000). I've looked up the original OpenSUSE bug reports ( https://bugzilla.novell.com/show_bug.cgi?id=616663 , https://bugzilla.novell.com/show_bug.cgi?id=731075 ) , and apparently the value which triggers the crash is MALLOC_CHECK_=3 . Alternatively you can also try MALLOC_PERTURB_=69 .
+1 to back port to 4.3.1
Fixed in R4_3_maintenance - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_3_maintenance&id=01108580242eb0bf3cd55685b8c7bcf239520457 & http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_3_maintenance&id=9e1e1310d824bf99e5f3c1ff03090123f33905c9
