If you have built Eclipse (/usr/ports/java/eclipse) with GTK and GnomeVFS, it doesn't work, it crash on sigbus 10 while starting. I've updated many of my libraries, and all dependencies are satisfied. I use a native FreeBSD JavaVM and compiler (SunJDK1.4.2) which works with other programs. Versions of some of my libraries: 0x34bf6000 /usr/X11R6/lib/libgtk-x11-2.0.so.400 0x34ecb000 /usr/X11R6/lib/libgdk-x11-2.0.so.400 0x34f55000 /usr/local/lib/libatk-1.0.so.600 0x35195000 /usr/local/lib/libgmodule-2.0.so.400 .... Here is the trace of the crash: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x34DFADEF Function=_gtk_tree_view_queue_draw_node+0x1716 Library=/usr/X11R6/lib/libgtk-x11-2.0.so.400 Current Java thread: at org.eclipse.swt.internal.gtk.OS.gtk_container_add(Native Method) - locked <0x30840450> (a java.lang.Class) at org.eclipse.swt.widgets.Tree.createHandle(Tree.java:249) at org.eclipse.swt.widgets.Widget.createWidget(Widget.java:321) at org.eclipse.swt.widgets.Control.createWidget(Control.java:306) [...] at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:183) at org.eclipse.core.launcher.Main.run(Main.java:644) at org.eclipse.core.launcher.Main.main(Main.java:628) Dynamic libraries: 0x8048000 /usr/local/jdk1.4.2/bin/java 0x28086000 /usr/lib/libpthread.so.1 0x280ab000 /lib/libc.so.5 ... 0x2804e000 /libexec/ld-elf.so.1 Heap at VM Abort: Heap def new generation total 640K, used 432K [0x2c480000, 0x2c530000, 0x2c960000) eden space 576K, 65% used [0x2c480000, 0x2c4deba8, 0x2c510000) from space 64K, 83% used [0x2c520000, 0x2c52d510, 0x2c530000) to space 64K, 0% used [0x2c510000, 0x2c510000, 0x2c520000) tenured generation total 8120K, used 5303K [0x2c960000, 0x2d14e000, 0x30480000) the space 8120K, 65% used [0x2c960000, 0x2ce8de40, 0x2ce8e000, 0x2d14e000) compacting perm gen total 9728K, used 9660K [0x30480000, 0x30e00000, 0x34480000) the space 9728K, 99% used [0x30480000, 0x30def010, 0x30def200, 0x30e00000) Local Time = Tue Sep 21 22:59:55 2004 Elapsed Time = 15 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2-p6-root_21_sep_2004_19_58 mixed mode) # Fix: It's just a work around, and it doesn't resolve the problem at all. You can use Eclipse if you install it without GTK: make WITH_MOTIF=1 WITHOUT_GNOMEVFS=1 install How-To-Repeat: Build Eclipse with GTK and GNOMEVFS2 (default options if you type make)
Responsible Changed From-To: freebsd-ports-bugs->java Over to maintainer.
Responsible Changed From-To: java->freebsd-java All other PRs like this are assigned to freebsd-java, not java, so join the crowd.
Hello! Could please those who have problems with eclipse SigBus'ing in _gtk_tree_view_queue_draw_node (or other gtk methods) send me their compiler options (/etc/make.conf) used for gtk and jdk builds. p.s. I'm not on the list, so keep me on To: or Cc: if posting to list. -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University.
Le Thu, Nov 25, 2004 at 01:07:56PM +0300, Oleg Sharoiko a ecrit: > Could please those who have problems with eclipse SigBus'ing in > _gtk_tree_view_queue_draw_node (or other gtk methods) send me their > compiler options (/etc/make.conf) used for gtk and jdk builds. > p.s. I'm not on the list, so keep me on To: or Cc: if posting to list. Here are mine's. Moreover, as I'm french, i use accents like é, è, and the "motif" theme for eclipse cut word where i've accents, it's quite boring, but i suppose it's another problem. Thanks if you solve this bug, or if you could help me. I'me currently using latest native FreeBSD Sun JDK (1.4.2p6_6). make.conf --------- PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo NO_SENDMAIL= true COMPAT4X= yes CPUTYPE?=p4 DOC_LANG= en_US.ISO8859-1 fr_FR.ISO8859-1 fr_FR.ISO8859-15 NOPROFILE= true # Avoid compiling profiled libraries CFLAGS= -O -pipe COPTFLAGS= -O -pipe #X_WINDOW_SYSTEM=xfree86-4 X_WINDOW_SYSTEM=xorg -- Nicolas Le Scouarnec
Hello! I'm sorry for flooding three lists at a time, but I have some information concerning ports/72014 and it looks like I've reached that point where I can't do further investigation. So I hope someone who has more knowledge, experience and free time will handle this further. I made some investigation of this bug and it looks like it is cased by gtk built with CPUTYPE=p4. Eclipse works fine after changing CPUTYPE to i686 and rebuilding/reinstalling gtk. This is true for my P4 box and this was also confirmed by two other testers who faced similar problem. Eclipse also works fine with CPUTYPE=athlon-xp (my amd based box at work). So I think this is gcc bug which leads to wrong code in gtk, and I suppose it can lead to other bugs with gtk. I've seen SIGBUSes in _gtk_tree_view_queue_draw_node and gtk_tree_view_get_column with -O0/-O and -O2 respectively. I'm not sure what should be done further. I thought of following: - building debug version of gtk, looking what arguments are passed to those functions and trying to create a test case to submit bug report to gcc team; - trying to build gtk with more recent gcc; - downgrade CPUTYPE from p4 to i686 in x11-toolkits/gtk20 until this problem is solved. Unfortunately I don't have any gtk development experience and I don't know what should be the best solution for this problem. I'm posting results of my investigation in hope that someone will handle this bug further. p.s. And I think this is not freebsd-java bug, so responsible in PR database should be changed to someone else. p.p.s. I'm not on the lists, so keep me on To: or Cc: lines if you want to reply me. p.p.p.s This mail is probably in a mess a little bit. Sorry, I couldn't put it into right words. -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University.
Hello, I submit this PR some month ago. I finally tried to compile all this stuff (eclipse and gtk2) with CPUTYPE?=p4. It works, so this PR can be closed as the bug has been fixed with newer GCC. I am currently running FreeBSD 5.4 -- Nicolas Le Scouarnec
Hello I made a mistake, Eclipse and GTK still not work if GTK is compiled while CPUTYPE is set to p4. In fact, it would have been surprising as gcc hasn't been upgraded since I got the problem. I'm using gcc (GCC) 3.4.2 [FreeBSD] 20040728. I can give some more information, as the situation changed a little for me. I didn't try to use a lot Eclipse compiled with GTK (CPUTYPE=p4), but it seemed to work (before Eclipse crashed before I could see the main window) and only crashed when I tryed to see "Installed JRE" in the Java tab in the Preference window. So, this PR has to stay open. To be tested later. Sorry. -- Nicolas Le Scouarnec
Eclipse has been crashing on me at random intervals in the exact same way lately, always within random functions in GTK, using both native JDK 1.4 and 1.5. I built my ports with CPUTYPE?=pentium-m and CFLAGS=-O -pipe in /etc/make.conf. Rebuilding only GTK without CPUTYPE?=pentium-m fixed the problem for me. This seems to confirm the earlier analysis by Oleg Sharoiko, and adds pentium-m to the list of CPUTYPEs which break GTK. This is FreeBSD 5.4-RELEASE-p6 with gcc-3.4.2 and current ports tree (gtk-2.6.9, eclipse-3.1, jdk-1.4.2p7_1 and jdk-1.5.0p1_3) http://www.freebsd.org/cgi/query-pr.cgi?pr=72014 -- Daniel Roethlisberger
It seems that this behavior is similar to the one mentioned in the eclipse bugzilla (https://bugs.eclipse.org/bugs) item #79618. This bug report contains two more references to gcc bug reports: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21973 Their theory is that the bug "may be caused by the Sun VM not aligning its stack when calling into JNI code". They also mention that compiling gtk libraries with -mno-sse2 seemed to help. Perhaps the reporters of this bug could prove or disprove this theory for our case. Panagiotis
Responsible Changed From-To: freebsd-java->freebsd-eclipse Over to maintainer(s).
I have just double checked on my pentium-m box, I can confirm that adding -mno-sse2 does solve the problem for me (at least as far as I can tell, as there is no definitive way to reproduce the problem). Compiling x11-toolkits/gtk20 with CPUTYPE?=pentium-m and CFLAGS=-O -pipe results in an unstable eclipse, while compiling gtk20 with the same CPUTYPE but CFLAGS=-O -pipe -mno-sse2 saves the day, giving me a stable eclipse. Can we add some kind of -mno-sse2 hack to the GTK port for the time being, or is there a better solution? -- Daniel Roethlisberger
I'm forwarding this to the people who are responsible for this. Daniel Roethlisberger wrote: > I have just double checked on my pentium-m box, I can confirm that > adding -mno-sse2 does solve the problem for me (at least as far as I can > tell, as there is no definitive way to reproduce the problem). > > Compiling x11-toolkits/gtk20 with CPUTYPE?=pentium-m and CFLAGS=-O -pipe > results in an unstable eclipse, while compiling gtk20 with the same > CPUTYPE but CFLAGS=-O -pipe -mno-sse2 saves the day, giving me a stable > eclipse. > > Can we add some kind of -mno-sse2 hack to the GTK port for the time > being, or is there a better solution? Some background: In PR ports/72014 it was reported a long time ago that eclipse/gtk crashes and this was tracked down to non-standard compiler optimizations when building gtk. There have been similar bug reports filed against the eclipse and gcc bug databases. Some gcc people have tracked it down to incorrect stack alignment (see ports/72014 for the pointers) and have received reports that using -mno-sse2 fixed it. Daniel has verified that this seems to help our case also. Therefore the question is, should we force -mno-sse2 to the compiler flags for the gtk ports? I would expect less bug reports from people who compile gtk apps with non-standard CFLAGS, at least. Cheers, Panagiotis
On Fri, 02 Sep 2005 04:40:15 -0500, Panagiotis Astithas <past@ebs.gr> wrote: > I'm forwarding this to the people who are responsible for this. > > Daniel Roethlisberger wrote: >> I have just double checked on my pentium-m box, I can confirm that >> adding -mno-sse2 does solve the problem for me (at least as far as I can >> tell, as there is no definitive way to reproduce the problem). >> Compiling x11-toolkits/gtk20 with CPUTYPE?=pentium-m and CFLAGS=-O >> -pipe >> results in an unstable eclipse, while compiling gtk20 with the same >> CPUTYPE but CFLAGS=-O -pipe -mno-sse2 saves the day, giving me a stable >> eclipse. >> Can we add some kind of -mno-sse2 hack to the GTK port for the time >> being, or is there a better solution? > > > Some background: > > In PR ports/72014 it was reported a long time ago that eclipse/gtk > crashes and this was tracked down to non-standard compiler optimizations > when building gtk. There have been similar bug reports filed against the > eclipse and gcc bug databases. Some gcc people have tracked it down to > incorrect stack alignment (see ports/72014 for the pointers) and have > received reports that using -mno-sse2 fixed it. Daniel has verified that > this seems to help our case also. It's a nice find the locate that SSE2 is causing the problem. Mono/gtk-sharp have the same problems and we always have to tell them to not tweak the CPUTYPE. After look at our PR and GCC's PRs, looks like might be either GCC or our libc bug. > Therefore the question is, should we force -mno-sse2 to the compiler > flags for the gtk ports? I would expect less bug reports from people who > compile gtk apps with non-standard CFLAGS, at least. It's good idea, I would like to add -mno-sse2 too. Here's patch, so let me know if I don't understand it correct or/and my English isn't right. http://people.freebsd.org/~mezz/diff/gtk20.diff Keep in mind, this patch is for MC. After that go in MC and I will put in offical one too. Cheers, Mezz > Cheers, > > Panagiotis -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
On Fri, 02 Sep 2005 12:17:48 -0500, Jeremy Messenger <mezz7@cox.net> wrote: > On Fri, 02 Sep 2005 04:40:15 -0500, Panagiotis Astithas <past@ebs.gr> > wrote: > >> I'm forwarding this to the people who are responsible for this. >> >> Daniel Roethlisberger wrote: >>> I have just double checked on my pentium-m box, I can confirm that >>> adding -mno-sse2 does solve the problem for me (at least as far as I >>> can >>> tell, as there is no definitive way to reproduce the problem). >>> Compiling x11-toolkits/gtk20 with CPUTYPE?=pentium-m and CFLAGS=-O >>> -pipe >>> results in an unstable eclipse, while compiling gtk20 with the same >>> CPUTYPE but CFLAGS=-O -pipe -mno-sse2 saves the day, giving me a stable >>> eclipse. >>> Can we add some kind of -mno-sse2 hack to the GTK port for the time >>> being, or is there a better solution? >> >> >> Some background: >> >> In PR ports/72014 it was reported a long time ago that eclipse/gtk >> crashes and this was tracked down to non-standard compiler >> optimizations when building gtk. There have been similar bug reports >> filed against the eclipse and gcc bug databases. Some gcc people have >> tracked it down to incorrect stack alignment (see ports/72014 for the >> pointers) and have received reports that using -mno-sse2 fixed it. >> Daniel has verified that this seems to help our case also. > > It's a nice find the locate that SSE2 is causing the problem. > Mono/gtk-sharp have the same problems and we always have to tell them to > not tweak the CPUTYPE. After look at our PR and GCC's PRs, looks like > might be either GCC or our libc bug. > >> Therefore the question is, should we force -mno-sse2 to the compiler >> flags for the gtk ports? I would expect less bug reports from people >> who compile gtk apps with non-standard CFLAGS, at least. > > It's good idea, I would like to add -mno-sse2 too. Here's patch, so let > me know if I don't understand it correct or/and my English isn't right. I have committed it in both MC and offical ports tree. Cheers, Mezz > http://people.freebsd.org/~mezz/diff/gtk20.diff > > Keep in mind, this patch is for MC. After that go in MC and I will put > in offical one too. > > Cheers, > Mezz > >> Cheers, >> >> Panagiotis -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Jeremy Messenger wrote: > On Fri, 02 Sep 2005 12:17:48 -0500, Jeremy Messenger <mezz7@cox.net> wrote: > >> On Fri, 02 Sep 2005 04:40:15 -0500, Panagiotis Astithas <past@ebs.gr> >> wrote: >> >>> I'm forwarding this to the people who are responsible for this. >>> >>> Daniel Roethlisberger wrote: >>> >>>> I have just double checked on my pentium-m box, I can confirm that >>>> adding -mno-sse2 does solve the problem for me (at least as far as >>>> I can >>>> tell, as there is no definitive way to reproduce the problem). >>>> Compiling x11-toolkits/gtk20 with CPUTYPE?=pentium-m and CFLAGS=-O >>>> -pipe >>>> results in an unstable eclipse, while compiling gtk20 with the same >>>> CPUTYPE but CFLAGS=-O -pipe -mno-sse2 saves the day, giving me a stable >>>> eclipse. >>>> Can we add some kind of -mno-sse2 hack to the GTK port for the time >>>> being, or is there a better solution? >>> >>> >>> >>> Some background: >>> >>> In PR ports/72014 it was reported a long time ago that eclipse/gtk >>> crashes and this was tracked down to non-standard compiler >>> optimizations when building gtk. There have been similar bug reports >>> filed against the eclipse and gcc bug databases. Some gcc people >>> have tracked it down to incorrect stack alignment (see ports/72014 >>> for the pointers) and have received reports that using -mno-sse2 >>> fixed it. Daniel has verified that this seems to help our case also. >> >> >> It's a nice find the locate that SSE2 is causing the problem. >> Mono/gtk-sharp have the same problems and we always have to tell them >> to not tweak the CPUTYPE. After look at our PR and GCC's PRs, looks >> like might be either GCC or our libc bug. >> >>> Therefore the question is, should we force -mno-sse2 to the compiler >>> flags for the gtk ports? I would expect less bug reports from people >>> who compile gtk apps with non-standard CFLAGS, at least. >> >> >> It's good idea, I would like to add -mno-sse2 too. Here's patch, so >> let me know if I don't understand it correct or/and my English isn't >> right. > > > I have committed it in both MC and offical ports tree. > > Cheers, > Mezz Excellent, thanks! Now if someone who has reported this issue could verify that the updated gtk fixes ports/72014 we could close that, too. Thanks, Panagiotis
Hi, I used to have to set CPUTYPE to p3 or i686, after I started using -mno-sse2 for gtk Eclipse (3.1) has worked like a charm with CPUTYPE=p4 System: FreeBSD tos.teleplan.no 5.4-STABLE FreeBSD 5.4-STABLE #4: Wed Jun 22 14:53:16 CEST 2005 root@tos.teleplan.no:/usr/obj/usr/src/sys/latitude i386 Cheers, Tom
Panagiotis Astithas <past@ebs.gr> 2005-09-04: > Now if someone who has reported this issue could verify that the > updated gtk fixes ports/72014 we could close that, too. The updated GTK gives me a stable eclipse with CPUTYPE?=pentium-m. As far as I'm concerned, ports/72014 can be closed, though the real source of the problem is still not fixed, whether it's GCC, libc, GTK or JDK, so maybe the PR should be suspended instead? -- Daniel Roethlisberger
State Changed From-To: open->closed Closed on submitters request.