From cagney@redhat.com Tue Jan 3 16:18:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 03 Jan 2006 16:18:00 -0000 Subject: New module: frysk-gtk? Message-ID: <43BAA33E.3030704@redhat.com> aka frysk.gtk.* Hello, fallout from gosiping with developers; Since of the objectives is for the frysk core to be buildable and runnable on a headless system (i.e., on a non-gui machine interacting with a remote frysk gui interface), it is important that it be possible to build frysk's core without requiring gui components. With that in mind, I'd like to propose a new module frysk-gtk (frysk/gtk/; frysk.gtk) that would contain any frysk specific GTK bindings; all the existing gtk bindings found in frysk-imports would be moved there. Doing this would mean that frysk-imports, and consequently frysk-core, is no longer dependant on gtk and that greatly simplifying a headless build. thoughts? Andrew From woodzltc@cn.ibm.com Wed Jan 4 02:48:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 04 Jan 2006 02:48:00 -0000 Subject: NullPointerException at inua.elf.PrintNote.print(inua.PrintWriter) Message-ID: Happy new year, Frysk developers! I am playing with Frysk. Although I don't get any successful experience of getting Frysk to report anything when an observed process terminates, But I do find something interesting. The inua package is one of them. But I met a nullpointer exception when playing with readelf. Here is the failing scenario: ./readelf -n addr2line Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException at inua.util.readelf.main(java.lang.String[]) (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/util/readelf.java:67) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) Caused by: java.lang.NullPointerException at inua.elf.PrintNote.print(inua.PrintWriter) (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/elf/PrintNote.java:64) at inua.util.readelf.main(java.lang.String[]) (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/util/readelf.java:172) ...2 more Other options seem to work ok. What is the problem? Regards - Wu Zhou From woodzltc@cn.ibm.com Wed Jan 4 12:56:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 04 Jan 2006 12:56:00 -0000 Subject: NullPointerException at inua.elf.PrintNote.print(inua.PrintWriter) In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Wu Zhou wrote: > Happy new year, Frysk developers! > > I am playing with Frysk. Although I don't get any successful experience > of getting Frysk to report anything when an observed process terminates, > But I do find something interesting. The inua package is one of them. > But I met a nullpointer exception when playing with readelf. Here is the > failing scenario: > > ./readelf -n addr2line > Exception in thread "main" java.lang.RuntimeException: > java.lang.NullPointerException > at inua.util.readelf.main(java.lang.String[]) > (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/util/readelf.java:67) > at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) > at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) > Caused by: java.lang.NullPointerException > at inua.elf.PrintNote.print(inua.PrintWriter) > (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/elf/PrintNote.java:64) > at inua.util.readelf.main(java.lang.String[]) > (/usr/src/redhat/BUILD/frysk-0.0.1.2005.12.14.15.12/frysk-0.0.1.2005.12.14.15.12/frysk-imports/inua/util/readelf.java:172) > ...2 more > > Other options seem to work ok. > > What is the problem? I think I had found the reason. The following patch could fix this: *** ./PrintNote.java.old 2006-01-04 20:01:13.000000000 +0800 --- ./PrintNote.java 2006-01-04 20:01:57.000000000 +0800 *************** public class PrintNote *** 53,59 **** for (int i = 0; i < phdrs.length; i++) { Phdr phdr = phdrs[i]; Note[] notes = phdr.asNotes (); ! if (notes == null) { o.print ("Notes at offset 0x"); o.printx (8, '0', phdr.offset); o.print (" with length 0x"); --- 53,59 ---- for (int i = 0; i < phdrs.length; i++) { Phdr phdr = phdrs[i]; Note[] notes = phdr.asNotes (); ! if (notes != null) { o.print ("Notes at offset 0x"); o.printx (8, '0', phdr.offset); o.print (" with length 0x"); Regards - Wu Zhou From cagney@redhat.com Wed Jan 4 15:54:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 04 Jan 2006 15:54:00 -0000 Subject: Please do a new check-out to pick up frysk-gtk In-Reply-To: <43BAA33E.3030704@redhat.com> References: <43BAA33E.3030704@redhat.com> Message-ID: <43BBEF0E.2080300@redhat.com> Hello, Phill gave it thumbs up :-) Frysk's CVS modules list has been updated to include frysk-gtk. While the directory is currently empty (well apart from common/), it will shortly contain all the gtk specific code. To pick up this new directory you'll need to do a clean checkout. Andrew From cagney@redhat.com Thu Jan 5 17:20:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 05 Jan 2006 17:20:00 -0000 Subject: New RHEL-4 rpm 0.0.1.2005.12.14.15.12-0.EL4.4 Message-ID: <43BD54E5.8060509@redhat.com> FYI, Adam and I have created a new RHEL-4 source rpm: frysk-0.0.1.2005.12.14.15.12-0.EL4.4.src.rpm (see ftp://sources.redhat.com/pub/frysk/RHEL-4). It contains the following changes: * Thu Dec 22 2005 Adam Jocksch 0.0.1.2005.12.14.15.12-0.EL4.4 - updated libgtk-java tarball, bumped release. * Mon Dec 19 2005 Roland McGrath - 0.0.1.2005.12.14.15.12-0.EL4.2 - Avoid improper provides/requires in rpm. most important is the newly imported libgtk-java, that contains fixes that mainline/cvs frysk will soon require. From cagney@redhat.com Sun Jan 8 22:32:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 08 Jan 2006 22:32:00 -0000 Subject: Building on FC-5 Test 2 Message-ID: <43C1928F.1020803@redhat.com> Just a brief update. With the release of Fedora Core 5 Test 2, it should be possible to build and run(1) frysk on that system using just standard RPMs (I successfully built and ran frysk using last nights pre FC-5t2 updates). Andrew (1) FRYKS's testsuite is tickeling an upstream kernel regression: the kernel will spontaneously kill a traced multi-threaded program that does an execve; I guess that will learn us for testing our code :-) From cagney@redhat.com Tue Jan 10 21:27:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 10 Jan 2006 21:27:00 -0000 Subject: RHEL-4 frysk vs FC-5 head packages Message-ID: <43C42659.6060206@redhat.com> What RHEL-4 frysk FC-5 head rpm antlr 2.7.5 antlr-2.7.4-2jpp_5fc interesting glib2 2.8.3 glib2-2.9.2-2 +++ glib_java 0.2.2 glib-java-0.2.2-1 fontconfig 2.3.2 fontconfig-2.3.93-2 +++ a 2.4 pre-release cairo 1.0.0 cairo-1.0.2-3.1 +++ cairo_java 1.0.2 cairo-java-1.0.2-0 pango 1.10.0 pango-1.11.1-2 +++ gtk2 2.8.6 gtk2-2.8.9-1.1 +++ atk 1.9.1 atk-1.10.3-1.1 +++ libgtk_java 2.8.2 libgtk-java-2.8.2-0 libglade 2.5.1 libglade2-2.5.1-3.1 config lacks --without-gnome? libglade_java 2.12.0 libglade-java-2.12.1-3 +++ jg_common 0.1 replaced by glib-java delete? libvte_java 0.11.11 libvte-java-0.11.11-7 jdom 1.0 jdom-1.0-1jpp_2fc.1 From rmoseley@redhat.com Thu Jan 12 00:09:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 12 Jan 2006 00:09:00 -0000 Subject: Start-up sequence Message-ID: <43C559FD.50808@redhat.com> Hi all, Attached is a screenshot of how the proposed Frysk start-up would appear. Basically it is hung off of the "System Tools" menu as proposed by Mike Behm. The icon is a little blurry as I took the icon given us from the graphics person and re-scaled it myself using Gimp from the 20x20 pixel icon to the 48x48 icon depicted in the screenshot. I will be requesting a new version of the icon from graphics that is clearer. Anyways, any comments on this are appreciated. This is just a straw man for now and can be easily modified. I wentt with Mike Behm's suggestion of hanging it off of the "System Tools" menu as that seems the logical place for it IMHO. Thanks, Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_startup.png Type: image/png Size: 75521 bytes Desc: not available URL: From dnovillo@redhat.com Fri Jan 13 22:58:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Fri, 13 Jan 2006 22:58:00 -0000 Subject: Pick up correct lib path when configuring on 64 bit hosts Message-ID: <200601131758.33119.dnovillo@redhat.com> This patch sets up PKG_CONFIG_PATH using lib or lib64 accordingly. I still haven't done a full build, but I checked that the directories are being picked up from .../lib64. OK to install? Index: acinclude.m4 =================================================================== RCS file: /cvs/frysk/frysk-common/acinclude.m4,v retrieving revision 1.33 diff -d -u -p -r1.33 acinclude.m4 --- acinclude.m4 11 Dec 2005 01:42:29 -0000 1.33 +++ acinclude.m4 13 Jan 2006 22:54:55 -0000 @@ -80,4 +80,5 @@ test "x$FIG2DEV" = x && AC_MSG_ERROR([no AM_PROG_AS -export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/lib/pkgconfig:/usr/lib/frysk/pkgconfig +lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` +export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig From dnovillo@redhat.com Sat Jan 14 01:40:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Sat, 14 Jan 2006 01:40:00 -0000 Subject: Fix build on x86-64 Message-ID: <200601132040.55935.dnovillo@redhat.com> With this patch I can build frysk on x86-64. I tried launching the GUI, but this is a remote box and some X applications do not launch properly via the ssh forwarded X11 settings. I got these failures from 'make check'. Not sure whether they're important: FAIL: anoncall/a.out FAIL: rh174912ice/gcj.sh FAIL: wrongclass/gcj.sh FAIL: cdtparserversion/cdttest.sh FAIL: TestRunner FAIL: textiter/a.out Most of the changes in the patch are just the replicated patch to common/acinclude.m4. OK to install? -------------- next part -------------- A non-text attachment was scrubbed... Name: 20060113-x86_64-fixes.diff Type: text/x-diff Size: 6066 bytes Desc: not available URL: From woodzltc@cn.ibm.com Sat Jan 14 04:59:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sat, 14 Jan 2006 04:59:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <200601132040.55935.dnovillo@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> Message-ID: On Fri, 13 Jan 2006, Diego Novillo wrote: > With this patch I can build frysk on x86-64. I tried launching the GUI, > but this is a remote box and some X applications do not launch properly > via the ssh forwarded X11 settings. I can also build frysk on a ppc64 box with some workaround. Maybe I can code a patch for that too? > I got these failures from 'make check'. Not sure whether they're > important: > > FAIL: anoncall/a.out > FAIL: rh174912ice/gcj.sh > FAIL: wrongclass/gcj.sh > FAIL: cdtparserversion/cdttest.sh > FAIL: TestRunner > FAIL: textiter/a.out I'd also want to know what impact they will bring up. I am guessing that they are relating to why I can't get frysk to work as expected on my x86 box. I got most of these failure on x86 too: the first four is in the frysk-imports directy, the same as the first four of the above; another one is in frysk-gtk directory, the same as the last one of above. On ppc64, I get a ICE while build cniinner, which make the building of frysk fail. If comment out cniinner in frysk-imports/test/Makefile, it built ok. Regards - Wu Zhou From cagney@redhat.com Sat Jan 14 07:01:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 14 Jan 2006 07:01:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <200601132040.55935.dnovillo@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> Message-ID: <43C8A151.4010900@redhat.com> Diego Novillo wrote: > >OK to install? > > definitly! thanks >------------------------------------------------------------------------ > >2006-01-13 Diego Novillo > >common/ > > * acinclude.m4: Use lib64 if appropriate. > > >frysk-gtk/tlwidgets/ > > * Makefile.am (CFLAGS): Add -fPIC -DPIC. > (ftkstripchart.o, ftkconsole.o): Use. > (Stripchart.o): Add -fPIC. > > > From cagney@redhat.com Sat Jan 14 07:09:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 14 Jan 2006 07:09:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> Message-ID: <43C8A34B.7080507@redhat.com> (oops sourceware bounced my last reply, attempt two) I've put a patched gcc 4.0.x tar-ball up in ftp://sources.redhat.com/pub/frysk/RHEL-4/ ; you may want to try it out as an interum. I've updated the build notes to mention this, recommending it for FC-4, RHEL 4 pre U3, and even Ubuntu. > I can also build frysk on a ppc64 box with some workaround. Maybe I can > code a patch for that too? I'm all ears :-) >> I got these failures from 'make check'. Not sure whether they're >> important: >> Given that most of those tests are checking for nasty code-gen bugs; I'd say yes. They are fixed in the RHEL 4 U3 compiler. Andrew From dnovillo@redhat.com Sat Jan 14 15:14:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Sat, 14 Jan 2006 15:14:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <43C8A34B.7080507@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A34B.7080507@redhat.com> Message-ID: <200601141014.02295.dnovillo@redhat.com> On Saturday 14 January 2006 02:07, Andrew Cagney wrote: > Given that most of those tests are checking for nasty code-gen bugs; I'd > say yes. > They are fixed in the RHEL 4 U3 compiler. > OK. I'll try with a newer GCC. I left the frysk binary running overnight and I found this on the screen: $ /usr/local/bin/frysk (java-gnome:10859): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/etc/frysk/pango/pango.modules' You may be able to recreate this file by running pango-querymodules. (java-gnome:10859): Pango-CRITICAL **: _pango_engine_shape_shape: assertion `PANGO_IS_FONT (font)' failed Pango-ERROR **: file /to/scratch/dnovillo/frysk/beehive/frysk/RHEL-4/frysk-0.0.1.2005.12.14.15.12/pango-1.10.0/pango/shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting... Aborted (core dumped) I will try init'ing the machine into runlevel 5, perhaps it's trying to talk to some local daemon and getting confused, though that sounds weird. From dnovillo@redhat.com Sat Jan 14 15:47:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Sat, 14 Jan 2006 15:47:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <200601141014.02295.dnovillo@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A34B.7080507@redhat.com> <200601141014.02295.dnovillo@redhat.com> Message-ID: <200601141047.32470.dnovillo@redhat.com> On Saturday 14 January 2006 10:14, Diego Novillo wrote: > I will try init'ing the machine into runlevel 5, perhaps it's trying to > talk to some local daemon and getting confused, though that sounds > weird. > I setup vncserver on the machine. The abort is definitely related to frysk itself. I'll try debugging next week. From dnovillo@redhat.com Sat Jan 14 16:32:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Sat, 14 Jan 2006 16:32:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <43C91F8A.9000901@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <200601141047.32470.dnovillo@redhat.com> <43C91F8A.9000901@redhat.com> Message-ID: <200601141131.15584.dnovillo@redhat.com> On Saturday 14 January 2006 10:58, Andrew Cagney wrote: > There's some strange behavior with the frysk rpm at present; for some > reason a re-install forgets to add files to /etc; it could be tat. > Un-install/install flushes it. From memory, the file it tries to open > is actually /etc/frysk/pango/i686-redhat-linux-gnu/pango.modules (in > your case x86-64...), an strace will give a definitive answer as to what > wasn't found. > Ah, yes. The problem is that make install created pango.modules in /etc/frysk/pango/i686.../ instead of /etc/frysk/pango/x86_64-... Manually fixing that took me to $ frysk Exception in thread "main" java.lang.NullPointerException at java.lang.Object.getClass() (/usr/lib64/libgcj.so.6.0.0) Progress, of sorts. Will try the new compiler and fix the installation bits for pango. From woodzltc@cn.ibm.com Mon Jan 16 10:47:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 16 Jan 2006 10:47:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <43C8A0F6.3030406@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> Message-ID: On Sat, 14 Jan 2006, Andrew Cagney wrote: > Wu Zhou wrote: > > I've put a patched gcc 4.0.x tar-ball up in > ftp://sources.redhat.com/pub/frysk/RHEL-4/ ; you may want to try it out as an > interum. I've updated the build notes to mention this, recommending it for > FC-4, RHEL 4 pre U3, and even Ubuntu. > > > I can also build frysk on a ppc64 box with some workaround. Maybe I can code > > a patch for that too? > > > I'm all ears :-) OK. Here it is. I tested it on ppc64. The build works ok. ChangeLog: =============== * frysk-ppc64-skip-cniinner.patch: GCJ get an ICE on cniinner, skip it at this time. * frysk.spec (Patch004): Add patch frysk-ppc64-skip-cniinner.patch. (ExclusiveArch): this can able to build on x86, ppc64. Maybe x86-64 too. (patch004): If arch is ppc64, apply frysk-ppc64-skip-cniinner.patch. (prep): The old config.guess in antlr package fail on ppc64. replace it with the shipped config.guess. (prep): %{_libdir} will point to /usr/lib64, but frysk can only build as 32-bits application on ppc64 at this time. (EXPORT): ditto. (build): gtk2 need to link explicitly with libm on ppc64. Don't know why. (post): replace the hard-coded pango modules directory with an arch-dependent one. Patch =============== *** frysk/frysk-imports/tests/Makefile.am Sat Jan 14 17:38:20 2006 --- frysk/frysk-imports/tests/Makefile.am.new Sat Jan 14 17:40:13 2006 *************** *** 94,100 **** $(GCJH) -I. cniinner.Child $(GCJH) -I. 'cniinner.Child$$Nested' $(GCJ) -g -I. -c -o cniinner/native.o $(srcdir)/cniinner/native.cxx ! $(GCJ) -g -I. --main=cniinner.Child -o cniinner/a.out \ $(srcdir)/cniinner/Parent.java \ $(srcdir)/cniinner/Child.java \ cniinner/native.o --- 94,100 ---- $(GCJH) -I. cniinner.Child $(GCJH) -I. 'cniinner.Child$$Nested' $(GCJ) -g -I. -c -o cniinner/native.o $(srcdir)/cniinner/native.cxx ! # $(GCJ) -g -I. --main=cniinner.Child -o cniinner/a.out \ $(srcdir)/cniinner/Parent.java \ $(srcdir)/cniinner/Child.java \ cniinner/native.o *** frysk.spec-4.4 Mon Jan 16 12:52:23 2006 --- frysk.spec Mon Jan 16 17:06:12 2006 *************** *** 53,58 **** --- 53,59 ---- Patch001: frysk-disable-imports-tests.patch Patch002: frysk-head.patch Patch003: frysk-makefileam.patch + Patch004: frysk-ppc64-skip-cniinner.patch Source100: http://www.antlr.org/download/%{antlr}.tar.gz Patch101: antlr.patch Source200: %{atk}.tar.bz2 *************** *** 135,143 **** BuildRequires: vte-devel libgnomeui-devel libgnomecanvas Requires: vte - # Only build on i386 for now - ExclusiveArch: %{ix86} - %description Frysk is an execution-analysis technology implemented using native Java and C++. It is aimed at providing developers and sysadmins with the ability to both --- 136,141 ---- *************** *** 163,168 **** --- 161,169 ---- # %patch001 -p2 -b .disable-imports-tests # %patch002 -p0 -b .head %patch003 -p2 -b .makefileam + %ifarch ppc64 + %patch004 -p1 -b .ppc64-skip-cniinner + %endif ./autogen.sh popd *************** *** 170,175 **** --- 171,179 ---- %setup -D -q -T -c -a100 pushd %{antlr_srcdir} %patch101 -p2 + %ifarch ppc64 + /bin/cp -f `rpm -qil automake | grep config.guess` %{antlr_srcdir}/scripts/config.guess + %endif popd # UNPACK before any java packages, they need these macros/ *************** *** 332,338 **** --- 336,348 ---- # export LD_LIBRARY_PATH and PKG_CONFIG_PATH + %ifarch ppc64 + export PKG_CONFIG_PATH=$RPM_BUILD_ROOT/%{__frysk_libdir}/pkgconfig:%{_prefix}/lib/pkgconfig + %endif + %ifnarch ppc64 export PKG_CONFIG_PATH=$RPM_BUILD_ROOT/%{__frysk_libdir}/pkgconfig:%{_libdir}/pkgconfig + %endif + export LD_LIBRARY_PATH=$RPM_BUILD_ROOT/%{__frysk_libdir} #---------------------------------------------------------------------- *************** *** 366,372 **** --- 376,387 ---- echo export \'CXX=${CXX:-/usr/bin/g++4}\' echo export \'JAVA=${JAVA:-/usr/bin/gij4}\' echo export \'JV_SCAN=${JV_SCAN:-/usr/bin/jv-scan4}\' + %ifarch ppc64 + echo export PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-$RPM_BUILD_ROOT/%{__frysk_libdir}/pkgconfig:%{_prefix}/lib/pkgconfig} + %endif + %ifnarch ppc64 echo export PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-$RPM_BUILD_ROOT/%{__frysk_libdir}/pkgconfig:%{_libdir}/pkgconfig} + %endif echo export LD_LIBRARY_PATH=${LD_LIBRARY_PATH:-$RPM_BUILD_ROOT/%{__frysk_libdir}} } *************** *** 609,615 **** --- 624,635 ---- #------------gtk2------------------------------------------ + %ifarch ppc64 + %define gtk2_makeflags "GDK_PIXBUF_DEP_CFLAGS = %{GLIB_CFLAGS} -I/usr/include/libpng12" "GDK_PIXBUF_DEP_LIBS = %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib} -lm" "GDK_DEP_CFLAGS = -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API %{GLIB_CFLAGS} %{CAIRO_CFLAGS} %{PANGO_CFLAGS}" "GDK_DEP_LIBS = -L/usr/X11R6/lib -lXrandr -lXrender -lXi -lXinerama -lXext -lX11 %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib} %{lib_fontconfig} -ldl -lXcursor -lXrender -lXext -lXfixes -lX11 -lm" "GTK_DEP_CFLAGS = %{GLIB_CFLAGS} %{PANGO_CFLAGS} %{CAIRO_CFLAGS} %{ATK_CFLAGS}" "GTK_DEP_LIBS = -L/usr/X11R6/lib -lX11 %{lib_pangocairo} %{lib_pango} %{lib_atk} %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib} %{lib_cairo} -ldl -lm" "%{glib_cflags}" "GLIB_LIBS = %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib}" "%{cairo_cflags}" "GDK_PIXBUF_XLIB_DEP_CFLAGS = %{GLIB_CFLAGS} -I/usr/X11R6/include" + %endif + %ifnarch ppc64 %define gtk2_makeflags "GDK_PIXBUF_DEP_CFLAGS = %{GLIB_CFLAGS} -I/usr/include/libpng12" "GDK_PIXBUF_DEP_LIBS = %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib}" "GDK_DEP_CFLAGS = -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API %{GLIB_CFLAGS} %{CAIRO_CFLAGS} %{PANGO_CFLAGS}" "GDK_DEP_LIBS = -L/usr/X11R6/lib -lXrandr -lXrender -lXi -lXinerama -lXext -lX11 %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib} %{lib_fontconfig} -ldl -lXcursor -lXrender -lXext -lXfixes -lX11 -lm" "GTK_DEP_CFLAGS = %{GLIB_CFLAGS} %{PANGO_CFLAGS} %{CAIRO_CFLAGS} %{ATK_CFLAGS}" "GTK_DEP_LIBS = -L/usr/X11R6/lib -lX11 %{lib_pangocairo} %{lib_pango} %{lib_atk} %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib} %{lib_cairo} -ldl -lm" "%{glib_cflags}" "GLIB_LIBS = %{lib_gobject} %{lib_gmodule} %{lib_gthread} %{lib_glib}" "%{cairo_cflags}" "GDK_PIXBUF_XLIB_DEP_CFLAGS = %{GLIB_CFLAGS} -I/usr/X11R6/include" + %endif %define gtk2_builddir %{BUILDDIR}/%{gtk2} *************** *** 768,775 **** %post ! mkdir -p %{__frysk_sysconfdir}/pango/i686-redhat-linux-gnu ! %{__frysk_bindir}/frysk-pango-querymodules > %{__frysk_sysconfdir}/pango/i686-redhat-linux-gnu/pango.modules mkdir -p %{__frysk_sysconfdir}/gtk-2.0 %{__frysk_bindir}/frysk-gdk-pixbuf-query-loaders > %{__frysk_sysconfdir}/gtk-2.0/gdk-pixbuf.loaders --- 788,805 ---- %post ! %ifarch ppc64 ! %define arch_pango_modules_dir powerpc64-redhat-linux-gnu ! %endif ! %ifarch %{ix86} ! %define arch_pango_modules_dir i686-redhat-linux-gnu ! %endif ! %ifarch x86_64 ! %define arch_pango_modules_dir x86_64-redhat-linux-gnu ! %endif ! ! mkdir -p %{__frysk_sysconfdir}/pango/%{arch_pango_modules_dir} ! %{__frysk_bindir}/frysk-pango-querymodules > %{__frysk_sysconfdir}/pango/%{arch_pango_modules_dir}/pango.modules mkdir -p %{__frysk_sysconfdir}/gtk-2.0 %{__frysk_bindir}/frysk-gdk-pixbuf-query-loaders > %{__frysk_sysconfdir}/gtk-2.0/gdk-pixbuf.loaders *************** *** 778,784 **** %postun ! rm -f %{__frysk_sysconfdir}/pango/i686-redhat-linux-gnu/pango.modules rm -f %{__frysk_sysconfdir}/gtk-2.0/gdk-pixbuf.loaders /sbin/ldconfig --- 808,814 ---- %postun ! rm -f %{__frysk_sysconfdir}/pango/%{arch_pango_modules_dir}/pango.modules rm -f %{__frysk_sysconfdir}/gtk-2.0/gdk-pixbuf.loaders /sbin/ldconfig Is it ok? Maybe I need to test it on x86. But don't have time today. :-) Regards - Wu Zhou From ezannoni@redhat.com Mon Jan 16 16:14:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Mon, 16 Jan 2006 16:14:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> Message-ID: <17355.49994.273467.765436@localhost.redhat.com> Wu Zhou writes: > OK. Here it is. I tested it on ppc64. The build works ok. When you say tested, do you mean that you ran the testsuite? Can you post the results? > > Maybe I need to test it on x86. But don't have time today. :-) > Yes, that would be a good idea. From woodzltc@cn.ibm.com Tue Jan 17 04:15:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 17 Jan 2006 04:15:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <17355.49994.273467.765436@localhost.redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> Message-ID: On Mon, 16 Jan 2006, Elena Zannoni wrote: > Wu Zhou writes: > > > OK. Here it is. I tested it on ppc64. The build works ok. > > When you say tested, do you mean that you ran the testsuite? Can you > post the results? Hi Elena, I just tested the "rpmbuild -ba" command after applying the patch. It builds ok on ppc64. I can get an installable binary rpm. It will put pango.modules in directory /etc/frysk/pango/powerpc64-redhat-linux-gnu. The program frysk can start successfully, but get some Xlib error occasionally, such as "Xlib: unexpected async reply (sequence 0x14d1). But I had a daily-build script for the cvs tree, which is now using the latest compilers Andrew posted a few days ago. It will generate some log files every days. Maybe that is what you would like to see? I post them here for your reference. ppc64-imports-check.log (cd frysk-imports; make check) Summary: two cases fail. improved a lot than shipped compilers (six failure) ================================================================== mkdir -p nestcall /opt/gccfr/bin/gcj -o nestcall/a.out --main=Nest ../../../frysk/frysk-imports/tests/nestcall/Nest.java mkdir -p samename /opt/gccfr/bin/gcj -g --main=SameName \ ../../../frysk/frysk-imports/tests/samename/SameName.java \ -o samename/a.out mkdir -p packagename /opt/gccfr/bin/gcj -g --main=packagename.O \ ../../../frysk/frysk-imports/tests/packagename/O.java \ -o packagename/O.out mkdir -p werror echo \! /opt/gccfr/bin/gcj -Werror -Wall -c -o /dev/null \ ../../../frysk/frysk-imports/tests/werror/Werror.java \ > werror/java.sh chmod a+x werror/java.sh mkdir -p gcc8544 echo '#!/bin/sh -xe' > gcc8544/gcj.sh.tmp echo /opt/gccfr/bin/gcj -C -d . ../../../frysk/frysk-imports/tests/gcc8544/DisplayRenderer.java ../../../frysk/frysk-imports/tests/gcc8544/StyledText.java >> gcc8544/gcj.sh.tmp chmod a+x gcc8544/gcj.sh.tmp mv gcc8544/gcj.sh.tmp gcc8544/gcj.sh mkdir -p logger /opt/gccfr/bin/gcj -o logger/a.out --main=Npe ../../../frysk/frysk-imports/tests/logger/Npe.java mkdir -p anoncall /opt/gccfr/bin/gcj -o anoncall/a.out --main=Anon ../../../frysk/frysk-imports/tests/anoncall/Anon.java mkdir -p cniinner /opt/gccfr/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Parent.java /opt/gccfr/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Child.java /opt/gccfr/bin/gcjh -I. cniinner.Parent /opt/gccfr/bin/gcjh -I. cniinner.Child /opt/gccfr/bin/gcjh -I. 'cniinner.Child$Nested' /opt/gccfr/bin/gcj -g -I. -c -o cniinner/native.o ../../../frysk/frysk-imports/tests/cniinner/native.cxx mkdir -p packagename /opt/gccfr/bin/gcj -g --main=packagename.C \ ../../../frysk/frysk-imports/tests/packagename/C.java \ -o packagename/C.out mkdir -p werror echo \! g++ -Werror -Wall -c -o /dev/null \ ../../../frysk/frysk-imports/tests/werror/Werror.cxx \ > werror/cxx.sh chmod a+x werror/cxx.sh mkdir -p rh174912 echo '#!/bin/sh -xe' > rh174912/gcj.sh.tmp echo /opt/gccfr/bin/gcj -C -d . ../../../frysk/frysk-imports/tests/rh174912/rh174912.java >> rh174912/gcj.sh.tmp echo /opt/gccfr/bin/gcj -c -I . -o rh174912/rh174912.o rh174912/rh174912.class >> rh174912/gcj.sh.tmp echo /opt/gccfr/bin/gcj -c -I . -o \'rh174912/rh174912\$1.o\' \'rh174912/rh174912\$1.class\' >> rh174912/gcj.sh.tmp chmod a+x rh174912/gcj.sh.tmp mv rh174912/gcj.sh.tmp rh174912/gcj.sh mkdir -p rh174912ice echo '#!/bin/sh -xe' > rh174912ice/gcj.sh.tmp echo /opt/gccfr/bin/gcj -C -I ../../../frysk/frysk-imports/tests -d . ../../../frysk/frysk-imports/tests/rh174912ice/T.java >> rh174912ice/gcj.sh.tmp echo /opt/gccfr/bin/gcj -c -I ../../../frysk/frysk-imports/tests -I . rh174912ice/T.class >> rh174912ice/gcj.sh.tmp chmod a+x rh174912ice/gcj.sh.tmp mv rh174912ice/gcj.sh.tmp rh174912ice/gcj.sh mkdir -p rh175569 echo '#!/bin/sh -xe' > rh175569/gcj.sh.tmp echo /opt/gccfr/bin/gcj -C -d rh175569 ../../../frysk/frysk-imports/tests/rh175569/C.java >> rh175569/gcj.sh.tmp chmod a+x rh175569/gcj.sh.tmp mv rh175569/gcj.sh.tmp rh175569/gcj.sh depbase=`echo process/single_exec.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT process/single_exec.o -MD -MP -MF "$depbase.Tpo" -c -o process/single_exec.o ../../../frysk/frysk-imports/tests/process/single_exec.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o process/single_exec -lpthread process/single_exec.o depbase=`echo process/multi_child_exec.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT process/multi_child_exec.o -MD -MP -MF "$depbase.Tpo" -c -o process/multi_child_exec.o ../../../frysk/frysk-imports/tests/process/multi_child_exec.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o process/multi_child_exec -lpthread process/multi_child_exec.o depbase=`echo process/multi_parent_exec.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT process/multi_parent_exec.o -MD -MP -MF "$depbase.Tpo" -c -o process/multi_parent_exec.o ../../../frysk/frysk-imports/tests/process/multi_parent_exec.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o process/multi_parent_exec -lpthread process/multi_parent_exec.o depbase=`echo process/multi_child_parent_exec.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT process/multi_child_parent_exec.o -MD -MP -MF "$depbase.Tpo" -c -o process/multi_child_parent_exec.o ../../../frysk/frysk-imports/tests/process/multi_child_parent_exec.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o process/multi_child_parent_exec -lpthread process/multi_child_parent_exec.o mkdir -p wrongclass echo /opt/gccfr/bin/gcj -C \ -I ../../../frysk/frysk-imports/tests/wrongclass \ -d `pwd`/wrongclass \ ../../../frysk/frysk-imports/tests/wrongclass/frysk/sys/Wait.java \ ../../../frysk/frysk-imports/tests/wrongclass/frysk/model/Signal.java \ ../../../frysk/frysk-imports/tests/wrongclass/frysk/event/Signal.java \ ../../../frysk/frysk-imports/tests/wrongclass/frysk/event/SignalEvent.java \ ../../../frysk/frysk-imports/tests/wrongclass/frysk/proc/LinuxHost.java \ > wrongclass/gcj.sh chmod a+x wrongclass/gcj.sh cd `dirname ../cdtparser/cdtparser.jar` && make make[1]: Entering directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/cdtparser' rm -rf classdir mkdir -p classdir classdir=`cd classdir && pwd` ; \ cd ../../../frysk/frysk-imports/cdtparser ; \ /opt/gccfr/bin/gcj -C -O -g -d $classdir @file.list cd classdir ; \ find * -name '*.class' -print | /opt/gccfr/bin/fastjar -@ -cf cdtparser.jar.tmp mv classdir/cdtparser.jar.tmp cdtparser.jar make[1]: Leaving directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/cdtparser' mkdir -p cdtparserversion /opt/gccfr/bin/gcj -C -d . \ -classpath ../cdtparser/cdtparser.jar \ ../../../frysk/frysk-imports/tests/cdtparserversion/CDTParserTest.java mkdir -p cdtparserversion rm -f cdtparserversion/cdttest.sh.tmp echo "#!/bin/sh" >> cdtparserversion/cdttest.sh.tmp echo '/opt/gccfr/bin/gij \' >> cdtparserversion/cdttest.sh.tmp echo ' -classpath .:../cdtparser/cdtparser.jar \' >> cdtparserversion/cdttest.sh.tmp echo ' cdtparserversion.CDTParserTest \' >> cdtparserversion/cdttest.sh.tmp echo ' ../../../frysk/frysk-imports/tests/cdtparserversion/main.cpp \' >> cdtparserversion/cdttest.sh.tmp echo ' > cdtparserversion/RESULT' >> cdtparserversion/cdttest.sh.tmp echo 'test `cat cdtparserversion/RESULT` == 4,5' >> cdtparserversion/cdttest.sh.tmp chmod a+x cdtparserversion/cdttest.sh.tmp mv cdtparserversion/cdttest.sh.tmp cdtparserversion/cdttest.sh depbase=`echo cmdline/print.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT cmdline/print.o -MD -MP -MF "$depbase.Tpo" -c -o cmdline/print.o ../../../frysk/frysk-imports/tests/cmdline/print.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o cmdline/print cmdline/print.o cp ../../../frysk/frysk-imports/tests/rh177240/strace-clone-exec.shin rh177240/strace-clone-exec.sh.tmp chmod a+x rh177240/strace-clone-exec.sh.tmp mv rh177240/strace-clone-exec.sh.tmp rh177240/strace-clone-exec.sh make process/single_exec process/multi_child_exec process/multi_parent_exec process/multi_child_parent_exec cmdline/dump cmdline/print rh177240/threadexec rh177240/strace-clone-exec.sh make[1]: Entering directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/tests' make[1]: `process/single_exec' is up to date. make[1]: `process/multi_child_exec' is up to date. make[1]: `process/multi_parent_exec' is up to date. make[1]: `process/multi_child_parent_exec' is up to date. depbase=`echo cmdline/dump.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT cmdline/dump.o -MD -MP -MF "$depbase.Tpo" -c -o cmdline/dump.o ../../../frysk/frysk-imports/tests/cmdline/dump.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o cmdline/dump cmdline/dump.o make[1]: `cmdline/print' is up to date. depbase=`echo rh177240/threadexec.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if /opt/gccfr/bin/gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" -DPACKAGE_VERSION=\"0.0.1.2006.01.17\" -DPACKAGE_STRING=\"frysk\ 0.0.1.2006.01.17\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" -DVERSION=\"0.0.1.2006.01.17\" -I. -I../../../frysk/frysk-imports/tests -g -O -MT rh177240/threadexec.o -MD -MP -MF "$depbase.Tpo" -c -o rh177240/threadexec.o ../../../frysk/frysk-imports/tests/rh177240/threadexec.c; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi /opt/gccfr/bin/gcc -g -O -o rh177240/threadexec -lpthread rh177240/threadexec.o make[1]: `rh177240/strace-clone-exec.sh' is up to date. make[1]: Leaving directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/tests' make check-TESTS make[1]: Entering directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/tests' mkdir -p cniinner /opt/gccfr/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Parent.java /opt/gccfr/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Child.java /opt/gccfr/bin/gcjh -I. cniinner.Parent /opt/gccfr/bin/gcjh -I. cniinner.Child /opt/gccfr/bin/gcjh -I. 'cniinner.Child$Nested' /opt/gccfr/bin/gcj -g -I. -c -o cniinner/native.o ../../../frysk/frysk-imports/tests/cniinner/native.cxx XFAIL: nestcall/a.out XFAIL: samename/a.out XFAIL: packagename/O.out XFAIL: werror/java.sh XFAIL: gcc8544/gcj.sh PASS: logger/a.out PASS: anoncall/a.out FAIL: cniinner/a.out PASS: packagename/C.out PASS: werror/cxx.sh PASS: rh174912/gcj.sh PASS: rh174912ice/gcj.sh PASS: rh175569/gcj.sh PASS: process/single_exec PASS: process/multi_child_exec PASS: process/multi_parent_exec PASS: process/multi_child_parent_exec PASS: wrongclass/gcj.sh PASS: cdtparserversion/cdttest.sh PASS: cmdline/print FAIL: rh177240/strace-clone-exec.sh ==================== 2 of 21 tests failed ==================== make[1]: Leaving directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-imports/tests' make: *** [check-am] Error 2 ppc64-gtk-check.log (cd frysk-gtk; make check): Summary: textiter fails. ==================================================== mkdir -p gcjtreeiter /opt/gccfr/bin/gcj -g \ -classpath /usr/share/frysk/java/gtk2.8-2.8.2.jar:/usr/share/frysk/java/glib0.2-0.2.2.jar \ -L/usr/lib/frysk -lgtkjava -lcairojava -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lglibjava \ -Wl,-rpath,/opt/frysk/lib:/usr/lib/frysk \ -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ --main=gcjtreeiter.IterTest \ ../../../frysk/frysk-gtk/tests/gcjtreeiter/IterTest.java \ -o gcjtreeiter/a.out mkdir -p gcjtreeiter /opt/gccfr/bin/gcj -g -C -d . -I../../../frysk/frysk-gtk/tests \ -classpath /usr/share/frysk/java/gtk2.8-2.8.2.jar:/usr/share/frysk/java/glib0.2-0.2.2.jar \ ../../../frysk/frysk-gtk/tests/gcjtreeiter/IterTest.java echo /opt/gccfr/bin/gij -classpath .:/usr/share/frysk/java/gtk2.8-2.8.2.jar:/usr/share/frysk/java/glib0.2-0.2.2.jar \ -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ gcjtreeiter.IterTest \ > gcjtreeiter/gij.sh chmod a+x gcjtreeiter/gij.sh mkdir -p textiter /opt/gccfr/bin/gcj -g \ -classpath /usr/share/frysk/java/gtk2.8-2.8.2.jar:/usr/share/frysk/java/glib0.2-0.2.2.jar \ -L/usr/lib/frysk -lgtkjava -lcairojava -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lglibjava \ -Wl,-rpath,/opt/frysk/lib:/usr/lib/frysk \ -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ --main=textiter.JNICrash \ -o textiter/a.out \ ../../../frysk/frysk-gtk/tests/textiter/JNICrash.java make check-TESTS make[1]: Entering directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-gtk/tests' XFAIL: gcjtreeiter/a.out XFAIL: gcjtreeiter/gij.sh FAIL: textiter/a.out =================== 1 of 3 tests failed =================== make[1]: Leaving directory `/root/DE-Frysk/frysk-cvs/cvs-4751/build/frysk-gtk/tests' make: *** [check-am] Error 2 ppc64-core-tr.log (cd frysk-core; ./TestRunner): Summary : it reports an unexpected signal error on TestI386Modify, and a ptrace I/O error on TestModify and stop. Will disable I386 testcases to see whether it can go on. ================================================= Running testDOMFrysk(frysk.dom.TestDOM) ...PASS Running testDOMImage(frysk.dom.TestDOM) ...PASS Running testDOMFunction(frysk.dom.TestDOM) ...PASS Running testDOMsource(frysk.dom.TestDOM) ...PASS Running testDOMLine(frysk.dom.TestDOM) ...PASS Running testDOMInlineInstance(frysk.dom.TestDOM) ...PASS Running testEventLoop(frysk.event.TestEventLoop) ...PASS Running testPeriodicTimer(frysk.event.TestEventLoop) ...PASS Running testTimerRemoval(frysk.event.TestEventLoop) ...PASS Running testScheduleBeforeRun(frysk.event.TestEventLoop) ...PASS Running testSignalHandler(frysk.event.TestEventLoop) ...PASS Running testAsync(frysk.event.TestEventLoop) ...PASS Running testProcExec(frysk.proc.TestExec) ...PASS Running testTaskExec(frysk.proc.TestExec) ...FAIL junit.framework.AssertionFailedError: tmp file exists Running testUnattachedSingleExec(frysk.proc.TestExec) ...PASS Running testAttachedSingleExec(frysk.proc.TestExec) ...PASS Running testGetSelf(frysk.proc.TestHostGet) ...PASS Running testI386Modify(frysk.proc.TestI386Modify) ...FAIL junit.framework.AssertionFailedError: unexpected signal 4 Running testI386Regs(frysk.proc.TestI386Regs) ...FAIL junit.framework.AssertionFailedError: orig_eax register expected:<1> but was:<0> Running testModify(frysk.proc.TestModify) ...char 0 was ff instead of 61 ppc64-sys-tr.log (cd frysk-sys; ./TestRunner): Summary: all passed =============================================== Running testIA32(frysk.sys.proc.TestAuxv) ...PASS Running testAMD64(frysk.sys.proc.TestAuxv) ...PASS Running testIA64(frysk.sys.proc.TestAuxv) ...PASS Running testPPC32(frysk.sys.proc.TestAuxv) ...PASS Running testPPC64(frysk.sys.proc.TestAuxv) ...PASS Running test(frysk.sys.proc.TestCmdLine) ...PASS Running test_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0_c0(frysk.sys.proc.TestCmdLine) ...PASS Running testIA32(frysk.sys.proc.TestMaps) ...PASS Running testIA64(frysk.sys.proc.TestMaps) ...PASS Running testAMD64(frysk.sys.proc.TestMaps) ...PASS Running testPPC32(frysk.sys.proc.TestMaps) ...PASS Running testPPC64(frysk.sys.proc.TestMaps) ...PASS Time: 0.006 OK (18 tests) ppc64-imports-tr.log (cd frysk-imports; ./TestRunner): Summary: all passed ========================================================= Running testGet(inua.eio.TestGet) ...PASS Running testMmap(inua.eio.TestMmap) ...PASS Running testPut(inua.eio.TestPut) ...PASS Running testGetWord(inua.eio.TestWordSize) ...PASS Running testRest(inua.eio.TestWordSize) ...PASS Running testParamaterlessPool(inua.util.TestPool) ...PASS Running testParameteredPool(inua.util.TestPool) ...PASS Time: 0.072 OK (7 tests) BTW. The patch in last post works also ok on x86. Regards - Wu Zhou From cagney@redhat.com Tue Jan 17 16:19:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 17 Jan 2006 16:19:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> Message-ID: <43CD18FA.5060402@redhat.com> Wu Zhou wrote: Overall the results are pretty good, two notes though: > FAIL: cniinner/a.out not so good; I'm guessing that on ppc-64 it tickled some other bug. Perhaphs try that test on gcc-4.1? >FAIL: rh177240/strace-clone-exec.sh > > Now there is likely a kernel bug. It would explain this failure: > >Running testTaskExec(frysk.proc.TestExec) ...FAIL > junit.framework.AssertionFailedError: tmp file exists > > From woodzltc@cn.ibm.com Wed Jan 18 01:57:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 18 Jan 2006 01:57:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <43CD18FA.5060402@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> <43CD18FA.5060402@redhat.com> Message-ID: On Tue, 17 Jan 2006, Andrew Cagney wrote: > Wu Zhou wrote: > > Overall the results are pretty good, two notes though: Hi Anrew, what about "FAIL: textiter/a.out"? Is it a serious problem? I remember that it ever pass for an earlier cvs. Now it failed on both x86 and ppc64. > > FAIL: cniinner/a.out > > not so good; I'm guessing that on ppc-64 it tickled some other bug. Perhaphs > try that test on gcc-4.1? Is gcc-4.1 out already? I tested on gcc-4.0.1, 4,0.2, Redhat 4.0.1 and your 4.0.2 compilers. All of them give the same error message: [root@plinuxt2 tests]# make -f Makefile.401 cniinner/a.out mkdir -p cniinner /opt/gcc401/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Parent.java /opt/gcc401/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C ../../../frysk/frysk-imports/tests/cniinner/Child.java /opt/gcc401/bin/gcjh -I. cniinner.Parent /opt/gcc401/bin/gcjh -I. cniinner.Child /opt/gcc401/bin/gcjh -I. 'cniinner.Child$Nested' /opt/gcc401/bin/gcj -g -I. -c -o cniinner/native.o ../../../frysk/frysk-imports/tests/cniinner/native.cxx /opt/gcc401/bin/gcj -g -I. --main=cniinner.Child -o cniinner/a.out \ ../../../frysk/frysk-imports/tests/cniinner/Parent.java \ ../../../frysk/frysk-imports/tests/cniinner/Child.java \ cniinner/native.o ../../../frysk/frysk-imports/tests/cniinner/Parent.java:3: internal compiler error: in mark_reference_fields, at java/boehm.c:105 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [cniinner/a.out] Error 1 Maybe I can submit a bug report for GNU java community? > > FAIL: rh177240/strace-clone-exec.sh > > > Now there is likely a kernel bug. It would explain this failure: > Can you point me to any link about this kernel bug? Thanks a lot! Regards - Wu Zhou From dnovillo@redhat.com Fri Jan 20 22:09:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Fri, 20 Jan 2006 22:09:00 -0000 Subject: Add needed packages for FC5 builds Message-ID: <43D15FA1.3020909@redhat.com> I needed to add these packages on a vanilla FC5 installation. OK to update the docs with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: 20060120-fc5-build-pkgs.diff Type: text/x-patch Size: 697 bytes Desc: not available URL: From cagney@redhat.com Fri Jan 20 22:47:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 20 Jan 2006 22:47:00 -0000 Subject: multiple exec doesn't exec In-Reply-To: <1137791765.7677.123.camel@multics.rdu.redhat.com> References: <1137692042.7677.79.camel@multics.rdu.redhat.com> <43CFED7F.9010809@redhat.com> <1137791765.7677.123.camel@multics.rdu.redhat.com> Message-ID: <43D162EB.8040408@redhat.com> Stan, below is a brief commentary on a barfing exec trace ... Lets start part way through where TestRunner just sent the child ignal 10 == SIGUSR1 == add clone >run event loop {Thread[Thread-2,5,main]} > > test runner is waiting for an event ... >poll frysk.event.EventLoop$1@49a48 >process signal 17 > > 17 is sigchild -> event pending on waitpid() extract it ... >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute >{TaskId,31250} stopped >get task {TaskId,31250 > it's the signal TestRunner sent to the child ... >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} receiveSignaledEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >signal running >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} notifySignaled(int) >send continue 10 > > the the child with that signal, the child will then process the signal creating a clone ... >poll frysk.event.EventLoop$1@49a48 >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute > > ... the requested clone! Several things happen next: -- the test case adds an observer to the clone -- the clonee stops -- the cloner (TaskId,31250) is continued <> -- the clonee (TaskId,31251) is continued <> -- both the cloner and clonee send the testrunner an ack signal (10, and 12) >{TaskId,31250} cloneEvent >get task {TaskId,31250} >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=null} notify -- all observers >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=null} requestAddObserver >{frysk.proc.LinuxProc@16df00,id={ProcId,31250},state=running,command=child} performAddObservation >add event [ProcEvent,procnull] >wake up {Thread[Thread-2,5,main]} >add task Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=null} >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=Start.waitForStop} new -- create attached clone >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} receiveClonedEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >{TaskId,31251} stopped >get task {TaskId,31251} >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=Start.waitForStop} receiveStoppedEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [ProcEvent,procnull] >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=Start.waitForStop} performAddObservation >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} PerformedClone >send continue 0 > > cloner continued >remove first pending event [TaskEvent,tasknull] >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=Start.waitForStop} processStoppedEvent >send set options >send continue 0 > > clonee continued >remove first pending event [TaskEvent,tasknull] >poll frysk.event.EventLoop$1@49a48 >process signal 10 >create signal event handler {,signal=0} >hash {,signal=10} >poll frysk.event.EventLoop$1@49a48 >process signal 12 >create signal event handler {,signal=0} >hash {,signal=12} > > the two ack signals from child's cloner and clonee threads arrive in the test case; they then get delivered and the event loop is stopped ... >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=10} >stop event loop {Thread[Thread-2,5,main]} >wake up {Thread[Thread-2,5,main]} >remove signal handler {,signal=10} >hash {,signal=10} >remove first pending event {,signal=12} >stop event loop {Thread[Thread-2,5,main]} >wake up {Thread[Thread-2,5,main]} >remove signal handler {,signal=12} >hash {,signal=12} >remove timer event {frysk.event.EventLoop$2$Timeout@1efca8} >refresh from process table >add event [HostEventRequestRefresh] >wake up {Thread[Thread-2,5,main]} >run event loop until no pending events {Thread[Thread-2,5,main]} >run event loop {Thread[Thread-2,5,main]} >remove first pending event [HostEventRequestRefresh] >request refresh execute >get proc {ProcId,31250} >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=running} requestAddObserver >{frysk.proc.LinuxProc@16df00,id={ProcId,31250},state=running,command=child} performAddObservation >add event [ProcEvent,procnull] >wake up {Thread[Thread-2,5,main]} >create signal event handler {,signal=0} >hash {,signal=10} >add signal handler {,signal=10} >get signal {,signal=10} >wake up {Thread[Thread-2,5,main]} >create signal event handler {,signal=0} >hash {,signal=12} >add signal handler {,signal=12} >get signal {,signal=12} >wake up {Thread[Thread-2,5,main]} > > .. now for the next round <> bit where second thread 31252 is created <> next send the child a SIGFPE==8 == clone peer; start with TestRunner waiting for the child to receive the signal ... >run polling {Thread[Thread-2,5,main]} >create a timer {frysk.event.EventLoop$2$Timeout@2f72d0} >timeout 5,000 >add timer event {frysk.event.EventLoop$2$Timeout@2f72d0} >wake up {Thread[Thread-2,5,main]} >run event loop {Thread[Thread-2,5,main]} >poll frysk.event.EventLoop$1@49a48 >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute >{TaskId,31250} stopped >get task {TaskId,31250} >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} receiveSignaledEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >signal running >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} notifySignaled(int) >send continue 8 > > child received the signal, continue that child with signal 8 - clone peer. The child will then: - send us an ack - send the peer thread the SIGPWR - do clone >poll frysk.event.EventLoop$1@49a48 >process signal 12 >create signal event handler {,signal=0} >hash {,signal=12} > > the ack for going to clone; >poll frysk.event.EventLoop$1@49a48 >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} > > and the other thread receiving it's SIGPWR >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=12} >stop event loop {Thread[Thread-2,5,main]} >wake up {Thread[Thread-2,5,main]} >remove signal handler {,signal=12} >hash {,signal=12} >remove first pending event {,signal=17} >execute >{TaskId,31251} stopped >get task {TaskId,31251} >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=running} receiveSignaledEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >signal running >Linux{frysk.proc.LinuxTask@13f820,id={TaskId,31251},state=running} notifySignaled(int) >send continue 30 > > the peer (31251) receives SIGPWR (30) and is continued with it; that thread does an exec ... >remove timer event {frysk.event.EventLoop$2$Timeout@2f72d0} >run polling {Thread[Thread-2,5,main]} >create a timer {frysk.event.EventLoop$2$Timeout@2f72a8} >timeout 5,000 >add timer event {frysk.event.EventLoop$2$Timeout@2f72a8} >wake up {Thread[Thread-2,5,main]} >run event loop {Thread[Thread-2,5,main]} >poll frysk.event.EventLoop$1@49a48 >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute >{TaskId,31252} exitEvent >get task {TaskId,31252} >Linux{frysk.proc.LinuxTask@13f7d0,id={TaskId,31252},state=running} receiveTerminatingEvent >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} > > receive (queue) thread 31252's terminating event (due to exec) >{TaskId,31250} exitEvent >get task {TaskId,31250} >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} receiveTerminatingEvent >add event [TaskEvent,tasknull] > > receive (queue) thread 31250's terminating event (due to exec) that leaves just 31250 >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >terminate running > > process first terminating >send continue 0 >remove first pending event [TaskEvent,tasknull] >terminate running >send continue 0 > > process second terminating >poll frysk.event.EventLoop$1@49a48 > > block for next child event ... >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute >{TaskId,31252} terminated >get task {TaskId,31252} >Linux{frysk.proc.LinuxTask@13f7d0,id={TaskId,31252},state=running} receiveTerminatedEvent > > 31252 receives a you-are-dead (terminated event) yet ... >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >{TaskId,31250} execEvent >get task {TaskId,31250} >Linux{frysk.proc.LinuxTask@992d0,id={TaskId,31250},state=running} receiveExecedEvent > > the next thing seen is for 31250 it just completed an exec; remember 31250 just transitioned out of state "running" (into?) Now what actually happened (I'm told) is that thread 31251 effectively renamed itself to 3125- (blowing away the real 31250 in the process) it then: >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] >terminate running > > presumably 31252 processes the terminated event? >{frysk.proc.LinuxProc@16df00,id={ProcId,31250},state=running,command=child} remove(Task) -- within this Proc >Linux{frysk.proc.LinuxTask@13f7d0,id={TaskId,31252},state=running} notify -- all observers >remove task Linux{frysk.proc.LinuxTask@13f7d0,id={TaskId,31252},state=running} >destroy Linux{frysk.proc.LinuxTask@13f7d0,id={TaskId,31252},state=running} >remove first pending event [TaskEvent,tasknull] >exec running > > presumably 31250 processes the exec event? what was the state of 31250 here and what state did it go into next? It should be possible to work it out; starting in "running" state it received: terminatingEvent; execEvent >{frysk.proc.LinuxProc@16df00,id={ProcId,31250},state=running,command=child} retain(Task) -- remove all but task > > what exactly did this do? see further down ... >remove tasks [] >send continue 0 >poll frysk.event.EventLoop$1@49a48 > > the child is then continued; what is it's state? wait for next child event, event was ... >process signal 17 >create signal event handler {,signal=0} >hash {,signal=17} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=17} >execute > > ... nothing; previously drained the event from the queue execed child then sends us back a signal 10 to say hey finished >poll frysk.event.EventLoop$1@49a48 >process signal 10 >create signal event handler {,signal=0} >hash {,signal=10} >move to event queue {Thread[Thread-2,5,main]} >remove first pending event {,signal=10} >stop event loop {Thread[Thread-2,5,main]} >wake up {Thread[Thread-2,5,main]} >remove signal handler {,signal=10} >hash {,signal=10} >remove timer event {frysk.event.EventLoop$2$Timeout@2f72a8} >refresh from process table >add event [HostEventRequestRefresh] >wake up {Thread[Thread-2,5,main]} >run event loop until no pending events {Thread[Thread-2,5,main]} >run event loop {Thread[Thread-2,5,main]} >remove first pending event [HostEventRequestRefresh] > > next a refresh occures an that leads to ... >request refresh execute >Linux{frysk.proc.LinuxTask@13f780,id={TaskId,31250},state=null} notify -- all observers >Linux{frysk.proc.LinuxTask@13f780,id={TaskId,31250},state=null} requestAddObserver >{frysk.proc.LinuxProc@16df00,id={ProcId,31250},state=running,command=child} performAddObservation >add event [ProcEvent,procnull] >wake up {Thread[Thread-2,5,main]} >add task Linux{frysk.proc.LinuxTask@13f780,id={TaskId,31250},state=null} >Linux{frysk.proc.LinuxTask@13f780,id={TaskId,31250},state=unattached} new -- create unattached > > ---> a brand new unattached 31250 task being created; what happened to the old one? <--- >remove first pending event [ProcEvent,procnull] >Linux{frysk.proc.LinuxTask@13f780,id={TaskId,31250},state=unattached} performAddObservation >add event [TaskEvent,tasknull] >wake up {Thread[Thread-2,5,main]} >remove first pending event [TaskEvent,tasknull] > > so for some reason process 31250 lost it's main task 31250. Two things that might make the next trace easier: - tweak the log message in TaskState and ProcState to be consistently of the form (for task) <<"{0} ", task>> so that it is easy to see the state of the task - could the testcase just tell a non-main task to do the clone directly, something like: task = child.findTaskUsingRefresh (false); child.exec (task.getTid()) that would simplify the number of exchanges Andrew From scox@redhat.com Fri Jan 20 22:52:00 2006 From: scox@redhat.com (Stan Cox) Date: Fri, 20 Jan 2006 22:52:00 -0000 Subject: new TestExec tests Message-ID: <1137797534.7677.141.camel@multics.rdu.redhat.com> Trying to add the following test to check execing from a thread, however it is failing with: java.lang.RuntimeException: Linux{frysk.proc.LinuxTask@5b870,id={TaskId,505},state=unattached} in state "unattached" did not handle PerformAddObservation There was 1 error: 1) testAttachedMultipleExec(frysk.proc.TestExec)java.lang.RuntimeException: Linux{frysk.proc.LinuxTask@5b870,id={TaskId,505},state=unattached} in state "unattached" did not handle PerformAddObservation at frysk.proc.State.unhandled(java.lang.Object, java.lang.String) (/home/scox/frysk/src/frysk-core/frysk/proc/State.java:77) at frysk.proc.TaskState.processPerformAddObservation(frysk.proc.Task, frysk.proc.Observation) (/home/scox/frysk/src/frysk-core/frysk/proc/TaskState.java:172) at frysk.proc.Task$19.execute() (/home/scox/frysk/src/frysk-core/frysk/proc/Task.java:552) at frysk.event.EventLoop.runEventLoop(boolean) (/home/scox/frysk/src/frysk-core/frysk/event/EventLoop.java:311) public void testAttachedMultipleExec () { AckProcess child = new AttachedAckProcess (); Proc proc = child.findProcUsingRefresh (true); // Watch for any Task exec events, accumulating them as they arrive. class ExecObserver extends AutoAddTaskObserverBase implements TaskObserver.Execed { int saved_tid = 0; public Action updateExeced (Task task) { Manager.eventLoop.requestStop (); return Action.CONTINUE; } void requestAdd (Task task) { task.requestAddExecedObserver (this); } void updateTaskAdded (Task task) { if (saved_tid == 0) saved_tid = task.getTid (); task.requestAddExecedObserver (this); } } ExecObserver execObserver = new ExecObserver (); child.addClone (); execObserver.requestAdd (child.findTaskUsingRefresh (false)); child.addClone (); // AckHandler ack = new AckHandler (Sig.USR1); child.execClone (); // ack.await (); Manager.host.requestRefresh (true); assertRunUntilStop ("waiting for exec"); //Manager.eventLoop.runPending (); String argv [] = proc.getCmdLine (); System.out.println ("X" + argv[0] + " " + argv[1] + " " + child.getPid () + " " + proc.getPid () + " " + execObserver.saved_tid + "X"); int colon = argv[0].indexOf (":"); int new_tid = 0; System.out.println ("colon" + colon); assertFalse ("pid:task after unattached multiple clone exec", colon < 0); new_tid = Integer.parseInt (argv[0].substring (colon + 1)); System.out.println (new_tid); // assertEquals ("pid after attached multiple clone exec", new_tid, proc.getPid ()); // assertEquals ("pid after attached multiple clone exec", new_tid, execObserver.saved_tid); assertEquals ("", true, true); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_core_event.log Type: text/x-log Size: 134118 bytes Desc: not available URL: From cagney@redhat.com Sun Jan 22 01:28:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 22 Jan 2006 01:28:00 -0000 Subject: frysk-0.0.1.2006.01.22-0.EL4.0.src.rpm Message-ID: <43D2DF9A.3020104@redhat.com> I've uploaded a new RHEL-4 jumbo-rpm (includes all of frysk's build dependencies) to ftp://sources.redhat.com/pub/frysk/RHEL-4/ Among the updates there's: - updates to the gtk packages bringing it into line with FC-5 - fixes and tweaks from from Diego Novillo and Wu Zhou for x86-64 and ppc64 (not yet enabled) - today's frysk snapshot I've appended the spec file's %changelog entries. Check http://sources.redhat.com/frysk/bugs/ or frysk-cvs@ for changes to frysk's sources. Andrew * Sat Jan 21 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.0 - Import glib 2.9.4.tar.bz2, atk 1.11.2.tar.bz2, and frysk 0.0.1.2006.01.22. - Add/update gtk+-2.8.10-set-invisible-char-to-bullet.patch, fontconfig-2.3.93-defaultconfig.patch, and 50-no-hint-fonts.conf. - Add frysk.desktop, and fryskTrayIcon48.png to -files. * Sat Jan 21 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.9 - Replace macros gccp, and gccs with frysk_gcc_prefix and frysk_gcc_suffix. Update EXPORT function to use. - In EXPORT, for ppc64, append -mminimal-toc to all all compiler environment variables. - Add macros build_frysk, and build_antlr. Use instead of architecture test. * Sat Jan 21 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.8 - For antlr, update config.guess and config.sub; problem reported by Wu Zhou * Sat Jan 21 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.7 - Drop update-scripts.tar.gz and update-scripts-frysk.patch. - Replace -post and -postun steps generating pango.modules and gdk-pixbuf.loaders with the scripts frysk-update-gdk-pixbuf-loaders, frysk-update-gtk-immodules, and frysk-update-pango-modules run from -post, and generated by MKUPDATE. * Sat Jan 21 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.6 - Rename lib_pangoft to lib_pangoft2. - Add lib_pangoft2 to libglade2_makeflags. * Fri Jan 20 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.5 - Fix typo, point lib_gdk_xll at libgdk-xll and not libgtk-xll. - Add lib_gtk_x11 to libglade2_makeflags. * Fri Jan 20 2006 Andrew Cagney 0.0.1.2006.01.13-0.EL4.4 - Add shell functions MKSCRIPT and ECHO_CMD for creating a shell script. In CONFIG, BUILD, and INSTALL use these to create a shell script containing all the config, build or install information. Run. * Thu Jan 19 2006 Diego Novillo 0.0.1.2006.01.13-0.EL4.3 - Use %{_target_platform} instead of i686-redhat-linux-gnu. From woodzltc@cn.ibm.com Mon Jan 23 01:51:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 23 Jan 2006 01:51:00 -0000 Subject: frysk-0.0.1.2006.01.22-0.EL4.0.src.rpm In-Reply-To: <43D2DF9A.3020104@redhat.com> References: <43D2DF9A.3020104@redhat.com> Message-ID: On Sat, 21 Jan 2006, Andrew Cagney wrote: > I've uploaded a new RHEL-4 jumbo-rpm (includes all of frysk's build > dependencies) to ftp://sources.redhat.com/pub/frysk/RHEL-4/ > Among the updates there's: > > - updates to the gtk packages bringing it into line with FC-5 > - fixes and tweaks from from Diego Novillo and Wu Zhou for x86-64 and ppc64 > (not yet enabled) > - today's frysk snapshot Thanks for the update. I will download this jumbo to have a try on x86 and ppc64. Regards - Wu Zhou From woodzltc@cn.ibm.com Mon Jan 23 02:17:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 23 Jan 2006 02:17:00 -0000 Subject: Fix build on x86-64 In-Reply-To: <43CE5F2A.4020009@redhat.com> References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> <43CD18FA.5060402@redhat.com> <43CE5F2A.4020009@redhat.com> Message-ID: On Wed, 18 Jan 2006, Andrew Cagney wrote: > Wu Zhou wrote: > > > On Tue, 17 Jan 2006, Andrew Cagney wrote: > > > > > > > Wu Zhou wrote: > > > > > > Overall the results are pretty good, two notes though: > > > > > > > Hi Anrew, what about "FAIL: textiter/a.out"? Is it a serious problem? I > > remember that it ever pass for an earlier cvs. Now it failed on both x86 > > and ppc64. > > > That's interesting; I'll re-check my local results. It shouldn't be a serious > problem. > The bug first hit some java-gnome JNI bindings code, fortunatly it was > possible to rewrite the code to avoid the problem. There's obviously an > ongoing risk that fresh code will trip over the problem, the gui developers > feel that the risk is relatively low. > That is okay. This test still fail on x86 and ppc64 though. > > > > FAIL: cniinner/a.out > > > > > > > not so good; I'm guessing that on ppc-64 it tickled some other bug. > > > Perhaphs > > > try that test on gcc-4.1? > > > > > > > Is gcc-4.1 out already? I tested on gcc-4.0.1, 4,0.2, Redhat 4.0.1 and your > > 4.0.2 compilers. All of them give the same error message: > > > > [root@plinuxt2 tests]# make -f Makefile.401 cniinner/a.out > > mkdir -p cniinner > > /opt/gcc401/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C > > ../../../frysk/frysk-imports/tests/cniinner/Parent.java > > /opt/gcc401/bin/gcj -I../../../frysk/frysk-imports/tests -d . -C > > ../../../frysk/frysk-imports/tests/cniinner/Child.java > > /opt/gcc401/bin/gcjh -I. cniinner.Parent > > /opt/gcc401/bin/gcjh -I. cniinner.Child > > /opt/gcc401/bin/gcjh -I. 'cniinner.Child$Nested' > > /opt/gcc401/bin/gcj -g -I. -c -o cniinner/native.o > > ../../../frysk/frysk-imports/tests/cniinner/native.cxx > > /opt/gcc401/bin/gcj -g -I. --main=cniinner.Child -o cniinner/a.out \ > > ../../../frysk/frysk-imports/tests/cniinner/Parent.java \ > > ../../../frysk/frysk-imports/tests/cniinner/Child.java \ > > cniinner/native.o > > ../../../frysk/frysk-imports/tests/cniinner/Parent.java:3: internal compiler > > error: in mark_reference_fields, at java/boehm.c:105 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See for instructions. > > make: *** [cniinner/a.out] Error 1 > > > > Maybe I can submit a bug report for GNU java community? > > > The intent is for Fedora Core 5 to ship with 4.1, the test releases (FC-5 Test > 2 is just out) include preliminary versions of the compiler. I made a test with the 20060106 snapshot of gcc-4.1, it still failed. Janis Johnson also confirmed that it failed in the same way on GCC trunk, gcc-3.4.2 building in 32-bits mode, with "-m64" option however, it will report only an undefined reference: /tmp/ccggTln9.o(.toc+0x10): undefined reference to `cniinner::child::class$' collect2: ld returned 1 exit status > > I think the java group would be very interested The original i386 bug > (botched object method offsets leaving a virtual address null) resulted in a > segmentation fault. You've got something new different. > Before submitting a problem reprot, I want to ask if I can make these code public (Parent.java, Child.java and native.cxx)? I guess it is, but I still want to make sure. :-) > > > > FAIL: rh177240/strace-clone-exec.sh > > > > > > > > > > > Now there is likely a kernel bug. It would explain this failure: > > > > > > > > > > Can you point me to any link about this kernel bug? Thanks a lot! > > > The above was testing for a regression in both the FC-5 and correspoinding > upstream kernel. The FC-5 bug report is here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177240 sounds like it has > tickled another bug. I am now believing that it is the same bug. Because I run the original test on a 2.6.15 kernel. I switch the kenel back to RHEL4 U2 shipped one, it report PASS this time. So the imports check on PPC64 only reports one FAILURE now, Great! BTW, I want to ask a question, to make Frysk work on PPC64, what extra work needed to be done? I means these code different than the common ones. If you can share your thought, that is much appreciated. Regards - Wu Zhou From cagney@redhat.com Tue Jan 24 16:16:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 24 Jan 2006 16:16:00 -0000 Subject: Add needed packages for FC5 builds In-Reply-To: <43D15FA1.3020909@redhat.com> References: <43D15FA1.3020909@redhat.com> Message-ID: <43D652EC.3020809@redhat.com> Diego Novillo wrote: > > I needed to add these packages on a vanilla FC5 installation. OK to > update the docs with this? definitely > > >------------------------------------------------------------------------ > >? 20060120-fc5-build-pkgs.diff >Index: index.html >=================================================================== >RCS file: /cvs/frysk/htdocs/build/index.html,v >retrieving revision 1.47 >diff -d -u -p -r1.47 index.html >--- index.html 16 Jan 2006 16:16:11 -0000 1.47 >+++ index.html 20 Jan 2006 22:06:54 -0000 >@@ -63,6 +63,12 @@ and its upstream counterpart prevents th > programs that make execve calls (the kernel spontaneously kills the > program). > >+
  • >+You will need to have the following packages installed: antlr, >+jdom, glib-java, libgtk-java, >+libvte-java, vte-devel, libglade-java and >+gcc-java. >+ > > > > > From woodzltc@cn.ibm.com Wed Jan 25 09:50:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 25 Jan 2006 09:50:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> <43CD18FA.5060402@redhat.com> <43CE5F2A.4020009@redhat.com> Message-ID: > > > > I think the java group would be very interested The original i386 bug > > (botched object method offsets leaving a virtual address null) resulted in a > > segmentation fault. You've got something new different. > > > > Before submitting a problem reprot, I want to ask if I can make these code > public (Parent.java, Child.java and native.cxx)? I guess it is, but I > still want to make sure. :-) Andrew, I assume that it can be made public and report this to gcj community a while ago. Regards - Wu Zhou From cagney@redhat.com Wed Jan 25 16:01:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jan 2006 16:01:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> <43CD18FA.5060402@redhat.com> <43CE5F2A.4020009@redhat.com> Message-ID: <43D7A0DE.7030501@redhat.com> Wu Zhou wrote: >>>I think the java group would be very interested The original i386 bug >>>(botched object method offsets leaving a virtual address null) resulted in a >>>segmentation fault. You've got something new different. >>> >>> >>> >>Before submitting a problem reprot, I want to ask if I can make these code >>public (Parent.java, Child.java and native.cxx)? I guess it is, but I >>still want to make sure. :-) >> >> > >Andrew, > >I assume that it can be made public and report this to gcj community a >while ago. > > Sorry, yes, certainly. From cagney@redhat.com Wed Jan 25 16:04:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 25 Jan 2006 16:04:00 -0000 Subject: Fix build on x86-64 In-Reply-To: References: <200601132040.55935.dnovillo@redhat.com> <43C8A0F6.3030406@redhat.com> <17355.49994.273467.765436@localhost.redhat.com> <43CD18FA.5060402@redhat.com> <43CE5F2A.4020009@redhat.com> Message-ID: <43D7A187.4060009@redhat.com> >BTW, I want to ask a question, to make Frysk work on PPC64, what extra >work needed to be done? I means these code different than the common >ones. If you can share your thought, that is much appreciated. > > I'll take a rain check on that, will follow up in a few days. From dnovillo@redhat.com Thu Jan 26 02:18:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Thu, 26 Jan 2006 02:18:00 -0000 Subject: Fix 64bit problems in LibGlade Message-ID: <43D8315F.1090609@redhat.com> I will be sending this patch to LibGlade upstream. The SEGV inside LibGlade was due to a bug in jni/org_gnu_glade_LibGlade.c. The file does not include a prototype for gkt-java's getGObjectHandle, so the compiler was assuming the function returns 'int'. The function actually returns a 'void *', and since this is a 64bit host, the returned value (assumed to be int by the compiler) was being sign extended. So, anyway, the fix is obvious. The warnings were right there and being ignored, as usual. The actual difficult part of finding this was the multithreading and the multitude of calls into JNI, pthread, dynamic casts and the rest of Java's runtime. Sigh. I now get a different problem which I'll look at next: Opening windows 25-Jan-06 8:58:27 PM frysk.gui.FryskGui importPreferences WARNING: /home/cygnus/dnovillo/.frysk/.settings not found. Will be created on program exit Exception in thread "main" java.lang.NullPointerException at java.lang.Object.getClass (libgcj.so.7) at org.gnu.gtk.frysk.EggTrayIcon.egg_tray_icon_new (EggTrayIcon.java:72) at org.gnu.gtk.frysk.EggTrayIcon. (EggTrayIcon.java:52) at frysk.gui.monitor.TrayIcon. (TrayIcon.java:97) at frysk.gui.FryskGui.mainGui (FryskGui.java:168) at frysk.gui.FryskGui.main (FryskGui.java:237) I'm not sure what's the process of getting this from upstream. I've added to my local RPM for the time being. -------------- next part -------------- A non-text attachment was scrubbed... Name: 20060125-fix-64bit-miscompilation.diff Type: text/x-patch Size: 1206 bytes Desc: not available URL: From dnovillo@redhat.com Thu Jan 26 16:04:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Thu, 26 Jan 2006 16:04:00 -0000 Subject: More /usr/lib64 fixes Message-ID: <43D8F318.8020703@redhat.com> I don't think these really affect the main installation, but for completeness. The patch defines a new environment variable (GEN_LIB) that's set to lib64 on 64 bit hosts. OK to apply? -------------- next part -------------- A non-text attachment was scrubbed... Name: 20060126-64bit-fixes.diff Type: text/x-patch Size: 4682 bytes Desc: not available URL: From cagney@redhat.com Thu Jan 26 16:23:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 26 Jan 2006 16:23:00 -0000 Subject: More /usr/lib64 fixes In-Reply-To: <43D8F318.8020703@redhat.com> References: <43D8F318.8020703@redhat.com> Message-ID: <43D8F786.6020004@redhat.com> Diego Novillo wrote: >I don't think these really affect the main installation, but for >completeness. The patch defines a new environment variable (GEN_LIB) >that's set to lib64 on 64 bit hosts. > >OK to apply? > > Sure, however, while you're there, you might as well just wack references to /opt/frysk/. The latest jumbo rpm (for both FC-4 and RHEL-4) install into /usr/lib/frysk/ so /opt/frysk is dead. Andrew > > >------------------------------------------------------------------------ > >2006-01-26 Diego Novillo > > * common/acinclude.m4 (GEN_LIB): Define. > * frysk-gtk/tests/Makefile.am (textiter/a.out): Use. > (gcjtreeiter/a.out): Use. > >Index: common/acinclude.m4 >=================================================================== >RCS file: /cvs/frysk/frysk-common/acinclude.m4,v >retrieving revision 1.39 >diff -d -u -p -r1.39 acinclude.m4 >--- common/acinclude.m4 14 Jan 2006 14:46:20 -0000 1.39 >+++ common/acinclude.m4 26 Jan 2006 15:54:26 -0000 >@@ -82,3 +82,4 @@ AM_PROG_AS > > lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig >+export GEN_LIB=$lib >Index: frysk-core/common/acinclude.m4 >=================================================================== >RCS file: /cvs/frysk/frysk-common/acinclude.m4,v >retrieving revision 1.39 >diff -d -u -p -r1.39 acinclude.m4 >--- frysk-core/common/acinclude.m4 14 Jan 2006 14:46:20 -0000 1.39 >+++ frysk-core/common/acinclude.m4 26 Jan 2006 15:54:26 -0000 >@@ -82,3 +82,4 @@ AM_PROG_AS > > lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig >+export GEN_LIB=$lib >Index: frysk-gtk/common/acinclude.m4 >=================================================================== >RCS file: /cvs/frysk/frysk-common/acinclude.m4,v >retrieving revision 1.39 >diff -d -u -p -r1.39 acinclude.m4 >--- frysk-gtk/common/acinclude.m4 14 Jan 2006 14:46:20 -0000 1.39 >+++ frysk-gtk/common/acinclude.m4 26 Jan 2006 15:54:26 -0000 >@@ -82,3 +82,4 @@ AM_PROG_AS > > lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig >+export GEN_LIB=$lib >Index: frysk-gtk/tests/Makefile.am >=================================================================== >RCS file: /cvs/frysk/frysk-gtk/tests/Makefile.am,v >retrieving revision 1.1 >diff -d -u -p -r1.1 Makefile.am >--- frysk-gtk/tests/Makefile.am 5 Jan 2006 22:03:39 -0000 1.1 >+++ frysk-gtk/tests/Makefile.am 26 Jan 2006 15:54:26 -0000 >@@ -59,8 +59,8 @@ textiter/a.out: $(textiter_FILES) > $(GCJ) -g \ > -classpath $(FRYSK_GTK_CLASSPATH) \ > $(FRYSK_GTK_LIBS) \ >- -Wl,-rpath,/opt/frysk/lib:/usr/lib/frysk \ >- -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ >+ -Wl,-rpath,/opt/frysk/$(GEN_LIB):/usr/$(GEN_LIB)/frysk \ >+ -Djava.library.path=/opt/frysk/lib:/usr/$(GEN_LIB)/frysk \ > --main=textiter.JNICrash \ > -o textiter/a.out \ > $(srcdir)/textiter/JNICrash.java >@@ -73,8 +73,8 @@ gcjtreeiter/a.out: $(gcjtreeiter_FILES) > $(GCJ) -g \ > -classpath $(FRYSK_GTK_CLASSPATH) \ > $(FRYSK_GTK_LIBS) \ >- -Wl,-rpath,/opt/frysk/lib:/usr/lib/frysk \ >- -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ >+ -Wl,-rpath,/opt/frysk/lib:/usr/$(GEN_LIB)/frysk \ >+ -Djava.library.path=/opt/frysk/$(GEN_LIB):/usr/$(GEN_LIB)/frysk \ > --main=gcjtreeiter.IterTest \ > $(srcdir)/gcjtreeiter/IterTest.java \ > -o gcjtreeiter/a.out >@@ -85,7 +85,7 @@ gcjtreeiter/gij.sh: $(gcjtreeiter_FILES) > -classpath $(FRYSK_GTK_CLASSPATH) \ > $(srcdir)/gcjtreeiter/IterTest.java > echo $(GIJ) -classpath .:$(FRYSK_GTK_CLASSPATH) \ >- -Djava.library.path=/opt/frysk/lib:/usr/lib/frysk \ >+ -Djava.library.path=/opt/frysk/lib:/usr/$(GEN_LIB)/frysk \ > gcjtreeiter.IterTest \ > > gcjtreeiter/gij.sh > chmod a+x gcjtreeiter/gij.sh >Index: frysk-imports/common/acinclude.m4 >=================================================================== >RCS file: /cvs/frysk/frysk-common/acinclude.m4,v >retrieving revision 1.39 >diff -d -u -p -r1.39 acinclude.m4 >--- frysk-imports/common/acinclude.m4 14 Jan 2006 14:46:20 -0000 1.39 >+++ frysk-imports/common/acinclude.m4 26 Jan 2006 15:54:27 -0000 >@@ -82,3 +82,4 @@ AM_PROG_AS > > lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig >+export GEN_LIB=$lib >Index: frysk-sys/common/acinclude.m4 >=================================================================== >RCS file: /cvs/frysk/frysk-common/acinclude.m4,v >retrieving revision 1.39 >diff -d -u -p -r1.39 acinclude.m4 >--- frysk-sys/common/acinclude.m4 14 Jan 2006 14:46:20 -0000 1.39 >+++ frysk-sys/common/acinclude.m4 26 Jan 2006 15:54:27 -0000 >@@ -82,3 +82,4 @@ AM_PROG_AS > > lib=`pkg-config --debug 2>&1 |awk -F '/' '/^Scanning.*pkgconfig.$/ { print $(NF - 1); exit; }'` > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/frysk/$lib/pkgconfig:/usr/$lib/frysk/pkgconfig >+export GEN_LIB=$lib > > From dnovillo@redhat.com Thu Jan 26 16:25:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Thu, 26 Jan 2006 16:25:00 -0000 Subject: More /usr/lib64 fixes In-Reply-To: <43D8F786.6020004@redhat.com> References: <43D8F318.8020703@redhat.com> <43D8F786.6020004@redhat.com> Message-ID: <43D8F7F8.9020701@redhat.com> Andrew Cagney wrote: > Sure, however, while you're there, you might as well just wack > references to /opt/frysk/. > Will do. Thanks. From tromey@redhat.com Sat Jan 28 00:31:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Sat, 28 Jan 2006 00:31:00 -0000 Subject: typo on web page Message-ID: I noticed a couple of typos on the 'questions' page today. Patch appended. Perhaps the word 'jython' ought to be a link to www.jython.org... thoughts? Tom Index: questions/index.html =================================================================== RCS file: /cvs/frysk/htdocs/questions/index.html,v retrieving revision 1.2 diff -u -r1.2 index.html --- questions/index.html 26 Jan 2006 23:31:53 -0000 1.2 +++ questions/index.html 28 Jan 2006 00:30:19 -0000 @@ -140,8 +140,8 @@
    Yes.
    Because the frysk core is directly programmable, the addition of a scripting language such as Guile, Perl, or Python is more than -feasible. In fact, there has already been multiple proposals to -directly integrate jpython into frysk. +feasible. In fact, there have already been multiple proposals to +directly integrate jython into frysk.
    As for which scripting language? That choice is yours.
    Will there be a command-line interpreter?
    From cagney@redhat.com Sat Jan 28 20:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 28 Jan 2006 20:38:00 -0000 Subject: frysk-0.0.1.2006.01.28-0.EL4.1.src.rpm Message-ID: <43DBD656.1060809@redhat.com> A new RHEL-4 SRPM snapshot is available: ftp://sources.redhat.com/pub/frysk/RHEL-4/frysk-0.0.1.2006.01.28-0.EL4.1.src.rpm Thanks to Diego and Wu, this rpm has been successfully built on x86_64, and ppc64; testing continues. The RPM includes the following changes and fixes: * Sat Jan 28 2006 Andrew Cagney 0.0.1.2006.01.28-0.EL4.1 - Import frysk 0.0.1.2006.01.28; includes some 32/64 bit fixes. - Backport glib2 2.9.5, gtk 2 2.8.11, and fontconfig 2.3.93.cvs20060124. * Fri Jan 27 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.9 - For pango and gtk, store the config file in a path containing _host but canonicalized using config.sub. * Fri Jan 27 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.8 - Put pango.modules pack in the -host directory. - Delete conditional definition of frysk_gcc_prefix, and frysk_gcc_suffix. Doesn't work with older RPMs. * Fri Jan 27 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.7 - Conditionally define frysk_gcc_prefix and frysk_gcc_suffix. * Fri Jan 27 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.6 - Add the macros build_glib2, build_glib_java, build_fontconfig, build_atk, build_cairo, build_cairo_java, build_pango, build_gtk2, build_libgtk_java, build_libglade2, build_libglade_java, build_libvte_java, and build_jdom. Wrap corresponding build code. * Fri Jan 27 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.5 - Update antlr.patch, update includes Wu Zhou's basename fix, and up-to-date config.guess and config.sub. * Thu Jan 26 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.4 - From Diego Novello : Add libglade-java-20060125-fix-64bit-miscompilation.patch. * Thu Jan 26 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.3 - From Wu Zhou : Add -m64 to ppc64 CC et.al. * Mon Jan 23 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.2 - In -files, only list frysk.desktop and fryskTrayIcon48.png when build_frysk. - Define all install paths in terms of macros. * Mon Jan 23 2006 Andrew Cagney 0.0.1.2006.01.22-0.EL4.1 - Write pango.modules to %{_target_platform}, instead of %{_host} sub-directory. From cagney@redhat.com Tue Jan 31 17:52:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 31 Jan 2006 17:52:00 -0000 Subject: frysk and jython (Java Python) In-Reply-To: <1135007855.2998.49.camel@multics.rdu.redhat.com> References: <437BA9FB.5000005@redhat.com> <1135007855.2998.49.camel@multics.rdu.redhat.com> Message-ID: <43DFA40B.8090805@redhat.com> Stan Cox wrote: >On Wed, 2005-11-16 at 16:51 -0500, Andrew Cagney wrote: > > >>Here's a little proof-of-concept showing jython (http://www.jython.org), >> >> > > > Hmm, no idea. Can I suggest creating a bug report for this and hanging it off of http://sourceware.org/bugzilla/show_bug.cgi?id=2247 (frysk vs jython tracker). >The following works (interactively via >CLASSPATH=~/jython/jython.jar ./gij.sh org.python.util.jython) > >from frysk.proc import Manager >Manager.eventLoop.start () >h = Manager.host >me = h.getSelf () >print me >print me.getCommand() >print me.getTasks() >h.requestCreateAttachedProc (["sleep","1000"]) >me.getChildren() >child = me.getChildren()[0] > >but if you put it in a script and execute via >(CLASSPATH=~/jython/jython.jar ./gij.sh org.python.util.jython >script.jy) you get: >Traceback (innermost last): > File "/home/scox/accu/test.jy", line 10, in ? >KeyError: 0 > >It is convenient to type python scripts in an editor that will do the >indentation automatically. > > > From cagney@redhat.com Mon Feb 6 20:11:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 06 Feb 2006 20:11:00 -0000 Subject: funit (8) Message-ID: <43E7ADAF.8030601@redhat.com> Hello, Both continuing, and expanding frysk's emphasis on test driven development, the new program funit(8) has been added. Funit, which can be run as /usr/libexec/frysk/funit, runs all of frysk's non-graphical JUnit tests using the installed environment. Having this available makes it easier to check for: - bugs in frysk (no need to re-build) - bugs in the installed environment (yes, frysk's test suite is getting good at flushing out kernel and other bugs) This testsuite is also run automatically as part of <>. Andrew From dnovillo@redhat.com Wed Feb 8 16:26:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Wed, 08 Feb 2006 16:26:00 -0000 Subject: Update list of packages required to build frysk Message-ID: <43EA1BC8.6020000@redhat.com> Package xmlto is now needed. OK to install? Index: index.html =================================================================== RCS file: /cvs/frysk/htdocs/build/index.html,v retrieving revision 1.52 diff -d -u -p -r1.52 index.html --- index.html 30 Jan 2006 22:47:00 -0000 1.52 +++ index.html 8 Feb 2006 16:25:46 -0000 @@ -86,7 +86,7 @@ program). You will need to install a number of packages vis:
     sudo yum install antlr jdom glib-java libgtk-java \
    -libvte-java vte-devel libglade-java gcc-java
    +libvte-java vte-devel libglade-java gcc-java xmlto
     
    From scox@redhat.com Wed Feb 8 16:40:00 2006 From: scox@redhat.com (Stan Cox) Date: Wed, 08 Feb 2006 16:40:00 -0000 Subject: Update list of packages required to build frysk In-Reply-To: <43EA1BC8.6020000@redhat.com> References: <43EA1BC8.6020000@redhat.com> Message-ID: <1139416796.4469.18.camel@multics.rdu.redhat.com> On Wed, 2006-02-08 at 11:26 -0500, Diego Novillo wrote: > Package xmlto is now needed. OK to install? > > Index: index.html Would you mind changing a typo in that file while you are in the neighborhood? all its prerequesits are met. prerequisites > =================================================================== > RCS file: /cvs/frysk/htdocs/build/index.html,v > retrieving revision 1.52 > diff -d -u -p -r1.52 index.html > --- index.html 30 Jan 2006 22:47:00 -0000 1.52 > +++ index.html 8 Feb 2006 16:25:46 -0000 > @@ -86,7 +86,7 @@ program). > You will need to install a number of packages vis: >
    >  sudo yum install antlr jdom glib-java libgtk-java \
    > -libvte-java vte-devel libglade-java gcc-java
    > +libvte-java vte-devel libglade-java gcc-java xmlto
    >  
    > > From dnovillo@redhat.com Wed Feb 8 16:46:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Wed, 08 Feb 2006 16:46:00 -0000 Subject: Update list of packages required to build frysk In-Reply-To: <1139416796.4469.18.camel@multics.rdu.redhat.com> References: <43EA1BC8.6020000@redhat.com> <1139416796.4469.18.camel@multics.rdu.redhat.com> Message-ID: <43EA2052.6050709@redhat.com> Stan Cox wrote: > Would you mind changing a typo in that file while you are in the > neighborhood? > Sure. ispell found a couple more. OK? -------------- next part -------------- A non-text attachment was scrubbed... Name: 20060208-add-xmlto.diff Type: text/x-patch Size: 2280 bytes Desc: not available URL: From cagney@redhat.com Wed Feb 8 16:55:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Feb 2006 16:55:00 -0000 Subject: Update list of packages required to build frysk In-Reply-To: <1139416796.4469.18.camel@multics.rdu.redhat.com> References: <43EA1BC8.6020000@redhat.com> <1139416796.4469.18.camel@multics.rdu.redhat.com> Message-ID: <43EA22F1.4050504@redhat.com> Stan Cox wrote: >On Wed, 2006-02-08 at 11:26 -0500, Diego Novillo wrote: > > >>Package xmlto is now needed. OK to install? >> >>Index: index.html >> >> > >Would you mind changing a typo in that file while you are in the >neighborhood? > >all its prerequesits are met. > prerequisites > > > yes, both oblivious[sic] :-) > > >>=================================================================== >>RCS file: /cvs/frysk/htdocs/build/index.html,v >>retrieving revision 1.52 >>diff -d -u -p -r1.52 index.html >>--- index.html 30 Jan 2006 22:47:00 -0000 1.52 >>+++ index.html 8 Feb 2006 16:25:46 -0000 >>@@ -86,7 +86,7 @@ program). >> You will need to install a number of packages vis: >>
    >> sudo yum install antlr jdom glib-java libgtk-java \
    >>-libvte-java vte-devel libglade-java gcc-java
    >>+libvte-java vte-devel libglade-java gcc-java xmlto
    >> 
    >> >> >> >> > > > From dnovillo@redhat.com Wed Feb 8 22:06:00 2006 From: dnovillo@redhat.com (Diego Novillo) Date: Wed, 08 Feb 2006 22:06:00 -0000 Subject: x86_64: GUI stalls on startup Message-ID: <43EA6B50.3050803@redhat.com> This may or may not be related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179228, but it does look similar. On startup, FryskGui gets stuck. According to pstack: Thread 4 (Thread 1084229984 (LWP 23279)): #0 0x00002aaaaed97bef in sigsuspend () from /lib64/libc.so.6 #1 0x00002aaaae185d2b in GC_suspend_handler_inner () #2 #3 0x00002aaaaec5c506 in pthread_cond_wait@@GLIBC_2.3.2 () #4 0x00002aaaadc7c42c in _Jv_CondWait () from /usr/lib64/libgcj.so.7 #5 0x00002aaaadc66e2c in gnu::gcj::runtime::FinalizerThread::run () #6 0x00002aaaadc755e8 in _Jv_ThreadRun () from /usr/lib64/libgcj.so.7 #7 0x00002aaaadc7bfe7 in really_start () from /usr/lib64/libgcj.so.7 #8 0x00002aaaae184f66 in GC_start_routine () from /usr/lib64/libgcj.so.7 #9 0x00002aaaaec5916a in start_thread () from /lib64/libpthread.so.0 #10 0x00002aaaaee3348d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (Thread 1084496224 (LWP 23280)): #0 0x00002aaaaed97bef in sigsuspend () from /lib64/libc.so.6 #1 0x00002aaaae185d2b in GC_suspend_handler_inner () #2 #3 0x00002aaaaee2a8c6 in poll () from /lib64/libc.so.6 #4 0x00002aaaaca1bac1 in g_main_context_check () #5 0x00002aaaaca1bffe in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #6 0x00002aaab0a3c180 in link_set_io_thread () from /usr/lib64/libORBit-2.so.0 #7 0x00002aaaaca32eaf in g_thread_create_full () #8 0x00002aaaae184f66 in GC_start_routine () from /usr/lib64/libgcj.so.7 #9 0x00002aaaaec5916a in start_thread () from /lib64/libpthread.so.0 #10 0x00002aaaaee3348d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 1094986080 (LWP 23290)): #0 0x00002aaaaec5e15d in sem_wait () from /lib64/libpthread.so.0 #1 0x00002aaaae185ac8 in GC_stop_world () from /usr/lib64/libgcj.so.7 #2 0x00002aaaae176583 in GC_stopped_mark () from /usr/lib64/libgcj.so.7 #3 0x00002aaaae1768db in GC_try_to_collect_inner () #4 0x00002aaaae176b79 in GC_collect_or_expand () from /usr/lib64/libgcj.so.7 #5 0x00002aaaae1770e9 in GC_allocobj () from /usr/lib64/libgcj.so.7 #6 0x00002aaaae17b827 in GC_generic_malloc_inner () #7 0x00002aaaae17c404 in GC_generic_malloc_many () from /usr/lib64/libgcj.so.7 #8 0x00002aaaae1854c6 in GC_local_gcj_malloc () from /usr/lib64/libgcj.so.7 #9 0x00002aaaadc3c8bf in _Jv_AllocObjectNoFinalizer () #10 0x00002aaaadc3c916 in _Jv_AllocObject () from /usr/lib64/libgcj.so.7 #11 0x00002aaaadc7144e in java::lang::Object::clone () #12 0x00002aaaade8ca99 in java::util::AbstractMap::clone () #13 0x00002aaaade8cb4b in java::util::HashMap::clone () #14 0x00000000004d83fd in frysk::proc::LinuxProc$1$TidBuilder::finit$ () #15 0x00000000004d844f in frysk::proc::LinuxProc$1$TidBuilder::LinuxProc$1$TidBuilder () #16 0x00000000004d8477 in frysk::proc::LinuxProc::sendRefresh () #17 0x00000000004d7ec6 in frysk::proc::LinuxHost::sendRefresh () #18 0x00000000004d736a in frysk::proc::HostState$1::processRequestRefresh () #19 0x00000000004d6865 in frysk::proc::Host$1::execute () #20 0x00000000004d5ca1 in frysk::event::EventLoop::runEventLoop () #21 0x00000000004d5d53 in frysk::event::EventLoop::run () #22 0x00000000004a124a in frysk::gui::Gui$3::run () #23 0x00002aaaade24216 in java::lang::Thread::run () #24 0x00002aaaadc755e8 in _Jv_ThreadRun () from /usr/lib64/libgcj.so.7 #25 0x00002aaaadc7bfe7 in really_start () from /usr/lib64/libgcj.so.7 #26 0x00002aaaae184f66 in GC_start_routine () from /usr/lib64/libgcj.so.7 #27 0x00002aaaaec5916a in start_thread () from /lib64/libpthread.so.0 #28 0x00002aaaaee3348d in clone () from /lib64/libc.so.6 #29 0x0000000000000000 in ?? () Thread 1 (Thread 46912574140368 (LWP 23278)): #0 0x00002aaaaee2a8c6 in poll () from /lib64/libc.so.6 #1 0x00002aaaaca1bac1 in g_main_context_check () #2 0x00002aaaaca1bffe in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #3 0x00002aaaab793d13 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x00002aaaab1f2f1d in org::gnu::gtk::Gtk::gtk_main () #5 0x00000000004a1087 in frysk::gui::Gui::gui () #6 0x00000000004a029b in frysk::gui::FryskGui::main () #7 0x00002aaaadc675f3 in gnu::java::lang::MainThread::call_main () #8 0x00002aaaadc755e8 in _Jv_ThreadRun () from /usr/lib64/libgcj.so.7 #9 0x00002aaaadc3dcb5 in _Jv_RunMain () from /usr/lib64/libgcj.so.7 #10 0x00000000004a00a3 in main () Is anyone else seeing this? From cagney@redhat.com Fri Feb 10 17:05:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 10 Feb 2006 17:05:00 -0000 Subject: JUnit stack smash fix Message-ID: <43ECC833.6050506@redhat.com> FYI, I've just checked in a fix where, when running the JUnit tests, the program would (apparently) spontaneously sigsegv and die. I traced the problem back to another case of GCJ and FRYSK fighting over who was in control of SIGCHLD. GCJ, instead of using a shared library, uses separate processes for things like demangling and addr2line look up. I've disabled that code. Unfortunatly that also means that GCJ stack-traces are not as nice as they once were. Andrew From ezannoni@redhat.com Tue Feb 21 15:43:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Tue, 21 Feb 2006 15:43:00 -0000 Subject: Dropping FC4 as platform Message-ID: <17403.13626.467834.19738@localhost.redhat.com> Since we are close to enabling 64-bit builds, and given FC5 is about to be come out, let's drop FC4 as a supported platform. If anybody out there is worried about FC4, they are welcome to submit patches to keep frysk working on it, but we are not going to worry about it. As the compiler gets more fixes and better debuginfo support, it will become harder and harder to backport those to FC4, as well. From woodzltc@cn.ibm.com Tue Feb 21 16:36:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 21 Feb 2006 16:36:00 -0000 Subject: Xlib error (sequence lost in reply type 0x0) on PPC64 Message-ID: Hi, I am tryig to build and run Frysk, heavily using Java-Gnome, on PPC64. The platform I am using is FC5 test2, with all the packages being the rawhide (ok, about a week ago). Frysk build ok and start also ok. But when I click on a random process in the process view, it report Xlib error: sequence lost (0x10000 > > 0x2080) in reply type 0x0! There is no such error in x86 platform. I am now suspecting that it might be related with Java-Gnome on PPC64 (anybody else else tried Java-Gnome on this platform, please let me know. :-) The reason is that when I attach GDB to the running Frysk, I sometimes get SEGV signal at cario function, such as: (gdb) c Continuing. [New Thread 4398185484880 (LWP 2466)] [New Thread 4398200185424 (LWP 2467)] [New Thread 4398210671184 (LWP 2468)] [Thread 4398200185424 (LWP 2467) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4398210671184 (LWP 2468)] _cairo_surface_show_glyphs (scaled_font=0x10b2f3b0, operator=CAIRO_OPERATOR_DEST_OUT, pattern=0x40009c8bec8, dst=0x0, source_x=10, source_y=2, dest_x=10, dest_y=2, width=103, height=10, glyphs=0x10d2e0a0, num_glyphs=13) at cairo-surface.c:1487 1487 if (dst->status) (gdb) p dst $1 = (cairo_surface_t *) 0x0 (gdb) bt #0 _cairo_surface_show_glyphs (scaled_font=0x10b2f3b0, operator=CAIRO_OPERATOR_DEST_OUT, pattern=0x40009c8bec8, dst=0x0, source_x=10, source_y=2, dest_x=10, dest_y=2, width=103, height=10, glyphs=0x10d2e0a0, num_glyphs=13) at cairo-surface.c:1487 #1 0x000000805d8de354 in _cairo_scaled_font_show_glyphs (scaled_font=0x10b2f3b0, operator=CAIRO_OPERATOR_DEST_OUT, pattern=0x40009c8bec8, surface=0x0, source_x=10, source_y=2, dest_x=10, dest_y=2, width=103, height=10, glyphs=0x10d2e0a0, num_glyphs=13) at cairo-font.c:930 #2 0x000000805d8e0048 in _cairo_gstate_show_glyphs_draw_func (closure=0x40009c8c160, operator=CAIRO_OPERATOR_DEST_OUT, src=0x40009c8bec8, dst=0x0, dst_x=0, dst_y=0, extents=0x40009c8c188) at cairo-gstate.c:2053 #3 0x000000805d8e1274 in _cairo_gstate_clip_and_composite (clip=0x10d300a0, operator=CAIRO_OPERATOR_DEST_OUT, src=0x40009c8bec8, draw_func=@0x805d933900: 0x805d8dfef0 <_cairo_gstate_show_glyphs_draw_func>, draw_closure=0x40009c8c160, dst=0x0, extents=0x40009c8c188) at cairo-gstate.c:1094 #4 0x000000805d8e15b0 in _cairo_gstate_show_glyphs (gstate=0x10d30000, glyphs=Variable "glyphs" is not available. ) at cairo-gstate.c:2131 #5 0x000000805d8d8418 in cairo_show_glyphs (cr=0x10d29ff0, glyphs=Variable "glyphs" is not available. ) at cairo.c:2158 #6 0x000000805d368efc in .pango_cairo_show_glyph_string () from /usr/lib64/libpangocairo-1.0.so.0 #7 0x000000805d3171e0 in .pango_renderer_draw_glyphs () from /usr/lib64/libpango-1.0.so.0 #8 0x000000805d367fd0 in .pango_cairo_show_glyph_string () from /usr/lib64/libpangocairo-1.0.so.0 #9 0x000000805d98542c in .gdk_draw_layout_line () from /usr/lib64/libgdk-x11-2.0.so.0 #10 0x000000805d3171e0 in .pango_renderer_draw_glyphs () from /usr/lib64/libpango-1.0.so.0 #11 0x000000805d317794 in .pango_renderer_draw_layout_line () from /usr/lib64/libpango-1.0.so.0 #12 0x000000805d317b90 in .pango_renderer_draw_layout () from /usr/lib64/libpango-1.0.so.0 #13 0x000000805d983c2c in .gdk_draw_layout_with_colors () from /usr/lib64/libgdk-x11-2.0.so.0 ---Type to continue, or q to quit--- Be noted that dst is zero at this point. Any thought on this? For a more detailed description, you can refer to http://sourceware.org/bugzilla/show_bug.cgi?id=2355 If you need any additional information, just let me know. Thanks. - Wu Zhou From cagney@redhat.com Tue Feb 21 16:47:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 21 Feb 2006 16:47:00 -0000 Subject: Dropping FC4 as platform In-Reply-To: <17403.13626.467834.19738@localhost.redhat.com> References: <17403.13626.467834.19738@localhost.redhat.com> Message-ID: <43FB444D.6000200@redhat.com> Elena Zannoni wrote: >Since we are close to enabling 64-bit builds, and given FC5 is about to >be come out, let's drop FC4 as a supported platform. > >If anybody out there is worried about FC4, they are welcome to submit >patches to keep frysk working on it, but we are not going to worry >about it. As the compiler gets more fixes and better debuginfo >support, it will become harder and harder to backport those to FC4, as >well. > > Elena, here's a brief breakdown: ptrace-exec gcj-gc gcj Java-GNOME FC-5 broken(1) broken(3) ok ok FC-4 broken|ok(2) ok broken(4) mega-rpm(5) RHEL4 ok ok ok mega-rpm badger ? ? broken(6) missing(6) (1) ptrace, when the non-main thread does an exec, is broken; on FC-5 blocker list? (2) see (1); broke it latest kernel; workaround is to avoid the latest kernel (3) the garbage collector deadlocks; fix looming (4) FC-4 gcj is missing fixes found on RHEL-4; workaround by building installing RHEL-4 gcj snapshot (5) Assuming (4) installed; the RHEL-4 mega-rpm can be built and installed (6) Breezy Badger needs both upstream compiler, and upstream Java-GNOME bindings to build. So as soon as those two remaining FC-5 issues are fixed (I think gcj-gc is about to go through); I'd agree that we can switch. From ezannoni@redhat.com Tue Feb 21 18:55:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Tue, 21 Feb 2006 18:55:00 -0000 Subject: Dropping FC4 as platform In-Reply-To: <43FB444D.6000200@redhat.com> References: <17403.13626.467834.19738@localhost.redhat.com> <43FB444D.6000200@redhat.com> Message-ID: <17403.25139.139394.52824@localhost.redhat.com> Andrew Cagney writes: > Elena Zannoni wrote: > > >Since we are close to enabling 64-bit builds, and given FC5 is about to > >be come out, let's drop FC4 as a supported platform. > > > >If anybody out there is worried about FC4, they are welcome to submit > >patches to keep frysk working on it, but we are not going to worry > >about it. As the compiler gets more fixes and better debuginfo > >support, it will become harder and harder to backport those to FC4, as > >well. > > > > > Elena, here's a brief breakdown: > > ptrace-exec gcj-gc gcj Java-GNOME > FC-5 broken(1) broken(3) ok ok > FC-4 broken|ok(2) ok broken(4) mega-rpm(5) > RHEL4 ok ok ok mega-rpm > badger ? ? broken(6) missing(6) > > (1) ptrace, when the non-main thread does an exec, is broken; on FC-5 > blocker list? Bug number? > (2) see (1); broke it latest kernel; workaround is to avoid the latest > kernel Ok that's another argument in favor of not worrying about fc4. > (3) the garbage collector deadlocks; fix looming bug #? > (4) FC-4 gcj is missing fixes found on RHEL-4; workaround by building > installing RHEL-4 gcj snapshot Available anywhere? > (5) Assuming (4) installed; the RHEL-4 mega-rpm can be built and installed Available anywhere? > (6) Breezy Badger needs both upstream compiler, and upstream Java-GNOME > bindings to build. > Ok, again a matter of resources. We should keep an eye on how/if frysk works on it, but for now it cannot be a priority, since we have only limited control on those packages. > So as soon as those two remaining FC-5 issues are fixed (I think gcj-gc > is about to go through); I'd agree that we can switch. > Define switch. We really can't afford to look after FC4 right now. Let's publish the workarounds on the webpages and leave it at that. From cagney@redhat.com Tue Feb 21 21:27:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 21 Feb 2006 21:27:00 -0000 Subject: Dropping FC4 as platform In-Reply-To: <17403.25139.139394.52824@localhost.redhat.com> References: <17403.13626.467834.19738@localhost.redhat.com> <43FB444D.6000200@redhat.com> <17403.25139.139394.52824@localhost.redhat.com> Message-ID: <43FB85F3.8090202@redhat.com> Elena Zannoni wrote: >Andrew Cagney writes: > > Elena Zannoni wrote: > > > > >Since we are close to enabling 64-bit builds, and given FC5 is about to > > >be come out, let's drop FC4 as a supported platform. > > > > > >If anybody out there is worried about FC4, they are welcome to submit > > >patches to keep frysk working on it, but we are not going to worry > > >about it. As the compiler gets more fixes and better debuginfo > > >support, it will become harder and harder to backport those to FC4, as > > >well. > > > > > > > > Elena, here's a brief breakdown: > > > > ptrace-exec gcj-gc gcj Java-GNOME > > FC-5 broken(1) broken(3) ok ok > > FC-4 broken|ok(2) ok broken(4) mega-rpm(5) > > RHEL4 ok ok ok mega-rpm > > badger ? ? broken(6) missing(6) > > > > (1) ptrace, when the non-main thread does an exec, is broken; on FC-5 > > blocker list? > >Bug number? > > FC-5: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177240 FC-4: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180484 > > (2) see (1); broke it latest kernel; workaround is to avoid the latest > > kernel > >Ok that's another argument in favor of not worrying about fc4. > > > Once fixed in FC-5 yes. The state is: FC-5: no workaround FC-4: workaround available (downgrade kernel) and until it's fixed we've test cases that won't pass. > > (3) the garbage collector deadlocks; fix looming > >bug #? > > FC-5: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180637 gcc: ? > > (4) FC-4 gcj is missing fixes found on RHEL-4; workaround by building > > installing RHEL-4 gcj snapshot > >Available anywhere? > > http://sourceware.org/frysk/build/index.html#fc4 ftp://sources.redhat.com/pub/frysk/RHEL-4/gcc-4.0.2-20051130-frysk-4.0.2-14.EL4.tar.bz2 > > (5) Assuming (4) installed; the RHEL-4 mega-rpm can be built and installed > >Available anywhere? > > http://sourceware.org/frysk/build/index.html#fc4 eg: ftp://sources.redhat.com/pub/frysk/RHEL-4/frysk-0.0.1.2006.01.28-0.EL4.1.src.rpm > > (6) Breezy Badger needs both upstream compiler, and upstream Java-GNOME > > bindings to build. > > > >Ok, again a matter of resources. We should keep an eye on how/if frysk >works on it, but for now it cannot be a priority, since we have only >limited control on those packages. > > > > > So as soon as those two remaining FC-5 issues are fixed (I think gcj-gc > > is about to go through); I'd agree that we can switch. > > > >Define switch. We really can't afford to look after FC4 right now. >Let's publish the workarounds on the webpages and leave it at that. > > Switch testing from RHEL-4+FC-4 to RHEL-4+FC-5. Something addressing the ptrace-exec bug (someone got an old working kernel :-) and gc-deadlock (I know the patch is looming) are needed before the switch. -- From cagney@redhat.com Wed Mar 1 05:30:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 01 Mar 2006 05:30:00 -0000 Subject: 64-bit frysk for x86-64 FC-5 Message-ID: <44053170.4020606@redhat.com> FYI, As a result of much hard work from Diego, Sami, Adam and Wu, we've achieved the goal of a 64-bit build of the frysk GUI (Java-GNOME based) running on an x86-64 FC-5 pre-release machine. We'll be pushing the relevant fixes into the official FC-5. Next is to work through the core and the x86-64 issues that we are now able to expose. Andrew From woodzltc@cn.ibm.com Wed Mar 1 16:02:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 01 Mar 2006 16:02:00 -0000 Subject: 64-bit frysk for x86-64 FC-5 In-Reply-To: <44053170.4020606@redhat.com> References: <44053170.4020606@redhat.com> Message-ID: On Wed, 1 Mar 2006, Andrew Cagney wrote: > FYI, > > As a result of much hard work from Diego, Sami, Adam and Wu, we've achieved > the goal of a 64-bit build of the frysk GUI (Java-GNOME based) running on an > x86-64 FC-5 pre-release machine. We'll be pushing the relevant fixes into the > official FC-5. That is great, Andrew. Could you please tell me where I can get the related source? I'd like to have a try with that on PPC64. > Next is to work through the core and the x86-64 issues that we are now able to > expose. Could you elaborate a little? Do you mean that you are going to work thru the frysk-core classes, or run the testcases on x86-64 to see what can be exposed? Or any others? Regards - Wu Zhou From cagney@redhat.com Wed Mar 1 16:41:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 01 Mar 2006 16:41:00 -0000 Subject: 64-bit frysk for x86-64 FC-5 In-Reply-To: References: <44053170.4020606@redhat.com> Message-ID: <4405CED1.6070102@redhat.com> Wu Zhou wrote: >On Wed, 1 Mar 2006, Andrew Cagney wrote: > > > >>FYI, >> >>As a result of much hard work from Diego, Sami, Adam and Wu, we've achieved >>the goal of a 64-bit build of the frysk GUI (Java-GNOME based) running on an >>x86-64 FC-5 pre-release machine. We'll be pushing the relevant fixes into the >>official FC-5. >> >> > >That is great, Andrew. Could you please tell me where I can get the >related source? I'd like to have a try with that on PPC64. > > > At present the fixes are in the Java-GNOME CVS repo, the'll eventually appear as RPMs in the FC-5 yum repo. >>Next is to work through the core and the x86-64 issues that we are now able to >>expose. >> >> > >Could you elaborate a little? Do you mean that you are going to work thru >the frysk-core classes, or run the testcases on x86-64 to see what can be >exposed? Or any others? > > > The latter, work through the testsuite. Andrew From woodzltc@cn.ibm.com Thu Mar 2 02:53:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 02 Mar 2006 02:53:00 -0000 Subject: 64-bit frysk for x86-64 FC-5 In-Reply-To: <4405CED1.6070102@redhat.com> References: <44053170.4020606@redhat.com> <4405CED1.6070102@redhat.com> Message-ID: On Wed, 1 Mar 2006, Andrew Cagney wrote: > Wu Zhou wrote: > > > On Wed, 1 Mar 2006, Andrew Cagney wrote: > > > > > > > FYI, > > > > > > As a result of much hard work from Diego, Sami, Adam and Wu, we've > > > achieved > > > the goal of a 64-bit build of the frysk GUI (Java-GNOME based) running on > > > an > > > x86-64 FC-5 pre-release machine. We'll be pushing the relevant fixes into > > > the > > > official FC-5. > > > > > > > That is great, Andrew. Could you please tell me where I can get the related > > source? I'd like to have a try with that on PPC64. > > > > > At present the fixes are in the Java-GNOME CVS repo, the'll eventually appear > as RPMs in the FC-5 yum repo. Thanks. I am not sure how to build Java-GNOME from CVS yet. But I will find a chance to have a try. > > > Next is to work through the core and the x86-64 issues that we are now > > > able to > > > expose. > > > > > > > Could you elaborate a little? Do you mean that you are going to work thru > > the frysk-core classes, or run the testcases on x86-64 to see what can be > > exposed? Or any others? > > > > > The latter, work through the testsuite. That is good. Is there anyway for me to know your progress on that? I am very interested in knowing how these testsuite work in x86-64. Regards - Wu Zhou From woodzltc@cn.ibm.com Wed Mar 8 06:42:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 08 Mar 2006 06:42:00 -0000 Subject: the result of "make check" on PPC64/FC5 Message-ID: Hello all, I had a try with the latest cvs tree today. The result of "make check" in frysk-imports directory is like this: XFAIL: nestcall/Nest XFAIL: samename/SameName XFAIL: samename/WrongVariable XFAIL: samename/WrongScope.gcj XPASS: packagename/O.out XFAIL: werror/java.sh XFAIL: gcc8544/gcj.sh PASS: logger/Npe PASS: anoncall/Anon PASS: cniinner/a.out PASS: packagename/C.out PASS: werror/cxx.sh PASS: rh174912/gcj.sh PASS: rh174912ice/gcj.sh PASS: rh175569/gcj.sh PASS: process/single_exec PASS: process/multi_child_exec PASS: process/multi_parent_exec PASS: process/multi_child_parent_exec PASS: wrongclass/gcj.sh PASS: cdtparserversion/cdttest.sh PASS: cmdline/print PASS: rh177240/strace-clone-exec.sh PASS: gctest/GCTest PASS: vfork-exec/vfork-exec ============================================================== 1 of 25 tests did not behave as expected (1 unexpected passes) ============================================================== packagename/O.out reports XPASS (unexpected pass). What is this check for? I also notice that packagename/C.out reports PASS. So the expected result is that: Class.forName ("packagename.C").getPackage() returns non-null; and O.class.getPackage() returns null? What is the result on x86? The result of "make check" in frysk-gtk directoy is: SKIP: gcjtreeiter/a.out SKIP: gcjtreeiter/gij.sh SKIP: textiter/a.out ====================== All 0 tests passed (3 tests were not run) ====================== I don't have any look into these. Anyone can give me a clue what is the potential problem? To Diego, Andrew told me that you are working on x86-64 port. So I guess that you might be interested in what is going on in PPC64 platform. Then I include you on the cc-list. Please also cc me if you find anything new on x86-64. Progress, problems, test results, all these kinds of thing I am interested. :-) Thanks - Wu Zhou From woodzltc@cn.ibm.com Wed Mar 8 06:52:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 08 Mar 2006 06:52:00 -0000 Subject: the results of TestRunner on PPC64/FC5 Message-ID: I also run TestRunner in different frysk-* directory. I post the results here too. [root@plinuxt2 frysk-sys]# ./TestRunner Running testIA32(frysk.sys.proc.TestAuxv) ...PASS Running testAMD64(frysk.sys.proc.TestAuxv) ...PASS Running testIA64(frysk.sys.proc.TestAuxv) ...PASS Running testPPC32(frysk.sys.proc.TestAuxv) ...PASS Running testPPC64(frysk.sys.proc.TestAuxv) ...PASS Running test(frysk.sys.proc.TestCmdLine) ...PASS Running test_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0_c0(frysk.sys.proc.TestCmdLine) ...PASS Running testIA32(frysk.sys.proc.TestMaps) ...PASS Running testIA64(frysk.sys.proc.TestMaps) ...PASS Running testAMD64(frysk.sys.proc.TestMaps) ...PASS Running testPPC32(frysk.sys.proc.TestMaps) ...PASS Running testPPC64(frysk.sys.proc.TestMaps) ...PASS Running testFillEmpty(frysk.sys.TestSigSet) ...PASS Running testAddRemove(frysk.sys.TestSigSet) ...PASS Running testList(frysk.sys.TestSigSet) ...PASS Running testProcMask(frysk.sys.TestSigSet) ...PASS Time: 0.014 OK (22 tests) [root@plinuxt2 frysk-imports]# ./TestRunner Running testGet(inua.eio.TestGet) ...PASS Running testMmap(inua.eio.TestMmap) ...PASS Running testPut(inua.eio.TestPut) ...PASS Running testGetWord(inua.eio.TestWordSize) ...PASS Running testRest(inua.eio.TestWordSize) ...PASS Running testParamaterlessPool(inua.util.TestPool) ...PASS Running testParameteredPool(inua.util.TestPool) ...PASS Time: 0.048 OK (7 tests) In directory frysk-core, there are four case failures: frysk.proc.TestI386Modify, frysk.proc.TestI386Regs, frysk.proc.TestSyscallOpen and frysk.proc.TestSyscallInterrupt [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallInterrupt Running testSyscallInterrupt(frysk.proc.TestSyscallInterrupt) ...ptrace: Input/output error [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallOpen Running testSyscallOpen(frysk.proc.TestSyscallOpen) ...ptrace: Input/output error [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Modify Running testI386Modify(frysk.proc.TestI386Modify) ...ptrace: Input/output error [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Regs Running testI386Regs(frysk.proc.TestI386Regs) ...ptrace: Input/output error Didn't look into these failure yet. Just post the problems here for recording. If anyone could give me any hints, that will be much appreciated! :-) All the other cases report PASS, with totally 91 tests: [root@plinuxt2 frysk-core]# ./TestRunner frysk.event.TestEventLoop frysk.event.TestSigChild frysk.proc.TestHostGet frysk.proc.TestRefresh frysk.proc.TestTaskTerminateObserver frysk.proc.TestProcGet frysk.proc.TestTasksObserver frysk.proc.TestTaskObserverBlocked frysk.proc.TestTaskForkedObserver frysk.proc.TestSyscall frysk.proc.TestTaskClonedObserver frysk.proc.TestTaskObserverDetach frysk.proc.TestRun frysk.proc.TestTaskObserver frysk.proc.TestSyscall2 frysk.proc.TestExec frysk.dom.TestDOM Running testEventLoop(frysk.event.TestEventLoop) ...PASS Running testPeriodicTimer(frysk.event.TestEventLoop) ...PASS Running testTimerRemoval(frysk.event.TestEventLoop) ...PASS Running testScheduleBeforeRun(frysk.event.TestEventLoop) ...PASS Running testSignalHandler(frysk.event.TestEventLoop) ...PASS Running testAsync(frysk.event.TestEventLoop) ...PASS Running testAAA(frysk.event.TestSigChild) ...PASS Running testBBB(frysk.event.TestSigChild) ...PASS Running testGetSelf(frysk.proc.TestHostGet) ...PASS Running testRepeatedHostRefresh(frysk.proc.TestRefresh) ...PASS Running testHostRefresh(frysk.proc.TestRefresh) ...PASS Running testProcRefresh(frysk.proc.TestRefresh) ...PASS Running testRefreshAll(frysk.proc.TestRefresh) ...PASS Running testParentChild(frysk.proc.TestRefresh) ...PASS Running testRefreshDaemon(frysk.proc.TestRefresh) ...PASS Running testExitLoosesChild(frysk.proc.TestRefresh) ...PASS Running testRefreshZombie(frysk.proc.TestRefresh) ...PASS Running testUnattachedSingleExec(frysk.proc.TestRefresh) ...PASS Running testUnattachedMultipleExec(frysk.proc.TestRefresh) ...PASS Running testTerminateExit0(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminateExit47(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminateKillINT(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminateKillKILL(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminateKillHUP(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatingExit0(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatingExit47(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatingKillINT(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatingKillKILL(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatingKillHUP(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatedExit0(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatedExit47(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatedKillINT(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatedKillKILL(frysk.proc.TestTaskTerminateObserver) ...PASS Running testTerminatedKillHUP(frysk.proc.TestTaskTerminateObserver) ...PASS Running testGetAuxv(frysk.proc.TestProcGet) ...PASS Running testGetCommand(frysk.proc.TestProcGet) ...PASS Running testGetTasks(frysk.proc.TestProcGet) ...PASS Running testGetChildren(frysk.proc.TestProcGet) ...PASS Running testGetCmdLine(frysk.proc.TestProcGet) ...PASS Running testGetExe(frysk.proc.TestProcGet) ...PASS Running testTasksObserver(frysk.proc.TestTasksObserver) ...PASS Running testGetBlockers(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockedCloneUnblockChildFirst(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockedCloneUnblockParentFirst(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockedForkUnblockChildFirst(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockedForkUnblockParentFirst(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockingFibonacciClone(frysk.proc.TestTaskObserverBlocked) ...PASS Running testBlockingFibonacciFork(frysk.proc.TestTaskObserverBlocked) ...PASS Running testUnblockRunning(frysk.proc.TestTaskObserverBlocked) ...PASS Running testTaskForkedObserver(frysk.proc.TestTaskForkedObserver) ...PASS Running testSyscall(frysk.proc.TestSyscall) ...PASS Running testTaskCloneObserver(frysk.proc.TestTaskClonedObserver) ...PASS Running testDetachFork(frysk.proc.TestTaskObserverDetach) ...<>PASS Running testDetachClone(frysk.proc.TestTaskObserverDetach) ...PASS Running testDetachExec(frysk.proc.TestTaskObserverDetach) ...PASS Running testDetachSignal(frysk.proc.TestTaskObserverDetach) ...PASS Running testCreateAttachedContinuedProc(frysk.proc.TestRun) ...PASS Running testCreateAttachedStoppedProc(frysk.proc.TestRun) ...PASS Running testAddObserverToRunning(frysk.proc.TestTaskObserver) ...PASS Running testAttachDetachMainTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDetachOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDetachManyTasks(frysk.proc.TestTaskObserver) ...PASS Running testDetachExitingMainTask(frysk.proc.TestTaskObserver) ...PASS Running testDetachExitingOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDeadMainTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDeadOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDieingMainTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachDieingOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachToAttachedMainTask(frysk.proc.TestTaskObserver) ...PASS Running testAttachToAttachedOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testBackToBackAttachAttachMainTask(frysk.proc.TestTaskObserver) ...PASS Running testBackToBackAttachAttachOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testBackToBackAttachDetachMainTask(frysk.proc.TestTaskObserver) ...PASS Running testBackToBackAttachDetachOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testDeletedAttachMainTask(frysk.proc.TestTaskObserver) ...PASS Running testDeletedAttachOtherTask(frysk.proc.TestTaskObserver) ...PASS Running testDeleteUnattachedFromAttachedMain(frysk.proc.TestTaskObserver) ...PASS Running testDeleteUnattachedFromDetachedMain(frysk.proc.TestTaskObserver) ...PASS Running testAttachDetachRapidlyCloningMainTask(frysk.proc.TestTaskObserver) ...PASS Running testSyscall2(frysk.proc.TestSyscall2) ...PASS Running testProcExec(frysk.proc.TestExec) ...PASS Running testTaskExec(frysk.proc.TestExec) ...PASS Running testAttachedSingleExec(frysk.proc.TestExec) ...PASS Running testAttachedMultipleParentExec(frysk.proc.TestExec) ...PASS Running testAttachedMultipleChildExec(frysk.proc.TestExec) ...PASS Running testDOMFrysk(frysk.dom.TestDOM) ...PASS Running testDOMImage(frysk.dom.TestDOM) ...PASS Running testDOMFunction(frysk.dom.TestDOM) ...PASS Running testDOMsource(frysk.dom.TestDOM) ...PASS Running testDOMLine(frysk.dom.TestDOM) ...PASS Running testDOMInlineInstance(frysk.dom.TestDOM) ...PASS Time: 9.945 OK (91 tests) Regards - Wu Zhou From woodzltc@cn.ibm.com Wed Mar 8 06:59:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 08 Mar 2006 06:59:00 -0000 Subject: the result of "make check" on PPC64/FC5 In-Reply-To: References: Message-ID: Oops, I should have mentioned that I am running these tests on kernel 2.6.15, with Andrea Arcangeli's ptrace patch reversed. Maybe I should run these tests on FC5 kernel, and reverse Andrea Arcangeli's ptrace patch? Is there much difference between the 2.6.15 kernel of FC5 and the official 2.6.15 kernel from kernel.org? Regards - Wu Zhou On Wed, 8 Mar 2006, Wu Zhou wrote: > Hello all, > > I had a try with the latest cvs tree today. > > The result of "make check" in frysk-imports directory is like this: > > XFAIL: nestcall/Nest > XFAIL: samename/SameName > XFAIL: samename/WrongVariable > XFAIL: samename/WrongScope.gcj > XPASS: packagename/O.out > XFAIL: werror/java.sh > XFAIL: gcc8544/gcj.sh > PASS: logger/Npe > PASS: anoncall/Anon > PASS: cniinner/a.out > PASS: packagename/C.out > PASS: werror/cxx.sh > PASS: rh174912/gcj.sh > PASS: rh174912ice/gcj.sh > PASS: rh175569/gcj.sh > PASS: process/single_exec > PASS: process/multi_child_exec > PASS: process/multi_parent_exec > PASS: process/multi_child_parent_exec > PASS: wrongclass/gcj.sh > PASS: cdtparserversion/cdttest.sh > PASS: cmdline/print > PASS: rh177240/strace-clone-exec.sh > PASS: gctest/GCTest > PASS: vfork-exec/vfork-exec > ============================================================== > 1 of 25 tests did not behave as expected (1 unexpected passes) > ============================================================== > > packagename/O.out reports XPASS (unexpected pass). What is this check > for? I also notice that packagename/C.out reports PASS. So the expected > result is that: Class.forName ("packagename.C").getPackage() returns > non-null; and O.class.getPackage() returns null? What is the result on > x86? > > The result of "make check" in frysk-gtk directoy is: > > SKIP: gcjtreeiter/a.out > SKIP: gcjtreeiter/gij.sh > SKIP: textiter/a.out > ====================== > All 0 tests passed > (3 tests were not run) > ====================== > > I don't have any look into these. Anyone can give me a clue what is the > potential problem? > > To Diego, > > Andrew told me that you are working on x86-64 port. So I guess that you > might be interested in what is going on in PPC64 platform. Then I > include you on the cc-list. Please also cc me if you find anything new on > x86-64. Progress, problems, test results, all these kinds of thing I am > interested. :-) > > Thanks > - Wu Zhou > > From cagney@redhat.com Wed Mar 8 15:57:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Mar 2006 15:57:00 -0000 Subject: the result of "make check" on PPC64/FC5 In-Reply-To: References: Message-ID: <440EFF3B.2060509@redhat.com> Wu Zhou wrote: >Oops, I should have mentioned that I am running these tests on kernel >2.6.15, with Andrea Arcangeli's ptrace patch reversed. > >Maybe I should run these tests on FC5 kernel, and reverse Andrea >Arcangeli's ptrace patch? > >Is there much difference between the 2.6.15 kernel of FC5 and the official >2.6.15 kernel from kernel.org? > >Regards >- Wu Zhou > >On Wed, 8 Mar 2006, Wu Zhou wrote: > > > >>Hello all, >> >>I had a try with the latest cvs tree today. >> >>The result of "make check" in frysk-imports directory is like this: >> >>XFAIL: nestcall/Nest >>XFAIL: samename/SameName >>XFAIL: samename/WrongVariable >>XFAIL: samename/WrongScope.gcj >>XPASS: packagename/O.out >>XFAIL: werror/java.sh >>XFAIL: gcc8544/gcj.sh >>PASS: logger/Npe >>PASS: anoncall/Anon >>PASS: cniinner/a.out >>PASS: packagename/C.out >>PASS: werror/cxx.sh >>PASS: rh174912/gcj.sh >>PASS: rh174912ice/gcj.sh >>PASS: rh175569/gcj.sh >>PASS: process/single_exec >>PASS: process/multi_child_exec >>PASS: process/multi_parent_exec >>PASS: process/multi_child_parent_exec >>PASS: wrongclass/gcj.sh >>PASS: cdtparserversion/cdttest.sh >>PASS: cmdline/print >>PASS: rh177240/strace-clone-exec.sh >>PASS: gctest/GCTest >>PASS: vfork-exec/vfork-exec >>============================================================== >>1 of 25 tests did not behave as expected (1 unexpected passes) >>============================================================== >> >>packagename/O.out reports XPASS (unexpected pass). What is this check >>for? I also notice that packagename/C.out reports PASS. So the expected >>result is that: Class.forName ("packagename.C").getPackage() returns >>non-null; and O.class.getPackage() returns null? What is the result on >>x86? >> >> XFAIL roughly means, there's a bug but it's not frysk's fault. Here older GCC's were broken - the XFAIL - gcc 4.1 however is fixed. Since so far hasn't been bitten by that specific bug (it was bitten by packagename/C) it failing isn't too much of a worry. BTW, last night I committed some more 64-bit fixage for the above, I guess x86-64 is more sensitive. >>The result of "make check" in frysk-gtk directoy is: >> >>SKIP: gcjtreeiter/a.out >>SKIP: gcjtreeiter/gij.sh >>SKIP: textiter/a.out >>====================== >>All 0 tests passed >>(3 tests were not run) >>====================== >> >> >> If there's no $DISPLAY, the tests are skipped. Since they play with GTK they can't pass without an X display - now if anyone knows how to get around this, is xvfb (x virtual frame buffer) still available somewhere? >>I don't have any look into these. Anyone can give me a clue what is the >>potential problem? >> >>To Diego, >> >>Andrew told me that you are working on x86-64 port. So I guess that you >>might be interested in what is going on in PPC64 platform. Then I >>include you on the cc-list. Please also cc me if you find anything new on >>x86-64. Progress, problems, test results, all these kinds of thing I am >>interested. :-) >> >>Thanks >>- Wu Zhou >> >> >> >> Andrew From cagney@redhat.com Wed Mar 8 16:10:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Mar 2006 16:10:00 -0000 Subject: mailing list re-org Message-ID: <440F023A.5080905@redhat.com> At present frysk, in addition to the irc channel, has two mailing lists: - frysk@ for occasional discussion and announcements (most discussion occurs on gimp.net/frysk) - frysk-cvs@ for cvs commits Missing from this is a mailing list carrying the bugzilla updates and changes, I can see two ways of integrating this information: - frysk@ for all development including bug information and possibly even cvs?; frysk-announce@ for occasional announcements - frysk@ as is; frysk-bugzilla@ for bugzilla Since tracking the project involves monitoring the discussion, bugs, and cvs changes, I've a vague preference for the former, however? thoughts? preferences? From pmuldoon@redhat.com Wed Mar 8 16:31:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 08 Mar 2006 16:31:00 -0000 Subject: mailing list re-org In-Reply-To: <440F023A.5080905@redhat.com> References: <440F023A.5080905@redhat.com> Message-ID: <1141835440.3814.20.camel@localhost.localdomain> I have a vague, but not very strong preference, for a frysk-bugzilla list and a frysk-cvs list, and frysk discussion/patches list. This allows me to write procmail/sieve/* rules that separate the discussion from the bugzilla entries from the cvs commits by mailing list name. I fear if we track feature updates in bugzilla, and use trackers to track them, the signal to noise ratio will get too high, and I will miss important mail. My 2cs Phil On Wed, 2006-03-08 at 11:11 -0500, Andrew Cagney wrote: > At present frysk, in addition to the irc channel, has two mailing lists: > > - frysk@ for occasional discussion and announcements (most discussion > occurs on gimp.net/frysk) > - frysk-cvs@ for cvs commits > > Missing from this is a mailing list carrying the bugzilla updates and > changes, I can see two ways of integrating this information: > > - frysk@ for all development including bug information and possibly even > cvs?; frysk-announce@ for occasional announcements > > - frysk@ as is; frysk-bugzilla@ for bugzilla > > Since tracking the project involves monitoring the discussion, bugs, and > cvs changes, I've a vague preference for the former, however? > > thoughts? preferences? > From cagney@redhat.com Wed Mar 8 16:42:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Mar 2006 16:42:00 -0000 Subject: web page re-org Message-ID: <440F09B6.2090202@redhat.com> I'm looking to tweak frysk's web site with two new top level pages: - http://sources.redhat.com/frysk/build (technically part of development) already present, just hard to find - consolidate the http://sources.redhat.com/frysk/images and http://sources.redhat.com/frysk/storyboard pages into a workflow page (also the usecase page?) Good workflow is a basic principal of gui design, I think we should highlight that: as a new workflow is identified it can be added as sketches; as it is finished it can be updated to include proper screen shots. thoughts? From cagney@redhat.com Wed Mar 8 16:50:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 08 Mar 2006 16:50:00 -0000 Subject: mailing list re-org In-Reply-To: <1141835440.3814.20.camel@localhost.localdomain> References: <440F023A.5080905@redhat.com> <1141835440.3814.20.camel@localhost.localdomain> Message-ID: <440F0B84.9020102@redhat.com> Phil Muldoon wrote: >I have a vague, but not very strong preference, for a frysk-bugzilla >list and a frysk-cvs list, and frysk discussion/patches list. > >This allows me to write procmail/sieve/* rules that separate the >discussion from the bugzilla entries from the cvs commits by mailing >list name. > >I fear if we track feature updates in bugzilla, and use trackers to >track them, the signal to noise ratio will get too high, and I will miss >important mail. > > BTW, SystemTap feed all their bugs into their developer list; they get prefixed with: [Bug blah] subject ... so are not hard to identify and filter. Another option would be frysk@ and frysk-devel@, the latter carrying all the developer traffic. . From woodzltc@cn.ibm.com Thu Mar 9 01:56:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 09 Mar 2006 01:56:00 -0000 Subject: the result of "make check" on PPC64/FC5 In-Reply-To: <440EFF3B.2060509@redhat.com> References: <440EFF3B.2060509@redhat.com> Message-ID: On Wed, 8 Mar 2006, Andrew Cagney wrote: > > > packagename/O.out reports XPASS (unexpected pass). What is this check > > > for? I also notice that packagename/C.out reports PASS. So the expected > > > result is that: Class.forName ("packagename.C").getPackage() returns > > > non-null; and O.class.getPackage() returns null? What is the result on > > > x86? > > > > XFAIL roughly means, there's a bug but it's not frysk's fault. Here older > GCC's were broken - the XFAIL - gcc 4.1 however is fixed. > Since so far hasn't been bitten by that specific bug (it was bitten by > packagename/C) it failing isn't too much of a worry. Got it. Thanks. > BTW, last night I committed some more 64-bit fixage for the above, I guess > x86-64 is more sensitive. > > > > The result of "make check" in frysk-gtk directoy is: > > > > > > SKIP: gcjtreeiter/a.out > > > SKIP: gcjtreeiter/gij.sh > > > SKIP: textiter/a.out > > > ====================== > > > All 0 tests passed > > > (3 tests were not run) > > > ====================== > > > > > > > If there's no $DISPLAY, the tests are skipped. Since they play with GTK they > can't pass without an X display - now if anyone knows how to get around this, > is xvfb (x virtual frame buffer) still available somewhere? OK. I set DISPLAY to a remote xserver and get the following result: XPASS: gcjtreeiter/a.out XFAIL: gcjtreeiter/gij.sh PASS: textiter/a.out ============================================================= 1 of 3 tests did not behave as expected (1 unexpected passes) ============================================================= There is another XPASS. It seems that FC5 has one more improvement, right? Thanks - Wu Zhou From woodzltc@cn.ibm.com Thu Mar 9 02:14:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 09 Mar 2006 02:14:00 -0000 Subject: web page re-org In-Reply-To: <440F09B6.2090202@redhat.com> References: <440F09B6.2090202@redhat.com> Message-ID: On Wed, 8 Mar 2006, Andrew Cagney wrote: > I'm looking to tweak frysk's web site with two new top level pages: > > - http://sources.redhat.com/frysk/build (technically part of development) > already present, just hard to find This might be desirable. I point some people to this web site. Quite a few of them ask me again how to build frysk. :-) > - consolidate the http://sources.redhat.com/frysk/images and > http://sources.redhat.com/frysk/storyboard pages into a workflow page (also > the usecase page?) > Good workflow is a basic principal of gui design, I think we should highlight > that: as a new workflow is identified it can be added as sketches; as it is > finished it can be updated to include proper screen shots. I don't have comments on this, but have some questions instead. :-) first, how to add user-specified action to these observers? I had some looks, but don't figure out how. second, does the source view window work now? I had a try with the shipped frysk on RHEL4 U3, it don't work. Thanks - Wu Zhou From rmoseley@redhat.com Thu Mar 9 03:21:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 09 Mar 2006 03:21:00 -0000 Subject: web page re-org In-Reply-To: References: <440F09B6.2090202@redhat.com> Message-ID: <440F9F35.50108@redhat.com> Wu Zhou wrote: > On Wed, 8 Mar 2006, Andrew Cagney wrote: > >> I'm looking to tweak frysk's web site with two new top level pages: >> >> - http://sources.redhat.com/frysk/build (technically part of development) >> already present, just hard to find >> > > This might be desirable. I point some people to this web site. Quite a > few of them ask me again how to build frysk. :-) > > >> - consolidate the http://sources.redhat.com/frysk/images and >> http://sources.redhat.com/frysk/storyboard pages into a workflow page (also >> the usecase page?) >> Good workflow is a basic principal of gui design, I think we should highlight >> that: as a new workflow is identified it can be added as sketches; as it is >> finished it can be updated to include proper screen shots. >> > > I don't have comments on this, but have some questions instead. :-) > > first, how to add user-specified action to these observers? I had some > looks, but don't figure out how. > This area is currently undergoing a signifcant redesign, rework to make it more "user-friendly". You should see a great improvement in a week or so, please stay tuned. > second, does the source view window work now? I had a try with the > shipped frysk on RHEL4 U3, it don't work. > No, the source window is only in demo mode only for right now. > Thanks > - Wu Zhou > From woodzltc@cn.ibm.com Thu Mar 9 03:37:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 09 Mar 2006 03:37:00 -0000 Subject: web page re-org In-Reply-To: <440F9F35.50108@redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> Message-ID: On Wed, 8 Mar 2006, Rick Moseley wrote: > This area is currently undergoing a signifcant redesign, rework to make it > more "user-friendly". You should see a great improvement in a week or so, > please stay tuned. OK. Look forward to its settle down. > > second, does the source view window work now? I had a try with the shipped > > frysk on RHEL4 U3, it don't work. > > > No, the source window is only in demo mode only for right now. Got it. Thanks for your quick reply. Regards - Wu Zhou From pmuldoon@redhat.com Thu Mar 9 03:46:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 09 Mar 2006 03:46:00 -0000 Subject: web page re-org In-Reply-To: References: <440F09B6.2090202@redhat.com> Message-ID: <1141876002.3827.6.camel@localhost.localdomain> > first, how to add user-specified action to these observers? I had some > looks, but don't figure out how. I guess it depends on what is meant by user-specified. Do you mean, create your own custom action (Call a pager, run a script, do something else custom the user wants to do?) Or, add an already defined system action (send to time-line widget for plotting, send to a log-file and so on?) If it is the latter, that should be made much simpler soon. Sami is reworking that section due to some bugs and enhancement requests that were filed. If it is the former, then that is yet undefined. How do we run a user specified action? Do we allow them to run an executable? Run a shell script? Do some scripting? This area is very much a blank slate right now. What do you think? Do you have any opinions on this? All input is very much wanted, and appreciated! ;) Regards Phil Muldoon From woodzltc@cn.ibm.com Thu Mar 9 04:25:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 09 Mar 2006 04:25:00 -0000 Subject: web page re-org In-Reply-To: <1141876002.3827.6.camel@localhost.localdomain> References: <440F09B6.2090202@redhat.com> <1141876002.3827.6.camel@localhost.localdomain> Message-ID: On Wed, 8 Mar 2006, Phil Muldoon wrote: > > > first, how to add user-specified action to these observers? I had some > > looks, but don't figure out how. > > I guess it depends on what is meant by user-specified. Do you mean, > create your own custom action (Call a pager, run a script, do something > else custom the user wants to do?) Or, add an already defined system > action (send to time-line widget for plotting, send to a log-file and so > on?) IMHO, it will be good to support both. The former might be somewhat advanced requirement, which maybe more complex, and more resource-demanding too. The latter is basic requirement I believe. I also want to add that a debugger automatically attached as a alternative action, just as what valgrind provides. > If it is the former, then that is yet undefined. How do we run a user > specified action? Do we allow them to run an executable? Run a shell > script? Do some scripting? This area is very much a blank slate right > now. What do you think? Do you have any opinions on this? All input is > very much wanted, and appreciated! ;) OK. That is really hard to say. Maybe we can provide a normal mode action, which mainly do some restricted and carefully defined stuff. And also provide a expert or guru or experiemental mode, which can do much free action as the user like. Just my two cents anyway. Don't have much serious thought on them yet. :-) Regards - Wu Zhou From pmuldoon@redhat.com Thu Mar 9 05:31:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 09 Mar 2006 05:31:00 -0000 Subject: web page re-org In-Reply-To: References: <440F09B6.2090202@redhat.com> <1141876002.3827.6.camel@localhost.localdomain> Message-ID: <1141882275.3827.27.camel@localhost.localdomain> On Wed, 2006-03-08 at 23:26 -0500, Wu Zhou wrote: > On Wed, 8 Mar 2006, Phil Muldoon wrote: > > > > > first, how to add user-specified action to these observers? I had some > > > looks, but don't figure out how. > > > > I guess it depends on what is meant by user-specified. Do you mean, > > create your own custom action (Call a pager, run a script, do something > > else custom the user wants to do?) Or, add an already defined system > > action (send to time-line widget for plotting, send to a log-file and so > > on?) > > IMHO, it will be good to support both. The former might be somewhat > advanced requirement, which maybe more complex, and more resource-demanding > too. The latter is basic requirement I believe. I also want to add that > a debugger automatically attached as a alternative action, just as what > valgrind provides. Yep! That is the plan, to add both a stock list of "system defined" actions, and also allow the user to define what happens when an event occurs in a richer, more custom model. > > If it is the former, then that is yet undefined. How do we run a user > > specified action? Do we allow them to run an executable? Run a shell > > script? Do some scripting? This area is very much a blank slate right > > now. What do you think? Do you have any opinions on this? All input is > > very much wanted, and appreciated! ;) > > OK. That is really hard to say. Maybe we can provide a normal mode > action, which mainly do some restricted and carefully defined stuff. And > also provide a expert or guru or experiemental mode, which can do much > free action as the user like. Yes, for sure. The user defined action (As in do something via a script, executable, something else) is a tricky concept. Questions like, do we have security concerns? Should we allow further scripting (perhaps even via jython to do some further core based actions)? How do we abstract (As you well point out, from the guru mode to the basic and restricted stuff)?. These are some of the questions facing us in the six month time-frame. So input is great here, as it is still up for discussion in these areas. Any opinion or input is welcome. > Just my two cents anyway. Don't have much serious thought on them yet. > :-) Thanks for the input. I love to see it, and welcome any further thoughts on the line; post them to the list if you have anything else on the subject. Many Regards Phil From ajocksch@redhat.com Thu Mar 9 20:30:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Thu, 09 Mar 2006 20:30:00 -0000 Subject: Update Preference Model Message-ID: <4410905C.5050401@redhat.com> Ok, over the last couple weeks Sami and myself have come up with what we think is a fairly robust and extensible model for the preferences in Frysk. Types of preferences are modeled by a class (eg. IntPreference, ColorPreference), through which you can retrieve the current value, set a new value, and add a listener to be notified when the preference changes. These preferences are then organized into preference groups, which have a name and can return an iterator to all the preferences in the group. We're also planning on having subgroups at some point, so a group can have one or more subgroups beneath it. These groups are then registered with the PreferenceManager. When a group is registered with the PreferenceManager it will automatically show up in the PreferenceWindow in the left TreeView (along with it's subgroups as children), and the preferences in that group will appear in the right pane when that option is selected. When the window is closed all preferences are saved into the model and the listeners are notified of the update. Hitting cancel undoes all changes and reverts the preferences to their previous state. Let us know what you think, any feedback is always appreciated :) From ezannoni@redhat.com Thu Mar 9 20:40:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Thu, 09 Mar 2006 20:40:00 -0000 Subject: web page re-org In-Reply-To: <440F9F35.50108@redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> Message-ID: <17424.37517.261426.122399@localhost.redhat.com> Rick Moseley writes: > This area is currently undergoing a signifcant redesign, rework to make > it more "user-friendly". You should see a great improvement in a week > or so, please stay tuned. Rick, let's post our plans to this list, pls. From rmoseley@redhat.com Thu Mar 9 21:11:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 09 Mar 2006 21:11:00 -0000 Subject: web page re-org In-Reply-To: <17424.37517.261426.122399@localhost.redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> <17424.37517.261426.122399@localhost.redhat.com> Message-ID: <441099F4.4020602@redhat.com> Elena Zannoni wrote: > Rick Moseley writes: > > This area is currently undergoing a signifcant redesign, rework to make > > it more "user-friendly". You should see a great improvement in a week > > or so, please stay tuned. > > Rick, let's post our plans to this list, pls. > Hmmm, well, these "plans" came about because of some bz's I filed and a meeting between Mike Behm and Sami. I had made several enhancement requests via bz and Mike pinged me about some more changes that he recommended. I then suggested that he and Sami get together so Mike could see first-hand the operation and could show Sami exactly what he recommended. Sami has already begun implementing those and you can see the beginnings of those from the frysk cvs head. On the initial frysk window, click on "Observers->Custom Observers(new)" item. Not sure if anything was ever really formalized here, they were just some recommendations on how to improve the workflow to make it more intuitive. Please feel free to comment on this new window that comes up. Be advised though, that it is not fully operational yet. From pmuldoon@redhat.com Thu Mar 9 21:20:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 09 Mar 2006 21:20:00 -0000 Subject: web page re-org In-Reply-To: <17424.37517.261426.122399@localhost.redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> <17424.37517.261426.122399@localhost.redhat.com> Message-ID: <1141939172.2559.5.camel@dhcp-12.hsv.redhat.com> When writing up the demo script, Rick tested (quite thoroughly) the custom observer stuff. So the plans are bz's in the sources bugzilla that consist of pr's and enh requests against sami and myself. So it's workflow tweaks and bug fixes. Here are the bz numbers for anyone interested: 2407, 2405, 2399, 2398, 2397, 2395, 2394, 2393 Regards Phil On Thu, 2006-03-09 at 15:39 -0500, Elena Zannoni wrote: > Rick Moseley writes: > > This area is currently undergoing a signifcant redesign, rework to make > > it more "user-friendly". You should see a great improvement in a week > > or so, please stay tuned. > > Rick, let's post our plans to this list, pls. -- From pmuldoon@redhat.com Thu Mar 9 21:22:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 09 Mar 2006 21:22:00 -0000 Subject: web page re-org In-Reply-To: <1141939172.2559.5.camel@dhcp-12.hsv.redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> <17424.37517.261426.122399@localhost.redhat.com> <1141939172.2559.5.camel@dhcp-12.hsv.redhat.com> Message-ID: <1141939367.2559.7.camel@dhcp-12.hsv.redhat.com> On Thu, 2006-03-09 at 15:19 -0600, Phil Muldoon wrote: > When writing up the demo script, Rick tested (quite thoroughly) the > custom observer stuff. So the plans are bz's in the sources bugzilla > that consist of pr's and enh requests against sami and myself. > > So it's workflow tweaks and bug fixes. Here are the bz numbers for > anyone interested: 2407, 2405, 2399, 2398, 2397, 2395, 2394, 2393 > > > > Rick, let's post our plans to this list, pls. On that note, I can pull together a summary of the pr's involved and send them to the list with an overview of what we are doing/trying to achieve. Will be no problem to do so. Regards Phil -- From woodzltc@cn.ibm.com Fri Mar 10 09:48:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 10 Mar 2006 09:48:00 -0000 Subject: the results of TestRunner on PPC64/FC5 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2006, Wu Zhou wrote: > In directory frysk-core, there are four case failures: > > frysk.proc.TestI386Modify, > frysk.proc.TestI386Regs, > frysk.proc.TestSyscallOpen and > frysk.proc.TestSyscallInterrupt > > [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallInterrupt > Running testSyscallInterrupt(frysk.proc.TestSyscallInterrupt) ...ptrace: Input/output error > [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallOpen > Running testSyscallOpen(frysk.proc.TestSyscallOpen) ...ptrace: Input/output error > [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Modify > Running testI386Modify(frysk.proc.TestI386Modify) ...ptrace: Input/output error > [root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Regs > Running testI386Regs(frysk.proc.TestI386Regs) ...ptrace: Input/output error > > Didn't look into these failure yet. Just post the problems here for > recording. If anyone could give me any hints, that will be much appreciated! > :-) I made a little analysis on these failure. And find these EIO error of ptrace come from the fact that member function sendrecIsa of LinuxTask is hard-coded to call LinuxIa32.isaSingleton (). So maybe we need to change this? First, sendrecIsa need to be dependent on the target ISA. This can be ia32, x86-64, ppc64, or some others maybe. Second, we need to add a class named LinuxPPC64 to extend Isa to support PPC64 (maybe a class named LinuxX86-64 is also needed. I am not very sure though). But I have a few question here: A. what is the bank intended to represent in class Register? I see that all the registers in LinuxIa32 set its bank to 0. B. class Isa seems to be not completed yet. So what is it intended to cover? ISA dependent features? or even include OS specific stuff? I see there is a segment of comment, saying: /** * Instruction Set Architecture. * * XXX: This ISA object needs to be re-organized; perhaphs an OsIsa * object with nested members for the ISA, the OS, et.al. */ So Frysk is also intended to support other OS? I had thought that it is only for Linux. And what is label "XXX" intended to represent? In my knowledge, that place is usually occupied by the author name. :-) BTW. I also see XXX is used in many other places, such as host.requestRefreshXXX, host.observableProcRemovedXXX.addObserver, and so on... Any intention on that? Regards - Wu Zhou P.S: I ask a lot of questions in one mail. Forgive me if it overwhelms. I am curious indeed. :-) From rmoseley@redhat.com Fri Mar 10 15:54:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Fri, 10 Mar 2006 15:54:00 -0000 Subject: Update Preference Model Message-ID: <4411A140.2080909@redhat.com> Jonathan's response did not make it to the list for some reason. Here it is: (Since you asked for feedback...) I'm not a fan of this at all! Autogenerated and automatic preferences are a pretty classic user-interface mistake, though a common one. It leads to an incoherent dialog, a bad set of preferences, and poorly thought out dialogs. It interacts badly when you have conflicting preferences, doesn't give you a way to give good feedback, and invariably grows complicated beyond bool/int as you hit special cases. It's occasionally okay to do if you have a complicated plug-in system, and patient users, but if you can at all avoid it, please do so! It's not too hard to mock out the preferences in glade and hook them up -- especially if you're going for such a simple commit model. It also forces you to think about which preferences are important to include, and which ones aren't needed, or could be done in a better way. Rather than write a system to handle preferences, it's better to figure out what those preferences should be, and try to do a reasonable effort based on that. Thanks, -Jonathan From ajocksch@redhat.com Fri Mar 10 16:22:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Fri, 10 Mar 2006 16:22:00 -0000 Subject: Update Preference Model In-Reply-To: <4411A140.2080909@redhat.com> References: <4411A140.2080909@redhat.com> Message-ID: <4411A7DB.2020500@redhat.com> Thanks, this is exactly the kind of guidance we were looking for :) Your points about auto-generated GUIs are well taken, and I will admit that the auto-generated window as it stands now is not one of the more clearer dialogs I've ever seen. When we were originally putting preferences into frysk, we followed exactly the model you'd suggested: Hardcoded glade dialog, and the just grab the preferences by name when we needed them in the code. What I found after a while is that it quickly became unmaintainable and changing things relating to the preferences became more complicated with every preference added. The aim of this new model was to bypass that complication and make it easier to make changes, but as you've correctly pointed out we've paid the price for it in usability. I like the way the new preference model works internally and attaching a hardcoded window to that shouldn't be too difficult. There will still be some maintenance issues but hopefully we can find a pretty (aesthetically and implementation-wise) solution to this. > (Since you asked for feedback...) > > I'm not a fan of this at all! Autogenerated and automatic preferences > are a pretty classic user-interface mistake, though a common one. It > leads to an incoherent dialog, a bad set of preferences, and poorly > thought out dialogs. It interacts badly when you have conflicting > preferences, doesn't give you a way to give good feedback, and > invariably grows complicated beyond bool/int as you hit special cases. > It's occasionally okay to do if you have a complicated plug-in system, > and patient users, but if you can at all avoid it, please do so! > > It's not too hard to mock out the preferences in glade and hook them up > -- especially if you're going for such a simple commit model. It also > forces you to think about which preferences are important to include, > and which ones aren't needed, or could be done in a better way. > > Rather than write a system to handle preferences, it's better to figure > out what those preferences should be, and try to do a reasonable effort > based on that. > > Thanks, > -Jonathan > From swagiaal@redhat.com Fri Mar 10 18:19:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 10 Mar 2006 18:19:00 -0000 Subject: web page re-org In-Reply-To: <17424.37517.261426.122399@localhost.redhat.com> References: <440F09B6.2090202@redhat.com> <440F9F35.50108@redhat.com> <17424.37517.261426.122399@localhost.redhat.com> Message-ID: <4411C328.2040105@redhat.com> > Rick, let's post our plans to this list, pls. > Here are some screen shots from the new custom observer work flow The last image is a screen shot of the old Custom Observers Dialog which will soon be removed. As shown here filters and actions have not been incorporated into the new dialog yet. But there will be widgets there that will allow you to add filters and actions to observers. I will send screenshots when that is ready. -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot22.png Type: image/png Size: 32207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot23.png Type: image/png Size: 30079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot24.png Type: image/png Size: 15833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot25.png Type: image/png Size: 21331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot26.png Type: image/png Size: 56274 bytes Desc: not available URL: From cagney@redhat.com Fri Mar 10 22:33:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 10 Mar 2006 22:33:00 -0000 Subject: web page re-org In-Reply-To: <440F09B6.2090202@redhat.com> References: <440F09B6.2090202@redhat.com> Message-ID: <4411FEFC.7090307@redhat.com> based on the comments ... Andrew Cagney wrote: > I'm looking to tweak frysk's web site with two new top level pages: > > - http://sources.redhat.com/frysk/build (technically part of development) > already present, just hard to find I've added this. > - consolidate the http://sources.redhat.com/frysk/images and > http://sources.redhat.com/frysk/storyboard pages into a workflow page > (also the usecase page?) > Good workflow is a basic principal of gui design, I think we should > highlight that: as a new workflow is identified it can be added as > sketches; as it is finished it can be updated to include proper screen > shots. > I've created a http://sources.redhat.com/frysk/workflow/ directory ready for integration - just need those sketches and the like uploaded. The directory is visible by checking out usng cvs vis: cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/frysk co htdocs I think sub pages for each work flow would make sense. Andrew From cagney@redhat.com Tue Mar 14 14:50:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 14 Mar 2006 14:50:00 -0000 Subject: the results of TestRunner on PPC64/FC5 In-Reply-To: References: Message-ID: <4416D88D.1080103@redhat.com> Sorry to not reply immediatly; Wu Zhou wrote: >On Wed, 8 Mar 2006, Wu Zhou wrote: > > >>In directory frysk-core, there are four case failures: >> >>frysk.proc.TestI386Modify, >>frysk.proc.TestI386Regs, >>frysk.proc.TestSyscallOpen and >>frysk.proc.TestSyscallInterrupt >> >>[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallInterrupt >>Running testSyscallInterrupt(frysk.proc.TestSyscallInterrupt) ...ptrace: Input/output error >>[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallOpen >>Running testSyscallOpen(frysk.proc.TestSyscallOpen) ...ptrace: Input/output error >>[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Modify >>Running testI386Modify(frysk.proc.TestI386Modify) ...ptrace: Input/output error >>[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Regs >>Running testI386Regs(frysk.proc.TestI386Regs) ...ptrace: Input/output error >> >>Didn't look into these failure yet. Just post the problems here for >>recording. If anyone could give me any hints, that will be much appreciated! >>:-) >> >> > >I made a little analysis on these failure. And find these EIO error of >ptrace come from the fact that member function sendrecIsa of LinuxTask is >hard-coded to call LinuxIa32.isaSingleton (). So maybe we need to change >this? > > > Looking locally, the ptrace barf is easy to fix (it should throw an exception :-), however, yes, the isa issue is more complex. >First, sendrecIsa need to be dependent on the target ISA. This can be >ia32, x86-64, ppc64, or some others maybe. > > > Yes. The information needs to come from the kernel's process tables. Unfortunatly there is currently no such interface - http://sourceware.org/bugzilla/show_bug.cgi?id=2458 . Fortunatly, there's a work-around. It is possible, using heuristics, to get the information from /proc//auxv, take a look at frysk/sys/proc/Aux* >Second, we need to add a class named LinuxPPC64 to extend Isa to support >PPC64 (maybe a class named LinuxX86-64 is also needed. I am not very sure >though). But I have a few question here: > > > Yes. Presumably each ISA would register itself with LinuxHost so that sendrecIsa, given a process and its auxv, would be able to find and return the correct ISA. >A. what is the bank intended to represent in class Register? I see that >all the registers in LinuxIa32 set its bank to 0. > > > For the ia32, there should be at least three banks (I'd better check what was actually implemented): - integer registers - floating point registers - sse registers A bank is a ByteArray containing the raw register information. How many banks there are, and their structure, are entirely ISA/OS/ABI dependant - determined for instance by the layout returned by PT_GETREGS, or /proc//tasks//regs. The second ISA specific areas are the system call, and signal descriptions. At present they are very hard wired, I think they should be drawn from tables. The current code is a prototype. >B. class Isa seems to be not completed yet. So what is it intended to >cover? ISA dependent features? or even include OS specific stuff? I see >there is a segment of comment, saying: > >/** > * Instruction Set Architecture. > * > * XXX: This ISA object needs to be re-organized; perhaphs an OsIsa > * object with nested members for the ISA, the OS, et.al. > */ > >So Frysk is also intended to support other OS? I had thought that it is >only for Linux. > > > frysk is being developed on GNU/Linux, yes; in the future, who knows. Even within Linux, there are warts - while upstream settles downstream can find itself with local variation that bubbles into these interfaces. A local system call, for instance. Consider the system >And what is label "XXX" intended to represent? In my knowledge, that >place is usually occupied by the author name. :-) > > > Very old convention. It is acting as a marker for stuff that is broken or missing or needs work. >BTW. I also see XXX is used in many other places, such as >host.requestRefreshXXX, host.observableProcRemovedXXX.addObserver, and >so on... Any intention on that? > > > Don't use it :-) >Regards >- Wu Zhou > >P.S: I ask a lot of questions in one mail. Forgive me if it overwhelms. >I am curious indeed. :-) > > From cmoller@redhat.com Tue Mar 14 16:19:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 14 Mar 2006 16:19:00 -0000 Subject: VTE Message-ID: <4416ECF8.8050902@redhat.com> For those of you following the continuing saga of vte under frysk, it turns out there was already a patch that appears to do what frysk needs. The patch may need a couple of minor tweeks before it's ready for prime-time, but it seems to work. Thanks to Behdad Esfahbod for pointing out the patch. Chris Moller -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Tue Mar 14 20:01:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 14 Mar 2006 20:01:00 -0000 Subject: vte patch Message-ID: <4417211B.2060409@redhat.com> Attached is a patch against vte-0.11.11 that adds vte_terminal_set_pty(). It's based on the patch included in GNOME bug #135230 "Feature request to attach VTE to existing pty" and incorporates Nalin Dahyabhai suggestions. Chris Moller -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vte-0.11.11-set-pty.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Tue Mar 14 20:24:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 14 Mar 2006 20:24:00 -0000 Subject: vte patch In-Reply-To: <4417211B.2060409@redhat.com> References: <4417211B.2060409@redhat.com> Message-ID: <44172679.6000807@redhat.com> Oops, ignore the first patch--I screwed it up. Here's a working one: Chris Moller mumbled something on 03/14/2006 03:01 PM: > Attached is a patch against vte-0.11.11 that adds > vte_terminal_set_pty(). It's based on the patch included in GNOME bug > #135230 "Feature request to attach VTE to existing pty" and incorporates > Nalin Dahyabhai suggestions. > > Chris Moller > > > ------------------------------------------------------------------------ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vte-0.11.11-set-pty.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From pmuldoon@redhat.com Tue Mar 14 23:19:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 14 Mar 2006 23:19:00 -0000 Subject: GUI Review Notes Message-ID: <1142378322.2635.20.camel@dhcp-12.hsv.redhat.com> These are my notes from a meeting in Boston office on the current state of the Frysk-GUI and where we can change, add or move forward. --- The meetings were held in Boston on the afternoon of February 13th and the morning of Tuesday February 14th. Attendees: >From the Frysk Project Group: Phil Muldoon Rick Moseley Sami Wagiaalla Adam Jocksch Elena Zannoni Desktop Team: Jonathan Blandford Seth Nickell Bryan Clark Monday Afternoon The meetings primarily looked at the flow and make-up of the monitor based tools, and the application of "tag-sets", and enhancement to "printf" style debugging. >From very early on, it became apparent that the current monitor had several different work-flows. Some complimentary and some opposing. There were multiple ways to achieve the same level of functionality. There was confusion regarding the difference of what applying an observer to a Thread was, opposed to a Process. Also there was no real easy way to identify what the main task in a process was. Generally, for the rest of the afternoon we focused on user-targeted design. What is it? What do we need to think about? User roles? The desktop team mentored us through this process, and gave some good advice. For my part, I found this very valuable, and think that other teams would find it equally as valuable. The team went over several possible work-flows, and eventually focused on what we thought was the most useful. Seth and Bryan lead the discussion, and helped us draw out the scenarios. These notes primarily concentrate on the monitoring aspect of the meetings. Rick and Adam should have some deeper notes on the creation of tag-sets. The Treeview. The process tree-view in the Frysk monitor is sorted very similarly to the presentation of several top down process tools. Tools like top and ps (and others) render a process hierarchy in a PPID to PID model. This is convenient to the system, as it forms an internal representation of the process model, and that is how it is stored on the system itself. But was it necessarily useful from a user perspective? In this view, there were pages and pages of processes that were irrelevant to the user, and just got in the way. We discussed user-roles at this point, and how we could build a tree-view that was more useful to the type of person currently using it. For example would a web-developer have any interest at all in kjournal, or ksyslogd .. or init, or mapping-daemon? The tree-view should be providing the information best suited to the user, at the point in time the information is needed, in an uncluttered format. It was noted that a tree-view then should be based off a session that is created in Frysk for the user type. Sessions I might have the terminology wrong with "sessions" as it is used here. Anyway, it seemed like the best way to describe it. Following on from the tree-view discussion, the question arose: "How do we know what the user wants from Frysk, and how can we provide the best information for that user?" As Frysk has a very wide audience type, the breadth of potential users really requires us to define the roles upfront. We looked at how to organize our work-flows, and decided to render the initial Frysk setup as a druid. The Druid would have several functions: 1) To save sessions; 2) To guide the user through setting-up a session that would render Frysk more useful for that user; 3) Would allow the user to jump straight to source level debugging; 4) Would start up a previously defined session. That attachment frysk_gui_new.png shows the initial screen. This is a mock-up from those sessions that Johnathan and then Sami worked on. The debug session will change over the next several months. Initially after new-session is clicked, the user would be taken to a selection of tag-sets that were stored on the system. However as source-level debugging is not quite there yet, the tag-sets will be implemented later. The next screen, therefore, deals with the behavior of the monitoring aspects of the UI. A mock-up is shown in the attachment: frysk_gui_new2.png This screen-shot is where the user defines what is important to her. What aspects of the process model does the user wish to watch? Processes are grouped in a flat system. Process names are first. PID is second. If the executable has more than one instantiation (IE multiple httpds) they are grouped as one. The tree will be sortable, and filterable to make selection easier. There are standard add-to and remove-from buttons. The screen is focused on one task, and that is to ask the user "What interests you in this system?" Therefore in this new debug work-flow, the user selects what processes are important to her upfront and in the beginning. Questions: If the user wants to change the profile/session how do they? (IE no longer interested in httpd for foobar, but everything else about the profile should remain the same) Where do we manage profiles? Delete, copy .. export? When the user has selected the useful processes, there are three questions: 1) What tag-sets do you want to apply on a per-process level? 2) Which of these processes do you want alarms on if it dies? 3) What other observers do you want to apply to these processes? To answer question two, the next screen would show a selection of the processes selected by the user (using the same grouping), and allow the user to select which of these processes are important to flag/perform an action, if that process exits. There are two exit scenarios, normal and abnormal. While normal might be defined as a process just exiting on completion, it might be undesired behavior on part of the user (IE httpd exiting at 3am. Why?) Abnormal can be defined as the abrupt and uncontrolled exit of a process (IE sigsegv). Questions: How do we define the action taken? Should it be one global action defined for all processes, or allow the user to define different actions on different processes? Once the user has defined what "Process exit" behavior is, the next screen should deal with adding initial observers. What observers do you wish to add to these processes when Frysk starts this session? Customer Observers In the old Frysk model, custom observers were defined in Frysk itself. They were a menu option of the main-menu tool-bar. However there is nothing in that work-flow that has a dependency on applying the observer itself. They are two distinct - but related - actions. We looked at re-factoring the custom observer dialog out of the druid and just including it as a stand-alone tool (runnable at anytime) from the Frysk stay-resident icon. This will make it is available at anytime. Apply observers After the user has defined the processes that are of interest if they die during that Frysk session, we allow the user to define what initial observers to add when that session is started. This is done via the same selection dialog, showing processes of interest. The right-click selection menu should list all observers that Frysk knows about, custom and system provided (system provided observers come with standard actions). End of Session Once all the Druid steps above are complete, the last screen should allow the user to name and save the session (maybe we should name it as a first step?). This session will then get added to the session-manager seen in the first attached screen-shot. On Finish, the session should also be "run" by Frysk, and the Druid should be closed. Frysk - Running a Session When Frysk runs a session, the tree-view shall be represented as the "interesting process" widget shown in the screen-shots. The old top down ps model will be replaced by this. We should include an option to open- up the filter via a button that optionally shows all other processes below the interesting processes in the tree-view. This should default to off. All operations in Frysk should be implemented in this widget. The user will be allowed to add further observers to threads/processes as they can now (Frysk will already have added those initial observers that were defined in the session druid). Custom observers as described above will be moved to the Frysk Taskbar icon and will be available to be created at any time. Tag-Sets Tag-sets will be created in the source-window, and will be exported from the source window. Tag-sets are a collection of tags that the user defines in a source-window. They are, in essence, a special kind of break-point. All of these tag breakpoints are collated in a process- version specific file, and applied (in the session-druid) to a process via Frysk breakpoints. There was talk of shipping tag-sets in the future as part of an RPMs payload. That would have to be a maintainer level task. I don't foresee this level of adoption for awhile. What is a Tag? A tag is a break-point that when hit will print out a user-specified message, and also store a stack-trace. This stack-trace buffer should be limited and should be circular. Tags are inserted in the source-window using the same work-flow as "apply a break-point". The original source will not need to recompiled. There will be a GUI middle-manager that will read the exported tag-file and apply via Frysk all the breakpoints associated with that set. When the observer break-point notifies the manager that a break-point has been reached, it would check to see if it was a tag, and if so, fire the appropriate action on that tag. Viewing Tag Hits. When tags are hit, they will be stored in a process-session specific file. This file is circular and is size limited. A time-execution based widget will plot when a tag is hit, over the the time it was hit. (IE tagFoo hit at 3.12am). Mouse Hovering over this plot will show the user-defined message to a tool-tip. Double click will bring up a dialog showing the back trace at that point in time. The widget should be able to zoom, scroll, and plot a defined number of tags at a given magnification level. See the white-board screen-shots for more details. Tuesday Morning Tuesday morning we went over again the concepts we discussed on Monday afternoon, and revisited the above scenarios to see how they looked after some thought. Later we looked at general good UI concepts, and good glade design. Johnathan led us through the initial GLADE steps, illustrating the many different gotchas and HIG concepts. We discussed work-flow again, and how many UI's follow similar design patterns. (Gnome Human Interface Guidelines) http://developer.gnome.org/projects/gup/hig/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_druid_new.png Type: image/png Size: 15107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_druid_new2.png Type: image/png Size: 23187 bytes Desc: not available URL: From swagiaal@redhat.com Wed Mar 15 18:12:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 15 Mar 2006 18:12:00 -0000 Subject: GUADEC proposal Message-ID: <44185912.1020005@redhat.com> Strange this email didnt make it to the list last night: I have look at the GUADEC proposal submission procedure. It is very hip and very open, I like it very much. You basically fill in the form which, creates a page that people can view, and comment on. You can edit that at any time. Here is what I would like to submit- any comments ?- : _*Title*_ Frysk: a Modern Debugger and Execution Analysis Tool _*Track*_ The *Topaz* track will contain visions, guesses, plans, alpha developments and anything related to the future. The *Catwalk* track will contain showcases, presentations, demonstrations - anything related to the present. The *Tangle* track will tackle tricky issues, controversial problems, and long-standing cross-discipline knots that need a broad effort. Which one does frysk fit in ? _*Point of View*_ *The Developer*. "Sessions about... development :), languages, platforms, libraries, standards, bugs and the GNOME project workflow. Closure and social event at the end, with a possibility of a KDE-GNOME rematch, this time on basketball." _*Type of Session:*_ 15' Presentation ? _*Summary*_ Frysk is a new object oriented debugger and execution analysis tool written in Java using the Java-GNOME bindings. The goal of Frysk is to solve usability, and functionality problems with traditional debuggers, making it possible to debug and analyze large scale multi threaded applications. _*Full Description*_ (I feel this section is a bit lacking... what more should i put here ?) Frysk is an execution analysis tool. The Frysk core creates and maintains an event driven, interactive Domain Object Model of the operating environment and its composing elements, such as hosts, processes and threads. The model allows clients to observe, analyze and manipulate processes and threads in that system. This is utilized to enable developers and system administrators to solve higher level problems such as monitoring the execution of a system, monitoring the use of locking primitives, exposing deadlocks, gathering data, and debugging a given process. Frysk is also intended as an always-on monitoring tool which allows the user to set up nets to catch certain problems and get a chance to analyze them as soon as they occurs and as the process is still alive. The Frysk GUI is designed to provides users with high level view hiding away noisy intricate details until they are requested. This high level overview in combination with correct and live modeling of a problem is what programmers seek when they choose the use of print statements and avoid traditional debuggers. Sami Wagiaalla From cagney@redhat.com Wed Mar 15 19:37:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 15 Mar 2006 19:37:00 -0000 Subject: GUADEC proposal In-Reply-To: <44185912.1020005@redhat.com> References: <44185912.1020005@redhat.com> Message-ID: <44186D4E.8060401@redhat.com> Sami Wagiaalla wrote: > Strange this email didnt make it to the list last night: > > I have look at the GUADEC proposal submission procedure. > It is very hip and very open, I like it very much. > > You basically fill in the form which, creates a page that people > can view, and comment on. You can edit that at any time. > > Here is what I would like to submit- any comments ?- : > > _*Title*_ > > Frysk: a Modern Debugger and Execution Analysis Tool > <> comes with a lot of baggage leading to wrong expectations. Terms like non-tradition, which you use near the end, may be better; and Execution analysis should, perhaphs, be mentioned first. Other phrases are: <>, <<..., eliminating the need for traditional debugging>>, ... > _*Track*_ > > The *Topaz* track will contain visions, guesses, plans, alpha > developments and anything related to the future. somewhere between this, > The *Catwalk* track will contain showcases, presentations, > demonstrations - anything related to the present. and this. > The *Tangle* track will tackle tricky issues, controversial > problems, and long-standing cross-discipline knots that need a broad > effort. From a GNOME view point, I don't think this so controversial. > > Which one does frysk fit in ? > > _*Point of View*_ > > *The Developer*. > "Sessions about... development :), languages, platforms, libraries, > standards, bugs and the GNOME project workflow. Closure and social > event at the end, with a possibility of a KDE-GNOME rematch, this > time on basketball." > > _*Type of Session:*_ > > 15' Presentation ? > > _*Summary*_ > > Frysk is a new object oriented debugger and execution analysis tool > written in Java using the Java-GNOME bindings. The goal of Frysk is > to solve usability, and functionality problems with traditional > debuggers, making it possible to debug and analyze large scale multi > threaded applications. > > _*Full Description*_ (I feel this section is a bit lacking... what > more should i put here ?) > > Frysk is an execution analysis tool. The Frysk core creates and > maintains an event driven, interactive Domain Object Model of the > operating environment and its composing elements, such as hosts, > processes and threads. The model allows clients to observe, analyze > and manipulate processes and threads in that system. This is > utilized to enable developers and system administrators to solve > higher level problems such as monitoring the execution of a system, > monitoring the use of locking primitives, exposing deadlocks, > gathering data, and debugging a given process. Frysk is also > intended as an always-on monitoring tool which allows the user to > set up nets to catch certain problems and get a chance to analyze > them as soon as they occurs and as the process is still alive. > > The Frysk GUI is designed to provides users with high level view > hiding away noisy intricate details until they are requested. This > high level overview in combination with correct and live modeling of > a problem is what programmers seek when they choose the use of print > statements and avoid traditional debuggers. > > > Sami Wagiaalla > From swagiaal@redhat.com Thu Mar 16 15:53:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 16 Mar 2006 15:53:00 -0000 Subject: GUADEC proposal In-Reply-To: <44185912.1020005@redhat.com> References: <44185912.1020005@redhat.com> Message-ID: <441989FF.5040202@redhat.com> Okay here is take two of the proposal after much appreacicated feedback from Andrew and Michael Behm. _*Title*_ Frysk: an Execution Analysis Tool _*Track*_ ??The *Topaz* track will contain visions, guesses, plans, alpha developments and anything related to the future.?? I think the Topaz is a better fit for us :). _*Point of View*_ *??The Developer*. Sessions about... development :), languages, platforms, libraries, standards, bugs and the GNOME project workflow. Closure and social event at the end, with a possibility of a KDE-GNOME rematch, this time on basketball.?? _*Type of Session:*_ 15' presetation. _*Summary*_ Frysk is a new object oriented execution analysis tool written in Java using the Java-GNOME bindings. The goal of Frysk is to solve usability, and functionality problems with traditional debugging, making it possible to debug and analyze large scale multi threaded applications. _*Full Description*_ Frysk is an execution analysis tool. The Frysk core creates and maintains an event-driven, interactive Domain Object Model of the operating environment and its composing elements. These elements include hosts, processes and threads, and language models for those processes and threads. The model allows clients of that API to observe, analyze, and manipulate its elements. Frysk uses this model to enable developers and system administrators to solve higher-level problems such as monitoring the execution of a system, monitoring the use of locking primitives, exposing deadlocks, gathering data, debugging multi threaded applications, and even catching problems that might involve more than one process. Frysk is also intended as an always-on monitoring tool that allows the user to set up observers to catch certain problems and get a chance to analyze them as soon as they occurs ??while the process is still alive. The Frysk GUI is designed to provide users with high level view, hiding away noisy, intricate details until they are requested. This high level overview, in combination with correct and live modeling of a problem, is what programmers seek when they choose the use of print statements and avoid traditional debuggers. From pmuldoon@redhat.com Thu Mar 16 16:18:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 16 Mar 2006 16:18:00 -0000 Subject: GUADEC proposal In-Reply-To: <441989FF.5040202@redhat.com> References: <44185912.1020005@redhat.com> <441989FF.5040202@redhat.com> Message-ID: <1142525858.2547.3.camel@dhcp-12.hsv.redhat.com> Still reading and thinking, but here are two comments that come immediately to mind. > _*Summary*_ > > Frysk is a new object oriented execution analysis tool written in Java > using the Java-GNOME bindings. The goal of Frysk is to solve usability, > and functionality problems with traditional debugging, making it > possible to debug and analyze large scale multi threaded applications. Any chance of mentioning it being natively compiled in the Summary? > _*Full Description*_ > > Frysk is an execution analysis tool. The Frysk core creates and > maintains an event-driven, interactive Domain Object Model of the > operating environment and its composing elements. These elements include > hosts, processes and threads, and language models for those processes > and threads. The model allows clients of that API to observe, analyze, > and manipulate its elements. > > Frysk uses this model to enable developers and system administrators to > solve higher-level problems such as monitoring the execution of a > system, monitoring the use of locking primitives, exposing deadlocks, > gathering data, debugging multi threaded applications, and even catching > problems that might involve more than one process. > > Frysk is also intended as an always-on monitoring tool that allows the > user to set up observers to catch certain problems and get a chance to > analyze them as soon as they occurs ???while the process is still alive. I'd put the paragraph below directly after the Core paragraph and not the last. It would demonstrate the two-tier module, and might be more context sensitive to the GUADEC crowd. > The Frysk GUI is designed to provide users with high level view, hiding > away noisy, intricate details until they are requested. This high level > overview, in combination with correct and live modeling of > a problem, is what programmers seek when they choose the use of print > statements and avoid traditional debuggers. -- From naoya.maruyama@gmail.com Fri Mar 17 07:19:00 2006 From: naoya.maruyama@gmail.com (Naoya Maruyama) Date: Fri, 17 Mar 2006 07:19:00 -0000 Subject: general questions on Frysk Message-ID: Hello, I'm new to Frysk, and am wondering how it works. I've read the Frysk web site, but yet - How does Frysk obtain events from other processes? What does the interface look like? Is it the same as the traditional debugger using ptrace? - How does Frysk monitor distributed systems? - How much would the overhead be? - Are there any documents describing the internals of Frysk? Any help would be appreciated. Naoya From cagney@redhat.com Fri Mar 17 18:43:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 17 Mar 2006 18:43:00 -0000 Subject: general questions on Frysk In-Reply-To: References: Message-ID: <441B03A4.2060902@redhat.com> Naoya Maruyama wrote: >Hello, > >I'm new to Frysk, and am wondering how it works. I've read the Frysk >web site, but yet > > > Naoya, good questions, >- How does Frysk obtain events from other processes? What does the >interface look like? Is it the same as the traditional debugger using >ptrace? > > At present frysk is using the kernel ptrace to obtain the event information; really, though, it isn't sufficent. Some kernel people are also looking at providing a more modern interface and when ever that becomes available we'll be all over it :-) >- How does Frysk monitor distributed systems? > > That's unfortunatly a work not really in progress - development is immediatly focused on getting the local native case working. Frysk's core architecture, however, is designed to allow distribution, see: http://sourceware.org/frysk/javadoc/public/frysk/model/doc-files/arch-distrib.jpg for a high level diagram. It has been suggested that a prototype can be quickly brought up using Java's distributed object framework. >- How much would the overhead be? > > We'll need to find out, and explore the options. The important thing is that the communication does not need to be low level level, but instead communicatioin can occure at a higher-level and involve less frequent exchanges exchanges. For instance, limited to just specific events. >- Are there any documents describing the internals of Frysk? > The page: http://sourceware.org/frysk/javadoc/public/ gives a very high level overview. Bbeyond that when it comes to more specific details the best thing is to ask either on this mailing list, or the irc:gimp.net/frysk channel. A good, but very very low level, way to see the core in action is to run its JUnit tests with logging enabled (/usr/libexec/frysk/funit -l FINE or cd frysk-core && ./TestRunner -l FINE). A file in ~/.frysk/logs will be created containing a log all the object|event interactions; for instance: {frysk.proc.LinuxTask@445370,id={TaskId,13106},state=attaching} receiveStoppedEvent {frysk.proc.LinuxTask@445370,id={TaskId,13106},state=attaching} processStoppedEvent {frysk.proc.LinuxProc@49bdc0,id={ProcId,13106},state=Attaching.ToMainTask} performTaskAttachCompleted is a very small part of the event sequence that occures when frysk is attaching to the Task (Linux LW) 13106. The corresponding code is in frysk-core/frysk/proc/TaskState.java. The details of the state machine pattern, on which that code is based, is found in the <> patterns book. >Any help would be appreciated. > > Andrew From naoya.maruyama@gmail.com Mon Mar 20 05:22:00 2006 From: naoya.maruyama@gmail.com (Naoya Maruyama) Date: Mon, 20 Mar 2006 05:22:00 -0000 Subject: general questions on Frysk In-Reply-To: <441B03A4.2060902@redhat.com> References: <441B03A4.2060902@redhat.com> Message-ID: Hello, Thank you for the reply. I'm especially interested in how Frysk will be extended to monitoring of distributed systems. I'll come to this project later. Naoya On 3/18/06, Andrew Cagney wrote: > Naoya Maruyama wrote: > > >Hello, > > > >I'm new to Frysk, and am wondering how it works. I've read the Frysk > >web site, but yet > > > > > > > Naoya, good questions, > > >- How does Frysk obtain events from other processes? What does the > >interface look like? Is it the same as the traditional debugger using > >ptrace? > > > > > At present frysk is using the kernel ptrace to obtain the event > information; really, though, it isn't sufficent. Some kernel people are > also looking at providing a more modern interface and when ever that > becomes available we'll be all over it :-) > > >- How does Frysk monitor distributed systems? > > > > > That's unfortunatly a work not really in progress - development is > immediatly focused on getting the local native case working. Frysk's > core architecture, however, is designed to allow distribution, see: > http://sourceware.org/frysk/javadoc/public/frysk/model/doc-files/arch-distrib.jpg > for a high level diagram. It has been suggested that a prototype can be > quickly brought up using Java's distributed object framework. > > >- How much would the overhead be? > > > > > We'll need to find out, and explore the options. The important thing is > that the communication does not need to be low level level, but instead > communicatioin can occure at a higher-level and involve less frequent > exchanges exchanges. For instance, limited to just specific events. > > >- Are there any documents describing the internals of Frysk? > > > The page: > > http://sourceware.org/frysk/javadoc/public/ > > gives a very high level overview. Bbeyond that when it comes to more > specific details the best thing is to ask either on this mailing list, > or the irc:gimp.net/frysk channel. > > A good, but very very low level, way to see the core in action is to run > its JUnit tests with logging enabled (/usr/libexec/frysk/funit -l FINE > or cd frysk-core && ./TestRunner -l FINE). A file in ~/.frysk/logs will > be created containing a log all the object|event interactions; for instance: > > {frysk.proc.LinuxTask@445370,id={TaskId,13106},state=attaching} > receiveStoppedEvent > {frysk.proc.LinuxTask@445370,id={TaskId,13106},state=attaching} > processStoppedEvent > {frysk.proc.LinuxProc@49bdc0,id={ProcId,13106},state=Attaching.ToMainTask} > performTaskAttachCompleted > > is a very small part of the event sequence that occures when frysk is > attaching to the Task (Linux LW) 13106. The corresponding code is in > frysk-core/frysk/proc/TaskState.java. The details of the state machine > pattern, on which that code is based, is found in the <> > patterns book. > > >Any help would be appreciated. > > > > > Andrew > > From woodzltc@cn.ibm.com Tue Mar 21 06:20:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 21 Mar 2006 06:20:00 -0000 Subject: About system call handling in Frysk Message-ID: Hi, Anrew and All I had some more thinking about the system call handling in Frysk. I guess that we need to set our goals first. IMHO, the following two goals might be disirable. (Maybe there are some others, but they are on the top of my mind now. If there are any errors or missing, feel free to correct me. :-) 1. to print system calls as intuitively and descriptively as possible Saying this, I am trying to mean that we should print the system call in such a way that seeing the output, user can get a good understanding about what the system call is trying to do, whether it succeed, if failed what is the reason, and so on.... 2. to support different architectures, including at least i386, ppc64 and x86_64, easy to extend to include other architectures. And to achive these goals, we might need to overcome some problems in the current Linux system. Here are some of my observation: - Different architecture support a different set of system calls. i386 has about 292 system calls in 2.6.15, ppc64 has 277, and x86_64 has 255. - The system calls interface in Linux is quite stable, but there are a few changes occasionally. some old system calls are deprecated, becoming "SYS_NI_SYSCALL"; a few new system call are added as new requirement appears. Is frysk supposed to support these old system call in old binary? And is it also supposed to support these new ones just coming into the new kernel? I believe it will be a good feature if we can support the old deprecated system calls and also the latest added ones. - Same system call in different architectures might have different number, but they should have the same format information, i.e. argument number, argument types and return type. (Is the latter assumption make sense? I didn't notice any negative proof. I would be very surprised if someone can prove me wrong. :-) - Some architecture are using multiplexer for some kinds of system call. For example, x86 and ppc64 are using ipc for ipc related system calls (shmget, shmdt, shmat.....), and using socketcall for socket related system calls (socket, connect, bind, listen...); Other architectures don't. For example, x86_64 don't work in that way, it has different call number for different ipc and socket related system call. - We can get the information about a sytem call from the kernel. But these information is very raw. We might need to translate them into more human-readable format. OK. These are my current observation. Any thought on that? I will post another mail later to discuss a potential solution I am thinking of. Thanks. From woodzltc@cn.ibm.com Wed Mar 22 15:14:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 22 Mar 2006 15:14:00 -0000 Subject: About system call handling in Frysk In-Reply-To: References: Message-ID: Had talked about the goals we might have and the problems I observed, I'd like to talk about a potential solution I am thinking of now. (It is only a very initial idea, feel free to point out anything incorrect.) First, for each architecture, we can manually maintain a file to contain a table for each system calls: the name and its number. We can name these files syscallnum-i386.list, syscallnum-ppc64.list and syscall-x86_64.list. For the very first version of them, we can get its contents from the latest kernel's asm-xxx/unistd.h file. Similar to what is in /usr/include/asm-xxx/unistd.h, these files contain all the existing system calls in different architectures. Also included in these files are these old deprecated ones, which is not implemented in current kernel. A reason not to use the user space one is that I found it is sometimes not that up-to-date as its kernel version. As new system call is added, we can add it into these files manually. Now that Linux's system call interface is quite stable, this workload is very small I believe. Then, based on these files, we can generate file SyscallNum.java for different architectures. This can be similar to the current way. But it can bring a little more uptodate information. (BTW, I notice the currrent SyscallNum.shjava will skip these system call which contain underscore, such as set_thread_area, _llseek.) Based on these files, we can also partially auto-generate array Syscall[] syscallList for Syscall.java. For this file, I want to suggest a few other changes too: First, I want to add a flag to indicate whether the sytem call is multiplexer or not. If it is, the print process will be different: it will try to print out the final dispatched system call. Next I want to extend member argList to indicate more specifically about the argument types. Currently, it supports 'a', 'b', 'p', 's', 'S' and 'i'. I am thinking that we can use more letters to distinguish between different kind of flags, modes, and so on.... We have at least 62 letters to do that (a-zA-Z0-9). So it can support a lot of things I believe. But I am not very sure if it can represent all these argument types appearing in these system calls. Having these different argument types there, maybe we can create a class to represent that. What I can figure out now is three data members: name, length and data; and one method: printer. In this way, I believe we can work out a more beautiful system call printer. Any thought on this? Regards - Wu Zhou On Tue, 21 Mar 2006, Wu Zhou wrote: > Hi, Anrew and All > > I had some more thinking about the system call handling in Frysk. > > I guess that we need to set our goals first. IMHO, the following two > goals might be disirable. > > (Maybe there are some others, but they are on the top of my mind now. > If there are any errors or missing, feel free to correct me. :-) > > 1. to print system calls as intuitively and descriptively as possible > > Saying this, I am trying to mean that we should print the system call > in such a way that seeing the output, user can get a good understanding > about what the system call is trying to do, whether it succeed, if > failed what is the reason, and so on.... > > 2. to support different architectures, including at least i386, ppc64 > and x86_64, easy to extend to include other architectures. > > > And to achive these goals, we might need to overcome some problems > in the current Linux system. Here are some of my observation: > > - Different architecture support a different set of system calls. > i386 has about 292 system calls in 2.6.15, ppc64 has 277, and > x86_64 has 255. > > - The system calls interface in Linux is quite stable, but there > are a few changes occasionally. some old system calls are > deprecated, becoming "SYS_NI_SYSCALL"; a few new system call are > added as new requirement appears. Is frysk supposed to support > these old system call in old binary? And is it also supposed to > support these new ones just coming into the new kernel? I believe > it will be a good feature if we can support the old deprecated > system calls and also the latest added ones. > > - Same system call in different architectures might have different > number, but they should have the same format information, i.e. > argument number, argument types and return type. > > (Is the latter assumption make sense? I didn't notice any negative > proof. I would be very surprised if someone can prove me wrong. :-) > > - Some architecture are using multiplexer for some kinds of system > call. For example, x86 and ppc64 are using ipc for ipc related > system calls (shmget, shmdt, shmat.....), and using socketcall for > socket related system calls (socket, connect, bind, listen...); > Other architectures don't. For example, x86_64 don't work in that > way, it has different call number for different ipc and socket > related system call. > > - We can get the information about a sytem call from the kernel. > But these information is very raw. We might need to translate > them into more human-readable format. > > > OK. These are my current observation. Any thought on that? > > I will post another mail later to discuss a potential solution > I am thinking of. > > Thanks. > From woodzltc@cn.ibm.com Thu Mar 23 07:07:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 23 Mar 2006 07:07:00 -0000 Subject: A workaround for the PPC32 ICE in cninner Message-ID: Hi Andrew, Janis Johnson provided a workaround for this ICE in mark_reference_fields, at java/boehm.c:105. Here it is: *** Parent.java.old 2006-03-23 06:29:35.000000000 +0800 --- Parent.java 2006-03-23 06:30:08.000000000 +0800 *************** class Parent *** 8,12 **** --- 8,13 ---- protected long p; protected long q; + protected int dummy; byte[] scratch = new byte[8]; } What do you think on this work-around? Can it get into the CVS, so that I can go on with the ppc32 test more smoothly? Thanx - Wu Zhou From woodzltc@linux.ibm.com Thu Mar 23 10:15:00 2006 From: woodzltc@linux.ibm.com (woodzltc@linux.ibm.com) Date: Thu, 23 Mar 2006 10:15:00 -0000 Subject: the blankness of the frysk GUI on PPC64 Message-ID: <20060323051500.5jywbrvp6owoog44@imap.linux.ibm.com> Fedora Core 5 was out a couple of days ago. So I update my PPC64 box with the latest Fedora Core 5 GA release. After applying the workaround for PPC32 internal compiler error with frysk-imports/tests/cniinner, the latest frysk CVS code build ok. But when I starts frysk, I found some of the frysk windows are blank. At the very beginning, besides the processes window, all other windows are blank (including threads window, the right timeline windows and observer windows). When I choose one process (to say a bash process) to add a fork observer, the popped out menu is also blank. After moving the mouse to the "add observer" menu, it return to normal case. After choosing "fork observer", all these windows (except the right downside window is still blank) return back to normal again. Because I am not familar with x programming, would anyone please have a look on that? Thanks a lot in advance. I attach the final screeshot here for your kind reference. If any problems, please contact me. Thanx - Wu Zhou P.S: seen from the above screenshot, fork follow worked on PPC. I guess this is a great progress. Good work, Guys! BTW, are you now working on Fedora 5, or still Fedora 4? I believe it is time for us to advance to Fedora 5. -------------- next part -------------- A non-text attachment was scrubbed... Name: GUI-blankness-20060323.JPG Type: image/jpeg Size: 139192 bytes Desc: not available URL: From pmuldoon@redhat.com Thu Mar 23 15:26:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 23 Mar 2006 15:26:00 -0000 Subject: the blankness of the frysk GUI on PPC64 In-Reply-To: <20060323051500.5jywbrvp6owoog44@imap.linux.ibm.com> References: <20060323051500.5jywbrvp6owoog44@imap.linux.ibm.com> Message-ID: <1143127577.2606.4.camel@dhcp-12.hsv.redhat.com> On Thu, 2006-03-23 at 05:15 -0500, woodzltc@linux.ibm.com wrote: > But when I starts frysk, I found some of the frysk windows are blank. > At the very beginning, besides the processes window, all other windows > are blank (including threads window, the right timeline windows and > observer windows). When I choose one process (to say a bash process) > to add a fork observer, the popped out menu is also blank. After > moving the mouse to the "add observer" menu, it return to normal case. > After choosing "fork observer", all these windows (except the right > downside window is still blank) return back to normal again. Ugh, thanks for the report. It's good to see and fix all of these corner cases. > Because I am not familar with x programming, would anyone please have > a look on that? Thanks a lot in advance. Not sure what this might be, but we will investigate. Might possibly be a Java-GNOME issue on that particular arch. > I attach the final screeshot here for your kind reference. If any > problems, please contact me. So that we can track it, and not forget about it, can you do me a big favor and enter it in bugzilla? (http://sourceware.org/bugzilla/). If you can't do it, let me know and I will enter it for you. > P.S: seen from the above screenshot, fork follow worked on PPC. I > guess this is a great progress. Good work, Guys! Thanks, there has been a lot of progress made in the last several months. Regards Phil From pmuldoon@redhat.com Fri Mar 24 14:16:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Mar 2006 14:16:00 -0000 Subject: Druid Validation Message-ID: <1143209794.3835.13.camel@localhost.localdomain> Hi all We are experimenting with a Druid (or Wizard) that starts up, and tailors your "session" to be more specific with the users needs (IE interesting processes, processes that when they exit cause an action to happen, and so on). We think this will help streamline the experience. After a small amount of looking around, it seems that validation in a Druid seems to be a non-standard gui concept. Eclipse - for example - does hot validation on a multi-page Druid. So there are several approaches. How should we do it? Here are several approaches I have seen recently. 1) Hot Validation. The Next button is disabled (grayed) until all information is correct and entered on that page. When correct information is entered and completed, the Next button becomes enabled. Edit any information to make it incorrect or incomplete, and the Next button will move from an enabled state to a disabled state. Concerns about this are: confusion regarding what information is correct if the only prompt you receive is a disabled/enabled button. What does the druid want? 2) Dialog based error/warnings. This time the Next (and Back) icons are always enabled. If the user clicks Next and the information is incomplete for that page, a dialog box will show explaining what they are missing, and what is incorrect. The user clears the dialog and fixes the information. Concerns here are 1) should the dialog box be modal as not to get lost behind other windows if the user clicks out; 2) if the box is modal, clearing the dialog box will remove the "what is wrong" information. 3) Finish based authentication. No validation is done until the user clicks Finish. Then something like 2) will happen. I'm not a fan at all of this approach. Any thoughts here are welcome. Regards Phil From pmuldoon@redhat.com Fri Mar 24 15:15:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Mar 2006 15:15:00 -0000 Subject: Druid Validation In-Reply-To: <1143211962.3164.30.camel@peach> References: <1143209794.3835.13.camel@localhost.localdomain> <1143211962.3164.30.camel@peach> Message-ID: <1143213296.3835.29.camel@localhost.localdomain> > Do the page-by-page approach, and make it obvious why you're not letting > them move on. Don't warn them through a paragraph of text at the top of > the Druid -- do it through a limited set of inputs and intelligent > guessing. You can warn them with feedback inside the Assistant if it's > not obvious. As an example, consider a password dialog: > > Enter Password [***** ] > Reenter Password [***** ] > > If the passwords don't match, you can't move on. Popping up a dialog is > annoying. Waiting until the end is a non-starter. > > Anaconda (when it had this screen) put a little bit of smaller, italic, > red text beneath the password dialog saying 'Passwords do not match'. > It's then clear to the user that you can't enter the password. When > they do match (or the entries are cleared) the warning text is hidden, > and next button is desensitised. Good points on the Anaconda example. I'm going to install FC5 gold on a home system here today, so I will look closely and see how that achieves the goals in mind. It seems from what you describe, the page-by-page with some kind of hinting mechanism is the way forward. I looked at the Assistants section in the HIG but it had nothing to say about validation (and nothing I could find on Druids as a concept). It's equally possible that I just missed it. As a side note, I installed FC5 on a work system yesterday, and I did not get "lost" at all, and it asks for rather large amount of technical information. So I'm guessing that is a decent model to follow then. I'm a bit leery of long multi-page wizards (esp the ones that dynamically insert pages depending on user selection). I notice Anaconda keeps the pages specified to one particular information-type needed at any one time, but allows the user to drill down inside that page (selecting packages other than default is a good example here). Is there a guide, or a general philosophy here? How long does a user sit in a Druid before becoming frustrated, or bored (and just starts entering bogus information to "move on"). How many pages before they get cranky and irritated at the endless questions? So many questions ;) Regards Phil From rmoseley@redhat.com Fri Mar 24 15:47:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Fri, 24 Mar 2006 15:47:00 -0000 Subject: Preliminary DOM Doc Message-ID: <44241493.4050307@redhat.com> Hi all, The Frysk back-end and the Frysk front-end(GUI) will be using a DOM(Document Object Model) to model the source code information. DOM is used by several open source projects to perform this task, Eclipse not being the least of these. In fact, we are using the Eclipse CDT parser to provide us with the information to put into the DOM to highlight keywords, etc. I have attached a document that I have written that describes the Frysk DOM that is a current snapshot of what it looks like at this stage of development. The Frysk DOM will be changing as we move into the implementation phase of the source window. I will endeavor to keep the document as up-to-date as I possibly can. I am sending a copy of this doc to our docs person, Mike Behm, to be polished up and at some point it will be checked into the CVS repo for Frysk. As usual, any comments, suggestions, ideas are welcomed. Rick PS: Thanks to Adam Jocksch for his help with this document. -------------- next part -------------- A non-text attachment was scrubbed... Name: DOM_doc.odt Type: application/vnd.oasis.opendocument.text Size: 13584 bytes Desc: not available URL: From cagney@redhat.com Fri Mar 24 15:49:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 24 Mar 2006 15:49:00 -0000 Subject: Druid Validation In-Reply-To: <1143209794.3835.13.camel@localhost.localdomain> References: <1143209794.3835.13.camel@localhost.localdomain> Message-ID: <4424159D.6080108@redhat.com> > > I think this is something that really should be determined by the desktop [GNOME] and not on a per application basis. If there isn't consistency then it could either be due to flux or a lack of clear guidelines. As an example of flux, I'm pretty sure that OS-X was once using Dialog based validation but as new apps come out they are switching more to Hot Validation (true?). >1) Hot Validation. The Next button is disabled (grayed) until all >information is correct and entered on that page. When correct >information is entered and completed, the Next button becomes enabled. >Edit any information to make it incorrect or incomplete, and the Next >button will move from an enabled state to a disabled state. Concerns >about this are: confusion regarding what information is correct if the >only prompt you receive is a disabled/enabled button. What does the >druid want? > > > Yes, sometimes frustrating when trying to figure out why that damd next box is still disabled, but more direct in feedback - you're not finished here :-) >2) Dialog based error/warnings. This time the Next (and Back) icons are >always enabled. If the user clicks Next and the information is >incomplete for that page, a dialog box will show explaining what they >are missing, and what is incorrect. The user clears the dialog and fixes >the information. Concerns here are 1) should the dialog box be modal as >not to get lost behind other windows if the user clicks out; 2) if the >box is modal, clearing the dialog box will remove the "what is wrong" >information. > > For obvious technical reasons, this is popular with web pages. Now-a-days, instead of a dialog, the messages are done in place - if the submition is rejected, look for the red ink. >3) Finish based authentication. No validation is done until the user >clicks Finish. Then something like 2) will happen. I'm not a fan at all >of this approach. > > Agree with this. From mbehm@redhat.com Fri Mar 24 15:58:00 2006 From: mbehm@redhat.com (Michael Behm) Date: Fri, 24 Mar 2006 15:58:00 -0000 Subject: Druid Validation Message-ID: <44241737.8060501@redhat.com> Phil Muldoon said: > 2) Dialog based error/warnings. This time the Next (and Back) > icons are always enabled. If the user clicks Next and the > information is incomplete for that page, a dialog box will > show explaining what they are missing, and what is incorrect. > The user clears the dialog and fixes the information. Concerns > here are 1) should the dialog box be modal as not to get lost > behind other windows if the user clicks out; 2) if the box is > modal, clearing the dialog box will remove the "what is wrong" > information. Could you have a status window at the bottom of the dialog? Initially this would be blank, but as the system validates each field and detects an error, the status message would be something like: " requires a ." Depending on the parsing you do for the error checking, you might also be able to provide a hint: "The IP address entered was previously assigned to ." The down-side is that this would use up screen space, but the message would not get lost. You could also display the erroneous information in in red until it gets corrected. Mike From pmuldoon@redhat.com Fri Mar 24 16:20:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Mar 2006 16:20:00 -0000 Subject: Druid Validation In-Reply-To: <4424159D.6080108@redhat.com> References: <1143209794.3835.13.camel@localhost.localdomain> <4424159D.6080108@redhat.com> Message-ID: <1143217214.3835.36.camel@localhost.localdomain> On Fri, 2006-03-24 at 10:51 -0500, Andrew Cagney wrote: > > > > > I think this is something that really should be determined by the > desktop [GNOME] and not on a per application basis. If there isn't > consistency then it could either be due to flux or a lack of clear > guidelines. As an example of flux, I'm pretty sure that OS-X was once > using Dialog based validation but as new apps come out they are > switching more to Hot Validation (true?). Yes, true. I did not find any specific stuff in the HIG so I thought I would ask my peers ;) Though I suppose one could draw from the overreaching philosophies from the general Usability Principles. It really is an excellent document. > >1) Hot Validation. The Next button is disabled (grayed) until all > >information is correct and entered on that page. When correct > >information is entered and completed, the Next button becomes enabled. > >Edit any information to make it incorrect or incomplete, and the Next > >button will move from an enabled state to a disabled state. Concerns > >about this are: confusion regarding what information is correct if the > >only prompt you receive is a disabled/enabled button. What does the > >druid want? > > > > > > > Yes, sometimes frustrating when trying to figure out why that damd next > box is still disabled, but more direct in feedback - you're not finished > here :-) Yes, I remember (I think it was the web tools wizard) when I was just totally puzzled as to what they wanted from me. No hints, nothing obvious, just a gray "Next" button. Well it turned out that I mis- configured something in a previous page, and that had not populated a control properly on the current page. Still the experience stayed with me ;) Regards Phil From pmuldoon@redhat.com Fri Mar 24 17:32:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 24 Mar 2006 17:32:00 -0000 Subject: Druid Validation In-Reply-To: <44241737.8060501@redhat.com> References: <44241737.8060501@redhat.com> Message-ID: <1143221515.3835.42.camel@localhost.localdomain> On Fri, 2006-03-24 at 10:58 -0500, Michael Behm wrote: > Phil Muldoon said: > > > 2) Dialog based error/warnings. This time the Next (and Back) > > icons are always enabled. If the user clicks Next and the > > information is incomplete for that page, a dialog box will > > show explaining what they are missing, and what is incorrect. > > The user clears the dialog and fixes the information. Concerns > > here are 1) should the dialog box be modal as not to get lost > > behind other windows if the user clicks out; 2) if the box is > > modal, clearing the dialog box will remove the "what is wrong" > > information. > > Could you have a status window at the bottom of the dialog? Initially > this would be blank, but as the system validates each field and detects > an error, the status message would be something like: > " requires a ." > Depending on the parsing you do for the error checking, you might also > be able to provide a hint: > "The IP address entered was previously assigned to ." > > The down-side is that this would use up screen space, but the message > would not get lost. You could also display the erroneous information in > in red until it gets corrected. This seems along the lines of the "Next button is gray, here is a hint as to why" type of idea. I like the ideas of contextually/history rich hint information (your IP address example). Something to think on, when we actually create the session data during the Druid; and how to construct it from top-bottom so we can drill back to provide the richness of hint-data you suggest. Regards Phil From jrb@redhat.com Fri Mar 24 19:26:00 2006 From: jrb@redhat.com (Jonathan Blandford) Date: Fri, 24 Mar 2006 19:26:00 -0000 Subject: Druid Validation In-Reply-To: <1143221515.3835.42.camel@localhost.localdomain> References: <44241737.8060501@redhat.com> <1143221515.3835.42.camel@localhost.localdomain> Message-ID: <1143228368.8404.84.camel@localhost.localdomain> On Fri, 2006-03-24 at 11:31 -0600, Phil Muldoon wrote: > This seems along the lines of the "Next button is gray, here is a hint > as to why" type of idea. I like the ideas of contextually/history rich > hint information (your IP address example). Something to think on, when > we actually create the session data during the Druid; and how to > construct it from top-bottom so we can drill back to provide the > richness of hint-data you suggest. I'd really like you guys to consider the hint-data to be a crutch, only used when necessary. They're distracting, especially when the hints are just of the form 'you need to include this information' to proceed. The password hint example is useful because it goes beyond that -- it indicates that the data isn't valid when it's not clear to the user that it is (due to '*' obfuscation). Basically, if your assistant needs lots of hints of how to enter the information, it's time to rethink the assistant. Thanks, -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Sun Mar 26 20:54:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 26 Mar 2006 20:54:00 -0000 Subject: [Fwd: [Java-gnome-developer] java-gnome 2.14.0] Message-ID: <44270034.9080003@redhat.com> read the blog, congrats to Adam, Sami, Rick, Phil, and Igor. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Cowie Subject: [Java-gnome-developer] java-gnome 2.14.0 Date: Sun, 26 Mar 2006 21:00:08 +1000 Size: 4466 URL: From pmuldoon@redhat.com Wed Mar 29 18:44:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 29 Mar 2006 18:44:00 -0000 Subject: Mailing list test Message-ID: <1143657873.3842.5.camel@localhost.localdomain> Test email to check for bounces. Regards Phil From cagney@redhat.com Wed Mar 29 20:08:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Mar 2006 20:08:00 -0000 Subject: Preliminary DOM Doc In-Reply-To: <44241493.4050307@redhat.com> References: <44241493.4050307@redhat.com> Message-ID: <442AE9A7.4070608@redhat.com> Rick, nice! Since this is describing internals, and since we're using javadoc/gjdoc, this can be added to: frysk-core/frysk/dom/package.html and the corresponding .java files making it an integral part of our programmer documentation. For reference the current frysk.doc page is here: http://sourceware.org/frysk/javadoc/public/frysk/dom/package-summary.html Images are possible, see the frysk.proc directory. We also need to get away from using the overloaded DOM term (i.e., frysk.dom) :-) DOM is either Domain Object Model (how I use it) and Document Object Model (how w3c uses it). Talking with Adam, one possible package name would be frysk.source (sounds good, doesn't mean anything :-). Any thoughts there? One thing I'm not clear on is the relationship between the run-time representation (based on debug info) and the source code representation. Perhaps that can be mentioned. If you've got questions bug me here or IRC (I'll be off line until Monday). Andrew From cagney@redhat.com Wed Mar 29 20:32:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Mar 2006 20:32:00 -0000 Subject: A workaround for the PPC32 ICE in cninner In-Reply-To: References: Message-ID: <442AEF90.40109@redhat.com> Wu Zhou wrote: (catching up with old e-mail) How's it going getting the up-stream GCC bug fixed? Our best practice here is to first fully investigate the up-stream bug and attempt a fix; and second, with that knowledge, assess if it will be better to back-port or work-around. In doing this we help to limit the number of hacks we have to carry in our code (and there have potentially been many many of those). Andrew Andrew > Hi Andrew, > > Janis Johnson provided a workaround for this ICE in mark_reference_fields, > at java/boehm.c:105. Here it is: > > *** Parent.java.old 2006-03-23 06:29:35.000000000 +0800 > --- Parent.java 2006-03-23 06:30:08.000000000 +0800 > *************** class Parent > *** 8,12 **** > --- 8,13 ---- > protected long p; > protected long q; > > + protected int dummy; > byte[] scratch = new byte[8]; > } > > What do you think on this work-around? Can it get into the CVS, so that I > can go on with the ppc32 test more smoothly? > > Thanx > - Wu Zhou > From rmoseley@redhat.com Wed Mar 29 21:02:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Wed, 29 Mar 2006 21:02:00 -0000 Subject: Using Eclipse with Frysk Message-ID: <442AF5D5.6090009@redhat.com> Hi all, Someone asked on #frysk the other day about using Eclipse to work on Frysk and suggested we add some how-to detail to the Frysk webpage. I told them I was using it, although in a somewhat degraded manner. For a number of reasons, Eclipse cannot be used to totally build Frysk, but it can be a great help in writing/modifying any Java code despite what the emacs pushers say. :) Here are the steps I use in bringing Frysk into an Eclipse project on an FC5 system. If someone has a better way, please feel free to chime in. 1) Check out frysk from the website(see http://sourceware.org/frysk for how to do this) 2) Bring up Eclipse 3) Click on File->New->Java Project->Next 4) Enter your desired project name 5) Select the "Create project from existing source" 6) "Browse..." to the directory where Frysk was imported 7) Select the top level "frysk" directory that came in from CVS 8) Click on "Next" 9) Select the "Libraries" tab at the top of the window 10) Select "Add External JARS..." 11) Browse to /usr/share/java and add the following jars: cairo1.0.jar (cairo-java) glade2.12.jar (libglade-java) glib0.2.jar (glib-java) gnome2.12.jar (libgnome-java) gnu.getopt.jar (gnu-getopt) gtk2.8.jar (libgtk-java) jdom.jar (jdom) If you do not have one of the jars listed, you will need to add the package listed on the right in parentheses that provides it to your system. 12) Click on "Finish" You should wind up with a fairly usable project with the Frysk source code. You can make modifications to the source code and check them back into the CVS repo, but you will still need to build Frysk from the command line. I usually have two different Frysk repos checked out, one I use to build Frysk("build" repo), and another that I use for Eclipse only("eclipse repo"). I usually do the editing with Eclipse, check it in, and then go to the "build" repo, do a "cvs update -d" and then rebuild there. Also, usually, each morning I do a "cvs update -d" in the eclipse repo to make sure I have the latest source there. Hope this helps. As I said earlier, if anyone has a better way, please feel free to add your comments/suggestions. Rick From cagney@redhat.com Wed Mar 29 21:21:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Mar 2006 21:21:00 -0000 Subject: Re-baseing to FC-5 (a.k.a. strace-clone-exec bug) Message-ID: <442AFAF6.1000000@redhat.com> Hello, Now that FC-5 (which includes the much improved GCC 4.1 along with many other good things) is released, it is probably time to switch any remaining focus away from FC-4, to FC-5 and beyond. With that in mind, FC-5 has one known problem: The strace-clone-exec test failure. Would anyone have a cheat sheet on how to build a Linux kernel with the relevant change removed? I can then update http://sourceware.org/frysk/build/ to explain the need to do this while we, in parallel, see about getting the kernel fixed. Andrew From cagney@redhat.com Wed Mar 29 21:36:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Mar 2006 21:36:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: <442AF5D5.6090009@redhat.com> References: <442AF5D5.6090009@redhat.com> Message-ID: <442AFE92.8050107@redhat.com> Rick Moseley wrote: > I usually do the editing with Eclipse, check it in, and then go to the > "build" repo, do a "cvs update -d" and then rebuild there. We need a better way. Our practice here is to always build and testsuite our code _before_ committing; and not use the repo as a scratch pad. Andrew From cagney@redhat.com Wed Mar 29 22:16:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 29 Mar 2006 22:16:00 -0000 Subject: About system call handling in Frysk In-Reply-To: References: Message-ID: <442B07C9.2080408@redhat.com> Wu Zhou wrote: (and wrote a follow-on) > Hi, Anrew and All > > I had some more thinking about the system call handling in Frysk. > > I guess that we need to set our goals first. IMHO, the following two > goals might be disirable. > > (Maybe there are some others, but they are on the top of my mind now. > If there are any errors or missing, feel free to correct me. :-) > > 1. to print system calls as intuitively and descriptively as possible > > I think this is actually a secondary goal (or perhaps can be thought of as a bonus from good design). That the current code made this the sole focus is unfortunate. If all someone wants to do is generate system traces then they can and will use strace. As your go on to explain there are a number of components: - the ISA/ABI specific calling convention object. Given a thread, and the knowledge of a specific ISA/ABI, this knows how to extract raw system call entry and exit values. At present this is implemented as SyscallEventInfo; SyscallEventInfo .number (Task), for instance, returns the system call number extracted from the task. As you explain, implementations for more ISA's and architectures are required. - the per-kernel system call database (you called it SyscallNum) At present this is hardwired in Syscall.java; and is customized for printing system call information to stdout. I think the object should be better abstracted so that it describes the system call - name, number, return, arguments and that means doing better than single letters as the encoding. It would also need to encapsulate the possibility of multiple system call numbers for single name. Being able to generate this from kernel information would be ideal (other kernels actually contain such a file and generate the system call code using that as input). What of the possibility of loading the file at run-time, rather than generating / wiring it in? - a system call print observer Given a task, it monitors for system calls, uses the the above two in combination to print the system to a stream - other more custom observers For instance, an observer, might monitor system calls watching for mmap, and then when it sees the call take applicable action - such as kill the task. > Saying this, I am trying to mean that we should print the system call > in such a way that seeing the output, user can get a good understanding > about what the system call is trying to do, whether it succeed, if > failed what is the reason, and so on.... > > 2. to support different architectures, including at least i386, ppc64 > and x86_64, easy to extend to include other architectures. > > > And to achive these goals, we might need to overcome some problems > in the current Linux system. Here are some of my observation: > > yes > - Different architecture support a different set of system calls. > i386 has about 292 system calls in 2.6.15, ppc64 has 277, and > x86_64 has 255. > > yes > - The system calls interface in Linux is quite stable, but there > are a few changes occasionally. some old system calls are > deprecated, becoming "SYS_NI_SYSCALL"; a few new system call are > added as new requirement appears. Is frysk supposed to support > these old system call in old binary? And is it also supposed to > support these new ones just coming into the new kernel? I believe > it will be a good feature if we can support the old deprecated > system calls and also the latest added ones. > > yes, it is a good goal. We're after flexibility and maintainability here. Of course, the second iteration (we've already had the first :-) need only focus on current kernels. I've my doubts that any one will run frysk on an old kernel :-) > - Same system call in different architectures might have different > number, but they should have the same format information, i.e. > argument number, argument types and return type. > > (Is the latter assumption make sense? I didn't notice any negative > proof. I would be very surprised if someone can prove me wrong. :-) > > I believe so. I think we can work with that assumption at the moment - lets only try to worry about esoteric architectures when we've got esoteric architectures to worry about. > - Some architecture are using multiplexer for some kinds of system > call. For example, x86 and ppc64 are using ipc for ipc related > system calls (shmget, shmdt, shmat.....), and using socketcall for > socket related system calls (socket, connect, bind, listen...); > Other architectures don't. For example, x86_64 don't work in that > way, it has different call number for different ipc and socket > related system call. > > I'm not sure what you mean here. Based on your other e-mail I know you mean more than having a single system call instruction with the call-number stored in a register. > - We can get the information about a sytem call from the kernel. > But these information is very raw. We might need to translate > them into more human-readable format. > > If you mean register values and the like, yes. > OK. These are my current observation. Any thought on that? > > I will post another mail later to discuss a potential solution > I am thinking of. > > Thanks. > I'll look at that next. Andrew From woodzltc@cn.ibm.com Thu Mar 30 05:31:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 30 Mar 2006 05:31:00 -0000 Subject: Re-baseing to FC-5 (a.k.a. strace-clone-exec bug) In-Reply-To: <442AFAF6.1000000@redhat.com> References: <442AFAF6.1000000@redhat.com> Message-ID: On Wed, 29 Mar 2006, Andrew Cagney wrote: > Hello, > > Now that FC-5 (which includes the much improved GCC 4.1 along with many other > good things) is released, it is probably time to switch any remaining focus > away from FC-4, to FC-5 and beyond. > > With that in mind, FC-5 has one known problem: The strace-clone-exec test > failure. Would anyone have a cheat sheet on how to build a Linux kernel with > the relevant change removed? I will try to work out one with the FC-5 shipped kernel. I was originally working with 2.6.15 kernel. Thanx - Wu Zhou From woodzltc@cn.ibm.com Thu Mar 30 10:31:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 30 Mar 2006 10:31:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: <442AF5D5.6090009@redhat.com> References: <442AF5D5.6090009@redhat.com> Message-ID: On Wed, 29 Mar 2006, Rick Moseley wrote: > Hi all, > > Someone asked on #frysk the other day about using Eclipse to work on Frysk and > suggested we add some how-to detail to the Frysk webpage. I told them I was > using it, although in a somewhat degraded manner. For a number of reasons, > Eclipse cannot be used to totally build Frysk, but it can be a great help in > writing/modifying any Java code despite what the emacs pushers say. :) Yes. I have similar feeling as you. I found it most useful in reading Java code. This can help me to understand Frysk's code. :-) BTW, can you elaborate a little on why Eclipse can't be used to build Frysk? Is the building process of Frysk one of the reason? I guess Eclipse can't emulate the building process Frysk is using. But I am not very sure. I am very new to Eclipse indeed. If it can, I guess that will be great. We can have Frysk as one of Eclipse plugins. I believe this will make Frysk easy to inter-operate with other tools. > Here are the steps I use in bringing Frysk into an Eclipse project on an FC5 > system. If someone has a better way, please feel free to chime in. > > 1) Check out frysk from the website(see http://sourceware.org/frysk for how > to do this) > 2) Bring up Eclipse > 3) Click on File->New->Java Project->Next > 4) Enter your desired project name > 5) Select the "Create project from existing source" > 6) "Browse..." to the directory where Frysk was imported > 7) Select the top level "frysk" directory that came in from CVS > 8) Click on "Next" > 9) Select the "Libraries" tab at the top of the window > 10) Select "Add External JARS..." > 11) Browse to /usr/share/java and add the following jars: > cairo1.0.jar (cairo-java) > glade2.12.jar (libglade-java) > glib0.2.jar (glib-java) > gnome2.12.jar (libgnome-java) > gnu.getopt.jar (gnu-getopt) > gtk2.8.jar (libgtk-java) > jdom.jar (jdom) One novice question: how to attach the source code of these package into Eclipse (or the new created Frysk project)? This can help me track into the java-gnome code. I guess I might need to create a java-gnome project some where. Or some action else? > If you do not have one of the jars listed, you will need to add the > package listed on the right in parentheses that provides it to your > system. > > 12) Click on "Finish" > > > You should wind up with a fairly usable project with the Frysk source code. > You can make modifications to the source code and check them back into the CVS > repo, but you will still need to build Frysk from the command line. I usually > have two different Frysk repos checked out, one I use to build Frysk("build" > repo), and another that I use for Eclipse only("eclipse repo"). I usually do > the editing with Eclipse, check it in, and then go to the "build" repo, do a > "cvs update -d" and then rebuild there. Also, usually, each morning I do a > "cvs update -d" in the eclipse repo to make sure I have the latest source > there. > > Hope this helps. As I said earlier, if anyone has a better way, please feel > free to add your comments/suggestions. Yes. It is really helpful. Thanks a bunch! Regards - Wu Zhou From woodzltc@cn.ibm.com Thu Mar 30 10:39:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 30 Mar 2006 10:39:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: <442AFE92.8050107@redhat.com> References: <442AF5D5.6090009@redhat.com> <442AFE92.8050107@redhat.com> Message-ID: On Wed, 29 Mar 2006, Andrew Cagney wrote: > Rick Moseley wrote: > > I usually do the editing with Eclipse, check it in, and then go to the > > "build" repo, do a "cvs update -d" and then rebuild there. > We need a better way. Our practice here is to always build and testsuite our > code _before_ committing; and not use the repo as a scratch pad. Does it work to simply copy the modified files from "eclipse repo" to "build repo"? Then build and test in "build repo". If no problem found, then commit? Just my two cents anyway. Thanx - Wu Zhou From rmoseley@redhat.com Thu Mar 30 15:57:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 30 Mar 2006 15:57:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: References: <442AF5D5.6090009@redhat.com> <442AFE92.8050107@redhat.com> Message-ID: <442BFFDF.8060305@redhat.com> Wu Zhou wrote: > On Wed, 29 Mar 2006, Andrew Cagney wrote: > > >> Rick Moseley wrote: >> >>> I usually do the editing with Eclipse, check it in, and then go to the >>> "build" repo, do a "cvs update -d" and then rebuild there. >>> >> We need a better way. Our practice here is to always build and testsuite our >> code _before_ committing; and not use the repo as a scratch pad. >> > > Does it work to simply copy the modified files from "eclipse repo" to > "build repo"? Then build and test in "build repo". If no problem found, > then commit? > Yeah, that would be the easiest way for sure. Write a semi-sophisticated script that copies over just the modules you have changed to the "build repo", test and then commit from there or from the "eclipse repo" if all tests pass. > Just my two cents anyway. > > Thanx > - Wu Zhou > From rmoseley@redhat.com Thu Mar 30 16:13:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 30 Mar 2006 16:13:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: References: <442AF5D5.6090009@redhat.com> Message-ID: <442C0397.5060400@redhat.com> Wu Zhou wrote: > On Wed, 29 Mar 2006, Rick Moseley wrote: > > >> Hi all, >> >> Someone asked on #frysk the other day about using Eclipse to work on Frysk and >> suggested we add some how-to detail to the Frysk webpage. I told them I was >> using it, although in a somewhat degraded manner. For a number of reasons, >> Eclipse cannot be used to totally build Frysk, but it can be a great help in >> writing/modifying any Java code despite what the emacs pushers say. :) >> > > Yes. I have similar feeling as you. I found it most useful in reading > Java code. This can help me to understand Frysk's code. :-) > > BTW, can you elaborate a little on why Eclipse can't be used to build > Frysk? Is the building process of Frysk one of the reason? I guess > Eclipse can't emulate the building process Frysk is using. But I am not > very sure. I am very new to Eclipse indeed. That is pretty much the problem in a nutshell. Eclipse does not play well with projects generated with the "autotools" method we are using in Frysk. There is an effort underway within Red Hat right now on the Eclipse development team to write a plugin that will make Eclipse more friendly with autotools projects. We'll keep an eye on that to see if Frysk can utilize it. > > > If it can, I guess that will be great. We can have Frysk as one of Eclipse > plugins. I believe this will make Frysk easy to inter-operate with other > tools. > On the roadmap is to have Frysk available as an Eclipse plugin, but that is quite a ways down the road. > > >> Here are the steps I use in bringing Frysk into an Eclipse project on an FC5 >> system. If someone has a better way, please feel free to chime in. >> >> 1) Check out frysk from the website(see http://sourceware.org/frysk for how >> to do this) >> 2) Bring up Eclipse >> 3) Click on File->New->Java Project->Next >> 4) Enter your desired project name >> 5) Select the "Create project from existing source" >> 6) "Browse..." to the directory where Frysk was imported >> 7) Select the top level "frysk" directory that came in from CVS >> 8) Click on "Next" >> 9) Select the "Libraries" tab at the top of the window >> 10) Select "Add External JARS..." >> 11) Browse to /usr/share/java and add the following jars: >> cairo1.0.jar (cairo-java) >> glade2.12.jar (libglade-java) >> glib0.2.jar (glib-java) >> gnome2.12.jar (libgnome-java) >> gnu.getopt.jar (gnu-getopt) >> gtk2.8.jar (libgtk-java) >> jdom.jar (jdom) >> > > One novice question: how to attach the source code of these package into > Eclipse (or the new created Frysk project)? This can help me track into the > java-gnome code. I guess I might need to create a java-gnome project some > where. Or some action else? > You can go out to the Fedora download servers and get the source rpms for any of these packages and install them and import them into Eclipse. > >> If you do not have one of the jars listed, you will need to add the >> package listed on the right in parentheses that provides it to your >> system. >> >> 12) Click on "Finish" >> >> >> You should wind up with a fairly usable project with the Frysk source code. >> You can make modifications to the source code and check them back into the CVS >> repo, but you will still need to build Frysk from the command line. I usually >> have two different Frysk repos checked out, one I use to build Frysk("build" >> repo), and another that I use for Eclipse only("eclipse repo"). I usually do >> the editing with Eclipse, check it in, and then go to the "build" repo, do a >> "cvs update -d" and then rebuild there. Also, usually, each morning I do a >> "cvs update -d" in the eclipse repo to make sure I have the latest source >> there. >> >> Hope this helps. As I said earlier, if anyone has a better way, please feel >> free to add your comments/suggestions. >> > > Yes. It is really helpful. Thanks a bunch! > Glad to be of service. We hope you will be making contributions to the Frysk project in the near future. :) Rick > Regards > - Wu Zhou > From cagney@redhat.com Thu Mar 30 22:18:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 30 Mar 2006 22:18:00 -0000 Subject: Using Eclipse with Frysk In-Reply-To: <442C0397.5060400@redhat.com> References: <442AF5D5.6090009@redhat.com> <442C0397.5060400@redhat.com> Message-ID: <442C599E.7060101@redhat.com> Rick Moseley wrote: > Wu Zhou wrote: >> On Wed, 29 Mar 2006, Rick Moseley wrote: >> >> >>> Hi all, >>> >>> Someone asked on #frysk the other day about using Eclipse to work on >>> Frysk and >>> suggested we add some how-to detail to the Frysk webpage. I told >>> them I was >>> using it, although in a somewhat degraded manner. For a number of >>> reasons, >>> Eclipse cannot be used to totally build Frysk, but it can be a great >>> help in >>> writing/modifying any Java code despite what the emacs pushers >>> say. :) >>> >> >> Yes. I have similar feeling as you. I found it most useful in >> reading Java code. This can help me to understand Frysk's code. :-) >> >> BTW, can you elaborate a little on why Eclipse can't be used to build >> Frysk? Is the building process of Frysk one of the reason? I guess >> Eclipse can't emulate the building process Frysk is using. But I am >> not very sure. I am very new to Eclipse indeed. > That is pretty much the problem in a nutshell. Eclipse does not play > well with projects generated with the "autotools" method we are using > in Frysk. There is an effort underway within Red Hat right now on the > Eclipse development team to write a plugin that will make Eclipse more > friendly with autotools projects. We'll keep an eye on that to see if > Frysk can utilize it. Why wait! Very early on I got frysk building from within Eclipse using a few basic custom builders. I abandoned the effort when I found the Eclipse I had crashed before I could use it to do anything useful, hopefully that aspect has improved. Given how simple what I did was (it was knocked up in a few hours, less if you ignore the crashes ;-), creating something similar should be easy. For a reference implementation I'd look at CLASSPATH; simply adopting their mechanism may even be possible. Of course getting this working may require a few tweaks to our build system, for instance: -- autogen.sh's behavior isn't right: should also run configure; and handle a relative path -- consistency between where eclipse and frysk put the jar files could save a few steps (but might also prove dangerous) Andrew From cagney@redhat.com Fri Mar 31 00:39:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 31 Mar 2006 00:39:00 -0000 Subject: web page updates Message-ID: <442C7AD5.2010607@redhat.com> I've made a few web page changes - documentation: http://sourceware.org/frysk/documentation/ The links page was folded in; better links to how to build added; a Recommended Reading List was added. - workflows: http://sourceware.org/frysk/workflow/ New, very new; still very empty. However the very raw sketches of two workflows have been added. I know more have been discussed somewhere. Please feel free to add at will. - front page: A brief summary of each tab is at the bottom. Andrew From woodzltc@cn.ibm.com Fri Mar 31 05:57:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 31 Mar 2006 05:57:00 -0000 Subject: Re-baseing to FC-5 (a.k.a. strace-clone-exec bug) In-Reply-To: References: <442AFAF6.1000000@redhat.com> Message-ID: I just finished a try on both x86 and ppc64. Here is my process: 1. get the kernel source rpm from fedora site, and install it to the standard location. # wget http://download.fedora.redhat.com/pub/fedora/linux/core/5/source/SRPMS/kernel-2.6.15-1.2054_FC5.src.rpm # rpm -ivh kernel-2.6.15-1.2054_FC5.src.rpm 2. I coded a patch to reverse Andrea's ptrace patch. Copy this file to /usr/src/redhat/SOURCES: [root@woodzltc SOURCES]# cat linux-2.6-strace-clone-exec.patch diff -Nru -p linux-2.6.15.ppc64/kernel/ptrace.c linux-2.6.15.wz/kernel/ptrace.c --- linux-2.6.15.ppc64/kernel/ptrace.c 2006-03-30 06:38:38.000000000 +0800 +++ linux-2.6.15.wz/kernel/ptrace.c 2006-03-30 06:46:36.000000000 +0800 @@ -57,10 +57,6 @@ void ptrace_untrace(task_t *child) signal_wake_up(child, 1); } } - if (child->signal->flags & SIGNAL_GROUP_EXIT) { - sigaddset(&child->pending.signal, SIGKILL); - signal_wake_up(child, 1); - } spin_unlock(&child->sighand->siglock); } @@ -82,7 +78,8 @@ void __ptrace_unlink(task_t *child) SET_LINKS(child); } - ptrace_untrace(child); + if (child->state == TASK_TRACED) + ptrace_untrace(child); } /* diff -Nru -p linux-2.6.15.ppc64/kernel/signal.c linux-2.6.15.wz/kernel/signal.c --- linux-2.6.15.ppc64/kernel/signal.c 2006-03-30 06:38:44.000000000 +0800 +++ linux-2.6.15.wz/kernel/signal.c 2006-03-30 06:48:59.000000000 +0800 @@ -1143,8 +1143,8 @@ void zap_other_threads(struct task_struc if (t != p->group_leader) t->exit_signal = -1; - /* SIGKILL will be handled before any pending SIGSTOP */ sigaddset(&t->pending.signal, SIGKILL); + rm_from_queue(SIG_KERNEL_STOP_MASK, &t->pending); signal_wake_up(t, 1); } } @@ -1979,9 +1979,9 @@ relock: /* Let the debugger run. */ ptrace_stop(signr, signr, info); - /* We're back. Did the debugger cancel the sig or group_exit? */ + /* We're back. Did the debugger cancel the sig? */ signr = current->exit_code; - if (signr == 0 || current->signal->flags & SIGNAL_GROUP_EXIT) + if (signr == 0) continue; current->exit_code = 0; 3. Apply this patch to /usr/src/redhat/SPECS/kernel-2.6.spec [root@woodzltc SPECS]# cat spec.patch --- ./kernel-2.6.spec 2006-03-15 04:41:50.000000000 +0800 +++ ./kernel-2.6-wz.spec 2006-03-30 15:58:40.000000000 +0800 @@ -292,6 +292,9 @@ Patch905: linux-2.6-modsign-include.patc # Tux http accelerator. Patch910: linux-2.6-tux.patch +# A temporary patch for Frysk project +Patch920: linux-2.6-strace-clone-exec.patch + # # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems # @@ -868,6 +871,9 @@ find -name "*.p.xen" | xargs rm -f # Tux %patch910 -p1 +# Frysk +%patch920 -p1 + # SATA Patches # Enable PATA ports on Promise. %patch2200 -p1 4. Use rpmbuild to build the kernel [root@woodzltc SPECS]# rpmbuild -ba kernel-2.6.spec After some times , you will get some binary rpm package in RPMS/{i586,i686,ppc64}/, and also a source rpm package in SRPMS/. (on x86, it will assume your target defaultly as i686. Under this configuration, it will try to build up, smp, xen, maybe some other kernel packages, which is very slow. One my laptop, it is more than six hours. You can specify target as i586 to speedup this a little. Like this: # rpmbuild -ba --target i586 kernel-2.6.spec ) 5. just install the resulting binray rpm package, it will auto-install the kernel and change the boot configuration file for you. [root@woodzltc redhat]# rpm -ivh RPMS/i586/kernel-2.6.15-1.2054_FC5.root.i586.rpm And then reboot, you will get into the new kernel. The above process is what I used. you can also use my resulting source rpm package to work-around the patching process (step 2 and step 3). If anyone would like to try this method, I can post my resulting source rpm package somewhere. BTW. Andrew, I am not very sure what you mean by saying "cheat sheet". I guess it is a kind of howto document like the above. Any error, please correct me. Thanx - Wu Zhou On Thu, 30 Mar 2006, Wu Zhou wrote: > On Wed, 29 Mar 2006, Andrew Cagney wrote: > > > Hello, > > > > Now that FC-5 (which includes the much improved GCC 4.1 along with many other > > good things) is released, it is probably time to switch any remaining focus > > away from FC-4, to FC-5 and beyond. > > > > With that in mind, FC-5 has one known problem: The strace-clone-exec test > > failure. Would anyone have a cheat sheet on how to build a Linux kernel with > > the relevant change removed? > > I will try to work out one with the FC-5 shipped kernel. I was originally > working with 2.6.15 kernel. > > Thanx > - Wu Zhou > From swagiaal@redhat.com Fri Mar 31 14:58:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 31 Mar 2006 14:58:00 -0000 Subject: Souce and Monitor Window Integration Message-ID: <442D4323.9030207@redhat.com> Prompted by the feed back from the Toronto meetings, I had some ideas about how to better integrate the source window and to monitor. To reflect the fact that they are two views of the same underlying model, and to make the tool more strongly suggest it self as useful to the user. Phil Muldoon, Adam, and I had a little brainstorm and flushed out these ideas. I have attached some some white board pictures that Adam, and I drew out. The central idea is that Monitor and Source are two views of the same object. So our goal is to make the switch between the two more obvious, and to provide the user with an "abbreviated" view of the the other mode. So, (a) a view of you current session (process/thread tree) stays with you in both modes, and your tool-bar and menu stay the same. (b) When you are in Source mode you are still able to see the time-lines in the bottom of you window, and when you are in Monitor mode, you can still see you stack and watch variables in the bottom of your window. For refactors like this we have to keep in mind that each "widget" or component stays independent of others, and communicate through event passing. This way the gui is completely refactorable to the extend of allowing the user to choose any combination of views they want (not that I am suggesting that ;) ) Please let us your comments :) -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0165.JPG Type: image/jpeg Size: 1080177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0166.JPG Type: image/jpeg Size: 1092047 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0167.JPG Type: image/jpeg Size: 1073873 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0168.JPG Type: image/jpeg Size: 1080975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0169.JPG Type: image/jpeg Size: 1063589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0170.JPG Type: image/jpeg Size: 1098222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0171.JPG Type: image/jpeg Size: 1131422 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0172.JPG Type: image/jpeg Size: 1116450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0173.JPG Type: image/jpeg Size: 1107743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0174.JPG Type: image/jpeg Size: 1119401 bytes Desc: not available URL: From swagiaal@redhat.com Fri Mar 31 15:57:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 31 Mar 2006 15:57:00 -0000 Subject: Souce and Monitor Window Integration In-Reply-To: <442D4323.9030207@redhat.com> References: <442D4323.9030207@redhat.com> Message-ID: <442D5155.9080806@redhat.com> Here is shrunk version of the images -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0165.JPG Type: image/jpeg Size: 70063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0166.JPG Type: image/jpeg Size: 76160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0167.JPG Type: image/jpeg Size: 71939 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0168.JPG Type: image/jpeg Size: 73889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0169.JPG Type: image/jpeg Size: 67886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0170.JPG Type: image/jpeg Size: 61442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0171.JPG Type: image/jpeg Size: 71255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0172.JPG Type: image/jpeg Size: 69104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0173.JPG Type: image/jpeg Size: 65826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0174.JPG Type: image/jpeg Size: 71774 bytes Desc: not available URL: From roland@redhat.com Fri Mar 31 20:53:00 2006 From: roland@redhat.com (Roland McGrath) Date: Fri, 31 Mar 2006 20:53:00 -0000 Subject: Souce and Monitor Window Integration In-Reply-To: Sami Wagiaalla's message of Friday, 31 March 2006 09:56:35 -0500 <442D4323.9030207@redhat.com> Message-ID: <20060331205302.E1CE61809CC@magilla.sf.frob.com> Please for the love of God no more 15MB eamil emssages. Put the images on sourceware or people.redhat.com or someplace and post links. From swagiaal@redhat.com Fri Mar 31 21:15:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 31 Mar 2006 21:15:00 -0000 Subject: Souce and Monitor Window Integration In-Reply-To: <20060331205302.E1CE61809CC@magilla.sf.frob.com> References: <20060331205302.E1CE61809CC@magilla.sf.frob.com> Message-ID: <442D9C09.6080900@redhat.com> Roland McGrath wrote: > Please for the love of God no more 15MB eamil emssages. > Put the images on sourceware or people.redhat.com or someplace and post links. > oops... sorry :D