[drlvm] current tests - can we focus on getting everything to pass?
Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 -Mark. On 28 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test]Deal with un-deleted temp files created in tests
Jimmy, Jing Lv 写道: Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that Note zfile is a user-defined zip file used by other tests and should not be deleted, it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory org\apache\harmony\jndi\tests\javax\naming\spi with a file jndiprovider.properties and a sub directory mock. This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! Put them in places where are appropriate according to various guide lines. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
I followed your suggestions below and made everything build in debug mode. Now I can put a break in main.c. Thanks. Also, now I also see debug information when I try to run helloworld. Perhaps this debugging information is useful. [EMAIL PROTECTED] /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804B410 Handler2=B7EEFE46 InaccessibleAddress=0004 EDI=080A87E0 ESI= EAX= EBX=B7F17FD4 ECX= EDX= EIP=B7F0AD94 ES=C010007B DS=007B ESP=BFE5194C EFlags=00210246 CS=0073 SS=007B EBP=BFE51A68 Module=/lib/ld-linux.so.2 Module_base_address=B7F02000 Aborted So now that I can put break points, I tried to follow the code in gdb to see where it was hanging. In gdb I get to line 1102 in main.c, which is the addDirsToPath method, execv (exeName, argv). I think that I remember this being discussed before. I believe gdb is unable to deal with this call to execv. So, I don't think this is what is making the VM hang, and now I am unable to follow the execution of java helloworld any further. Is there a way around this? Here is the gdb results: (gdb) b main.c:315 Breakpoint 1 at 0x8048e6f: file main.c, line 315. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9192)] [New Thread 32769 (LWP 9195)] [New Thread 16386 (LWP 9196)] [Switching to Thread 16384 (LWP 9192)] Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315 315 rc = addDirsToPath(PORTLIB, 2, dirs, argv); (gdb) s addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1015 1015 char *oldPath = NULL; (gdb) b 1102 Breakpoint 2 at 0x804a7aa: file main.c, line 1102. (gdb) c Continuing. Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102 1102 execv (exeName, argv); Oops, some day I made everything build in debug mode locally. And forgot about it. Currently there is no option for that. TBD, obviously. I do it with the patch (linux only) like this: ... No problem. I'm glad it's helpful. I was beginning to worry that I was just getting annoying :). Thanks for the help, Armand Thank you for digging into it. That's really valuable. I hope we will fix the issue soon. Thanks, Armand Egor Pasko wrote: I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with future shared library load). Try my above suggestion, please. GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to
Re: [drlvm] [launcher] Executable hangs
yes - add the bin directory and the default directory to your LD_LIBRARY_PATH - the launcher will decide that it doesn't need to do the execv() and will skip it... geir On Sep 28, 2006, at 2:31 AM, Armand Navabi wrote: I followed your suggestions below and made everything build in debug mode. Now I can put a break in main.c. Thanks. Also, now I also see debug information when I try to run helloworld. Perhaps this debugging information is useful. [EMAIL PROTECTED] /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804B410 Handler2=B7EEFE46 InaccessibleAddress=0004 EDI=080A87E0 ESI= EAX= EBX=B7F17FD4 ECX= EDX= EIP=B7F0AD94 ES=C010007B DS=007B ESP=BFE5194C EFlags=00210246 CS=0073 SS=007B EBP=BFE51A68 Module=/lib/ld-linux.so.2 Module_base_address=B7F02000 Aborted So now that I can put break points, I tried to follow the code in gdb to see where it was hanging. In gdb I get to line 1102 in main.c, which is the addDirsToPath method, execv (exeName, argv). I think that I remember this being discussed before. I believe gdb is unable to deal with this call to execv. So, I don't think this is what is making the VM hang, and now I am unable to follow the execution of java helloworld any further. Is there a way around this? Here is the gdb results: (gdb) b main.c:315 Breakpoint 1 at 0x8048e6f: file main.c, line 315. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9192)] [New Thread 32769 (LWP 9195)] [New Thread 16386 (LWP 9196)] [Switching to Thread 16384 (LWP 9192)] Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315 315 rc = addDirsToPath(PORTLIB, 2, dirs, argv); (gdb) s addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1015 1015 char *oldPath = NULL; (gdb) b 1102 Breakpoint 2 at 0x804a7aa: file main.c, line 1102. (gdb) c Continuing. Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102 1102 execv (exeName, argv); Oops, some day I made everything build in debug mode locally. And forgot about it. Currently there is no option for that. TBD, obviously. I do it with the patch (linux only) like this: ... No problem. I'm glad it's helpful. I was beginning to worry that I was just getting annoying :). Thanks for the help, Armand Thank you for digging into it. That's really valuable. I hope we will fix the issue soon. Thanks, Armand Egor Pasko wrote: I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put somewhere in ~/.gdbinit, two scripts are better: first for initial run, the second script does the same but reusing old breakpoint numbers: dis en 1 r dis en 2 c dis I should put that into the FAQ, obviously. And then when I run the program it never stops at the breakpoint, though I see the print I have inserted in the code. Secondly, and more importantly, if I try to do anything interesting, like run helloworld, gdb seems to lose a thread and then hang (says it Cannot find a thread. Invalid thread handle). I have to then stop it and go kill it. this one is probably a separate issue (not connected with future shared library load). Try my above suggestion, please. GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/ bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11007)] [New Thread 32769 (LWP 11010)] [New Thread 16386 (LWP 11011)] Cannot find thread 32769: invalid thread handle (gdb) q The program is running. Exit anyway? (y or n) y [1]+ Stopped gdb ./java Thanks, Armand On the 0x1F0 day of Apache Harmony Armand Navabi wrote: When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb
Re: [doc] new Getting Started guides
On 9/28/06, Geir Magnusson Jr. wrote: On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: t is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. Yes, I remember that and I wanted to share my view what the fastest way is. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. Good point. But what other components right now would you point to? A structure can be - Classlib . = pointers to subcomponents - Tools . = pointers to subcomponents -VM . = pointers to subcomponents BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. Sometimes it is hard to swallow a whole pile. J2SE implementation is a big pile. I don't see anything wrong here why not to suggest the newbie to try a piece of the pile. For example, what the problem with releasing 'keytool' or 'beans framework'? Why these parts should wait until we complete full toolset of classlib? I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having subprojects that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. IMHO, we unintentionally pushed idea of independency components to project's backyard. I think this is not good. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... Yes, high mail traffic might be a problem it constantly grows. And subject's line definitely helps now but I'm not sure about future. Also some parts of the project are indeed independent. For example, it may be possible to take some framework from classlib, say logging framework, and try it with another JRE. And the framework should work. This is true independence. So it seems more natural for me to create a sub-project for the framework to let it be more attractive for users: has less bugs, is faster, follows the spec. and so on. Why not? Thanks, Stepan. As for homepages, we already have that - basic pages for each major component. geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 from me. -- Ivan Intel Middleware Products Division On 28 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test]Deal with un-deleted temp files created in tests
Sounds reasonable. And do not forget about great method File.removeOnExit(). SY, Alexey 2006/9/28, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that Note zfile is a user-defined zip file used by other tests and should not be deleted, it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory org\apache\harmony\jndi\tests\javax\naming\spi with a file jndiprovider.properties and a sub directory mock. This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] [launcher] Executable hangs
That did not fix it for me. I thought I had both the bin directory and the default directory in my LD_LIBRARY_PATH. I just ran it again to make sure, and it still seems to get lost on execv(). Is there something special I need to call in gdb to skip it? GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) b main.c:1102 Breakpoint 1 at 0x804a7aa: file main.c, line 1102. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9882)] [New Thread 32769 (LWP 9885)] [New Thread 16386 (LWP 9886)] [Switching to Thread 16384 (LWP 9882)] Breakpoint 1, addDirsToPath (portLibrary=0xbfb29920, count=2, newPathToAdd=0xbfb29728, argv=0xbfb29d14) at main.c:1102 1102 execv (exeName, argv); (gdb) n Cannot find user-level thread for LWP 9882: generic error -- HAD TO Cntrl^c (gdb) show environment ... LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre /bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/defau lt/ ... JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre ... Armand -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 2:39 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [launcher] Executable hangs yes - add the bin directory and the default directory to your LD_LIBRARY_PATH - the launcher will decide that it doesn't need to do the execv() and will skip it... geir On Sep 28, 2006, at 2:31 AM, Armand Navabi wrote: I followed your suggestions below and made everything build in debug mode. Now I can put a break in main.c. Thanks. Also, now I also see debug information when I try to run helloworld. Perhaps this debugging information is useful. [EMAIL PROTECTED] /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ ./java helloworld An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804B410 Handler2=B7EEFE46 InaccessibleAddress=0004 EDI=080A87E0 ESI= EAX= EBX=B7F17FD4 ECX= EDX= EIP=B7F0AD94 ES=C010007B DS=007B ESP=BFE5194C EFlags=00210246 CS=0073 SS=007B EBP=BFE51A68 Module=/lib/ld-linux.so.2 Module_base_address=B7F02000 Aborted So now that I can put break points, I tried to follow the code in gdb to see where it was hanging. In gdb I get to line 1102 in main.c, which is the addDirsToPath method, execv (exeName, argv). I think that I remember this being discussed before. I believe gdb is unable to deal with this call to execv. So, I don't think this is what is making the VM hang, and now I am unable to follow the execution of java helloworld any further. Is there a way around this? Here is the gdb results: (gdb) b main.c:315 Breakpoint 1 at 0x8048e6f: file main.c, line 315. (gdb) r helloworld Starting program: /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java helloworld [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 9192)] [New Thread 32769 (LWP 9195)] [New Thread 16386 (LWP 9196)] [Switching to Thread 16384 (LWP 9192)] Breakpoint 1, gpProtectedMain (args=0xbfc3df90) at main.c:315 315 rc = addDirsToPath(PORTLIB, 2, dirs, argv); (gdb) s addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1015 1015 char *oldPath = NULL; (gdb) b 1102 Breakpoint 2 at 0x804a7aa: file main.c, line 1102. (gdb) c Continuing. Breakpoint 2, addDirsToPath (portLibrary=0xbfc3dfb0, count=2, newPathToAdd=0xbfc3ddb8, argv=0xbfc3e3a4) at main.c:1102 1102 execv (exeName, argv); Oops, some day I made everything build in debug mode locally. And forgot about it. Currently there is no option for that. TBD, obviously. I do it with the patch (linux only) like this: ... No problem. I'm glad it's helpful. I was beginning to worry that I was just getting annoying :). Thanks for the help, Armand Thank you for digging into it. That's really valuable. I hope we will fix the issue soon. Thanks, Armand Egor Pasko wrote: I solve this by breaking inside launcher after VM lib is loaded, then I break somewhere after libjitrino.so is loaded. Then I can break anywhere :) looks like this: break main.c:360 r dis break compile_jit_a_method c dis break whatever function you want You can make it a script via GDB's 'define' and put
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test]Deal with un-deleted temp files created in tests
Jimmy, Jing Lv 写道: Jimmy, Jing Lv wrote: Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that Note zfile is a user-defined zip file used by other tests and should not be deleted, it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory org\apache\harmony\jndi\tests\javax\naming\spi with a file jndiprovider.properties and a sub directory mock. This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! If no objection, I'll raise JIRAs and fix them. That would be great, go ahead. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 2006/9/28, Ivan Volosyuk [EMAIL PROTECTED]: +1 from me. -- Ivan Intel Middleware Products Division On 28 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
+1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
Looks like a progress :) On the 0x1F2 day of Apache Harmony Armand Navabi wrote: That did not fix it for me. I thought I had both the bin directory and the default directory in my LD_LIBRARY_PATH. I just ran it again to make sure, and it still seems to get lost on execv(). Is there something special I need to call in gdb to skip it? you can always jump in GDB. And I love this feature. Now that should be easy enuough to debug out why the launcher does not see the LD_LIBRARY_PATH and tries to execv. Geir says, it should NOT execv. This is the bug. Seems like an easy one. does main.c:1037 (oldPath = getenv (variableName);) work for you? BTW, I remember having to set HYLD_LIBRARY_PATH on OSX. I was very surprized)) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] fail statements omitted in many exception catching test cases
Thanks Richard.
I've looked at luni module and raised HARMONY-1618 about some bugs of those
kind.
On 9/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at
[1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
--
Robert Hu
China Software Development Lab, IBM
[classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. -- Leo Li China Software Development Lab, IBM
Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][drlvm][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Paulex, I agree to your suggestions on keeping the config files for generated docs only. As for And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. I fully side with that. Moreover, I'd suggest that we add such a target for DRLVM sources as well. JIRAs start to appear with comments brushup for Doxygen needs (eg. JIRA 1544), so why not do it. Best regards, Nadya Morozova -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 12:31 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository. Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
Weldon Washburn wrote:
On 9/26/06, Leo Li [EMAIL PROTECTED] wrote:
Hi, Weldon:
The usage of the argument of portLibrary is for the function to call
other functions of the port library if needed. The argument is just a
virtual function table, as you said, can be any implemenatation of the
HyPortLibrary struct, not only the HyPortLibrary struct the function
belongs
to. Of course, different HyPortLibrary might lead to different
behavior of
the function if the HyPortLibrary is used by it.
I think the main purpose of the design is to alter some function
of a
specified HyPortLibrary struct flexibly, especially at runtime: What is
necessary to do is just to change an entry in HyPortLibrary while the
altered function can make use of other functions as well as other
functions
can use it.
Am I all right?:)
Hmmm... Interesting idea you have. Basically the idea is to rewrite the
virtual function table _before_ any of the functions are used. This
makes
much more sense than the way drlvm currently boots up. By the way, is
there
any documentation that says what you are suggesting? In other words, was
portlib specifically designed to do what you suggest?
I think so, here below the part of portlib document at {harmony svn
root}/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
The port library is implemented as a table of function pointers. One
advantage of a function pointer based table is the ability to replace
any functionality without recompiling the entire Java virtual machine.
For example if an application is experiencing a memory leak, the memory
management functions of the port library can be replaced to help
determine the root cause of this leak. Alternatively applications
wishing to control all memory allocation can provide their own routines
to override the platform specific allocation and deallocation of memory.
Various implementations of the port library may choose not to implement
all functionality contained in the port library table. If a platform
does not support sockets, and thus the Java virtual machine does not
utilize sockets, the port library does not need to provide a valid
socket behavior. The port library contains version control information
cid:part1.01000201.01070009@gmail.com that enables applications to
determine if required functionality is supported. In addition the
version control information allows applications to determine if the port
library provided is compatible with the one which they were compiled
against.
On 9/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
It looks like hysignal.c is using the right monitor enter/exit().
That
is,
the one
from drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll
However, a bunch of functions in classlib's hysignal.c have an
incoming
argument of HyPortLibrary *portlib. The portlib variable can either
point
to the original classlib portlib C struct. Or it can point to PORTLIB
which
is a C struct with all the entries nulled out (more on this later.)
I think the next question to ask is what hysignal.c does with
the HyPortLibrary *portlib argument. If anyone knows, please
tell us.
Otherwise I will keep digging.
From stepping through DRLVM bootup, it looks like classlib's
portlib is
_dropped_ in signalProtectMain(). Then launcher gpProtectedMain
calls
invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C
struct. We need to put comments in the code describing the switch
from
classlib's portlib to drlvm's nulled out version.
On 9/22/06, Weldon Washburn [EMAIL PROTECTED] wrote:
All,
Its not clear at this moment what threading implementation is being
executed when hysignal.c calls hythread_monitor_enter(). If someone
already knows, please tell us. Otherwise, I will step through it
with
the
debugger to find out what is going on.
- Weldon
--
Weldon Washburn
Intel Middleware Products Division
--
Weldon Washburn
Intel Middleware Products Division
--
Leo Li
China Software Development Lab, IBM
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
Good point. +1 from me. SY, Alexey 2006/9/27, Alexei Zakharov [EMAIL PROTECTED]: If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) then we definitely need to supply jar with tests. We may also supply the build file with placeholders for user classes tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov [EMAIL PROTECTED]: On 9/27/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: If I recall, the point of the test.jar was to have a pre-built jar of tests in the HDK so that someone could setup the build-test infra using the HDK so they could run tests on their platform w/o having to build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would have to be configured to have the classlib test target use that jar. All I'm saying is that how we do this is important, as we don't want to cause pain for classlib developers who use the HDK for development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir geir Thanks, Vladimir Thanks, Vladimir geir Thanks, Vladimir On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: They are at the regular place http://people.apache.org/dist/incubator/harmony/snapshots I moved all the old classlib snapshots into /old and I'll update the website accordingly. I'll be automating this. Also, lets not make much noise about this for a little while so we can test to make sure there's no major errors. Things seem good. I have a list of more things to fix, but I realized today that I was obsessing over the snapshot contents - it's not a release, and it's good enough. I'd like to ditch both /old and the remaining classlib snapshots, as 1) they are snapshots - history doesn't matter 2) the classlib is now in the HDK, so we just need to adjust the docs to match. I'll do the latter, but wanted to see if anyone has a problem w/ me removing /old and the last classlib snapshot. I'll do this if I don't hear any protest, so either positively acknowledge this action if you support it, dont' do a thing if you support or dont' care, or say why we shouldn't :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build-test-infra] Build Test Infrastructure
Anton, I'm looking at http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=2 jira=0 http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=3 jira=0 I see 5 errors and 14 failures. I just want to double check that we have less than 20 problems with running unit tests on DRLVM. Is it correct statement or some failures are missed? With best regards, Alexei Fedotov, Intel Middleware Products Division BTW, I have a small request for enhancement: the following request hides search options by the right margin of my screen. I would suggest reordering table rows in a way fixed width fields go first. http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=1 jira=0 -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 7:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure I think we'd want this to be registered user can add user Done. I'm still the only person with login - send me your login/password to register. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
This has been a problem for some time - I recall commenting out the call to an ant target that cleaned that svn-checked out documentation. If we are going to remove them, then I think we need to add them to the website and ensure we update them regularly. (So that they exist in a form we can link to - I recall seeing links to the versions in svn in the past.) Regards, Mark. On 28 September 2006 at 16:30, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Do you think we can have the docs built on a regular basis (like, a script that triggers Doxygen build say 2 times a week + on demand to push updates if needed) and resulting docs stored on the website? This way, you don't have SVN versioning for auto-generated content and keep info available for all. Best regards, Nadya Morozova -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 1:08 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository. This has been a problem for some time - I recall commenting out the call to an ant target that cleaned that svn-checked out documentation. If we are going to remove them, then I think we need to add them to the website and ensure we update them regularly. (So that they exist in a form we can link to - I recall seeing links to the versions in svn in the past.) Regards, Mark. On 28 September 2006 at 16:30, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
May be we start from failed test exclusion to run CC over these tests and will enable these tests one by one? Now, the CC is useless for drlvm due to known stable failures. Thanks, Vladimir On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Trying to catch patternset errors earlier
Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail, it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ProviderService.class I'm sure there are other ways to solve this problem but this seemed like a sensible quick fix to help catch these problems a little sooner[1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
2006/9/28, Vladimir Ivanov [EMAIL PROTECTED]: May be we start from failed test exclusion to run CC over these tests and will enable these tests one by one? Now, the CC is useless for drlvm due to known stable failures. I'm afraid CC is useless for flickering failures as well. Thanks, Vladimir On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Alexei, VM hanged in the process of test execution - I killed it and tests proceeded - I'm not sure whether this crash is recorded as error or those tests are not included in the report. The report on site is the similar to the one I see in my local test_result/html report . On 9/28/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Anton, I'm looking at http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=2 jira=0 http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=3 jira=0 I see 5 errors and 14 failures. I just want to double check that we have less than 20 problems with running unit tests on DRLVM. Is it correct statement or some failures are missed? With best regards, Alexei Fedotov, Intel Middleware Products Division BTW, I have a small request for enhancement: the following request hides search options by the right margin of my screen. I would suggest reordering table rows in a way fixed width fields go first. http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=1 jira=0 -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 7:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure I think we'd want this to be registered user can add user Done. I'm still the only person with login - send me your login/password to register. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
Sounds reasonable. The alternative is to not make clean fail, just print the warning and tidy up the remainder. That may be too easy to ignore though. Regards, Tim Mark Hindess wrote: Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail, it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ProviderService.class I'm sure there are other ways to solve this problem but this seemed like a sensible quick fix to help catch these problems a little sooner[1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Yep, the current situation is an artifact from way back -- I agree the doc should be generated into the website are now. Regards, Tim Mark Hindess wrote: This has been a problem for some time - I recall commenting out the call to an ant target that cleaned that svn-checked out documentation. If we are going to remove them, then I think we need to add them to the website and ensure we update them regularly. (So that they exist in a form we can link to - I recall seeing links to the versions in svn in the past.) Regards, Mark. On 28 September 2006 at 16:30, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm] IBM VME related issues
Thanks for pointing them out Alexey. Alexey Varlamov wrote: Here is the list of JIRA issues which should not slip attention of IBM engineers: HARMONY-1596 HARMONY-1309 HARMONY-813 These are just the ones I'm aware of, please extend this list if you know some :) -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrote: Sounds reasonable. The alternative is to not make clean fail, just print the warning and tidy up the remainder. That may be too easy to ignore though. Yes. I considered that and had the same concern. Even if I wrote the code to print the warning, I think I'd ignore it since it would scroll too quickly off the top of my screen at the beginning of the build. -Mark. Regards, Tim Mark Hindess wrote: Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail, it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ProviderService.cl ass I'm sure there are other ways to solve this problem but this seemed like a sensible quick fix to help catch these problems a little sooner[1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: +1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
I think that it will be better to add another target to build for this check. Because of two reasons: 1. It is unclear that clean is also checks something 2. If it will fail and leave some files in build dirs how should I clean the repository? 2006/9/28, Mark Hindess [EMAIL PROTECTED]: On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrote: Sounds reasonable. The alternative is to not make clean fail, just print the warning and tidy up the remainder. That may be too easy to ignore though. Yes. I considered that and had the same concern. Even if I wrote the code to print the warning, I think I'd ignore it since it would scroll too quickly off the top of my screen at the beginning of the build. -Mark. Regards, Tim Mark Hindess wrote: Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail, it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ProviderService.cl ass I'm sure there are other ways to solve this problem but this seemed like a sensible quick fix to help catch these problems a little sooner[1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
According to our Compatibility Guidelines
...There are a few occasions where both the specification is quiet on
a given issue, and the RI exhibits behaviour that we would consider
illogical. In such cases we discuss the issue on the Harmony
developers' mailing list, and code the class libraries to do what the
development community conclude is the logical thing...
So we have 1 vote for non-bug and 1 vote for bug.
2006/9/28, Richard Liang [EMAIL PROTECTED]:
On 9/27/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our Compatibility Guidelines[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[],
int, int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of
points to transform is zero. Harmony doesn't throw any exception. Spec doesn't say
about any exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation
doesn't use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Re: [drlvm] current tests - can we focus on getting everything to pass?
On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's ThreadTest is a kind of always failing test unfortunately. Now its failure is related to launcher related issue mentioned in another thread as well as the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch. On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new problems possibly related to H-1519 patch. So ThreadTest is very helpful in catching regressions and should be paid a special attention to each time it fails :) As for general statistics of kernel test failures, ThreadTest fails now on all platforms in all modes (jet, opt, int) and ClassLoaderTest and ClassAnnotationTest fail on opt (win, linux), which is under Egor's investigation. Thanks, Elena org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
The issue has gone away for me too, false alarm possibly... Elena On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote: I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky [EMAIL PROTECTED]: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: sob :) Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy -- Thanks, Elena
Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
Morozova, Nadezhda wrote: Do you think we can have the docs built on a regular basis (like, a script that triggers Doxygen build say 2 times a week + on demand to push updates if needed) and resulting docs stored on the website? This way, you don't have SVN versioning for auto-generated content and keep info available for all. May need to keep it a manual update for now since we have no scripts that update the website regularly. These Doxygen docs describe APIs so hopefully they are not changing regularly (at least, not twice a week). Regards, Tim -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 1:08 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository. This has been a problem for some time - I recall commenting out the call to an ant target that cleaned that svn-checked out documentation. If we are going to remove them, then I think we need to add them to the website and ensure we update them regularly. (So that they exist in a form we can link to - I recall seeing links to the versions in svn in the past.) Regards, Mark. On 28 September 2006 at 16:30, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Japi diffs for harmony
org.omg packages looks much better after applying latest Yoko. javax.rmi looks much better too! :) http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html Thanks, Stuart, for these regular comparison updates! SY, Alexey 2006/9/28, Stuart Ballard [EMAIL PROTECTED]: Japi diff jdk12 vs harmony: Full results: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony.html -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
On the 0x1F2 day of Apache Harmony Elena Semukhina wrote: On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's ThreadTest is a kind of always failing test unfortunately. Now its failure is related to launcher related issue mentioned in another thread as well as the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch. On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new problems possibly related to H-1519 patch. So ThreadTest is very helpful in catching regressions and should be paid a special attention to each time it fails :) As for general statistics of kernel test failures, ThreadTest fails now on all platforms in all modes (jet, opt, int) and ClassLoaderTest and ClassAnnotationTest fail on opt (win, linux), which is under Egor's investigation. ClassLoaderTest, to be precise.. ClassAnnotatationsTest passes for me on linux Thanks, Elena org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
2006/9/28, Mark Hindess [EMAIL PROTECTED]: On 28 September 2006 at 14:30, Alexey Petrenko [EMAIL PROTECTED] wrote: I think that it will be better to add another target to build for this check. Because of two reasons: 1. It is unclear that clean is also checks something This simple check can only happen part way through the clean target - after the modules have done their cleaning and before the top-level cleanup is done. I see your point. But let's review the sitatuation from another viewpoint... What do we need in general? We need up-to-date list of all packages in the specified module. Right? If so we can create simple script to update patternset files... Or even create them at build time. But will cost us build time itself :) 2. If it will fail and leave some files in build dirs how should I clean the repository? I've fixed the clean target so that it always completes the cleaning process even if it fails. Thanks. SY, Alexey 2006/9/28, Mark Hindess [EMAIL PROTECTED]: On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrote: Sounds reasonable. The alternative is to not make clean fail, just print the warning and tidy up the remainder. That may be too easy to ignore though. Yes. I considered that and had the same concern. Even if I wrote the code to print the warning, I think I'd ignore it since it would scroll too quickly off the top of my screen at the beginning of the build. -Mark. Regards, Tim Mark Hindess wrote: Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail , it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ProviderServic e.cl ass I'm sure there are other ways to solve this problem but this seemed lik e a sensible quick fix to help catch these problems a little sooner[1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
+1 for the website. I agree with Mark that the changes to this document shoud be discussed first. On 9/28/06, Mark Hindess [EMAIL PROTECTED] wrote: I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: [general] svn:eol-style = native (LF vs CRLF)
I've just faced the same problem with the *.def files. All these files has CRLF endings even on Linux. It results in rejecting the patch which applies OK on Windows... SY, Alexey 2006/9/14, Geir Magnusson Jr. [EMAIL PROTECTED]: I thought we did this a while ago...? geir Tony Wu wrote: +1 to set *svn:eol-style native* to all text files On 9/14/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: After going through this thread, I realize there is another possibility to encounter the problem even you are working on single platform, 1.the file you are working on does not have eol-style property and the latest commit is performed on Unix system. 2.you create a patch. 3.when applying the patch, your patch-apply tool consider it is on win32 system and convert all the LF to CRLF. 4.your local copy is dos style and the remote copy is unix style so you get totally different files when compare the bytes. Tony, thanks, it is exactly the case I've described in my post. I also thought that the reason was the svn:eol-style property for certain files or my local svn settings. Also I was wondering if the idea suggested in this thread was already applied for all modules (and security module was just missed), or it is in progress now. I think it is a good idea to set this property for all .java files in modules at once. Regards, Ilya. I have no idea wyh some of the .java files have the property but others doesnt in the meanwhile. hope it will do some help. On 9/13/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 8/17/06, Tim Ellison [EMAIL PROTECTED] wrote: Sure -- just blat them all in one go. Regards, Tim Nathan Beyer wrote: Does anyone have objections to setting the svn:eol-style to native for *.java, *.c, *.h, *.cpp, *.xml as we move forward with updates and changes? I believe this is the suggested setting for committers [1][2]. The only file types that I know of that must have a specific line ending are *.dsp and *.dsw, which must be CRLF. Some files are already set this way and others are not, but if we go about updating these as we move forward, this should normalize checkouts for everyone. Hi to all! Is anything done on this issue? I found some classes in [security] module has different eol style even within one package. When I make a patch for these classes, apply it (on Windows) - I find, that classes, that were in svn reporitory with 'unix' eol now have 'dos' eol. Thus if I make diff again - it shows me, that some files are to be fully rewrited with 'dos' eol, and I can't see the differences I've made. Probably I've missed something with svn settings or smth else? Thanks, Ilya. -Nathan Beyer [1] http://www.apache.org/dev/version-control.html#https-svn [2] http://www.apache.org/dev/svn-eol-style.txt -- Tim Ellison ([EMAIL PROTECTED] ) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division -- Tony Wu China Software Development Lab, IBM -- -- Ilya Okomin Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
On the 0x1F2 day of Apache Harmony Alexey Varlamov wrote: 28 Sep 2006 17:50:57 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Elena Semukhina wrote: On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's ThreadTest is a kind of always failing test unfortunately. Now its failure is related to launcher related issue mentioned in another thread as well as the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch. On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new problems possibly related to H-1519 patch. So ThreadTest is very helpful in catching regressions and should be paid a special attention to each time it fails :) As for general statistics of kernel test failures, ThreadTest fails now on all platforms in all modes (jet, opt, int) and ClassLoaderTest and ClassAnnotationTest fail on opt (win, linux), which is under Egor's investigation. ClassLoaderTest, to be precise.. ClassAnnotatationsTest passes for me on linux It crashes sometimes (not very often) on OPT with the same trace as ClassLoaderTest which actually tells nothing... hmm.. ten times in a row it passed for me. If you reproduced the failure with memopt OFF, that would be valuable. If you cannot reproduce with memopt OFF, knowing that would be valuable too :) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
No arguments against web-site :) 2006/9/28, Oleg Khaschansky [EMAIL PROTECTED]: +1 for the website. I agree with Mark that the changes to this document shoud be discussed first. On 9/28/06, Mark Hindess [EMAIL PROTECTED] wrote: I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
+1 for the non-bug diff.
My opinion is that this boundary case is not going to affect any
application, especially because Harmony doesn't throw an exception
while RI does. Also, when the number of points is positive Harmony
still throws an exception if offset is out of bounds.
On 9/28/06, Denis Kishenko [EMAIL PROTECTED] wrote:
According to our Compatibility Guidelines
...There are a few occasions where both the specification is quiet on
a given issue, and the RI exhibits behaviour that we would consider
illogical. In such cases we discuss the issue on the Harmony
developers' mailing list, and code the class libraries to do what the
development community conclude is the logical thing...
So we have 1 vote for non-bug and 1 vote for bug.
2006/9/28, Richard Liang [EMAIL PROTECTED]:
On 9/27/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our Compatibility Guidelines[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[],
int, int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of points
to transform is zero. Harmony doesn't throw any exception. Spec doesn't say about any
exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation doesn't
use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Denis M. Kishenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Development Lab, IBM
Re: [drlvm] current tests - can we focus on getting everything to pass?
On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/9/28, Vladimir Ivanov [EMAIL PROTECTED]: May be we start from failed test exclusion to run CC over these tests and will enable these tests one by one? Now, the CC is useless for drlvm due to known stable failures. I'm afraid CC is useless for flickering failures as well. Yes, but at least CC may works as reminder for them. Thanks, Vladimir On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest and org.apache.harmony.luni.tests.java.lang.ThreadGroupTest. These are good candidates to fix first - especially Thread related - maybe this would help to get closer to more subtle defects. 28 Sep 2006 14:47:27 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Geir Magnusson, Jr. wrote: Right now, we have lots of tests that are skipped in smoke tests, and some that fail in kernel, and I believe that we're still failing the classlib test suite. We should drive this to goodness and health. How shall we start? :) I am working on the ClassLoaderTest :) memopt optimization pass makes it fail, it even removes some array-bounds-checks (surprize, surprize), which looks like, ehm, unfair. For now I could not reduce the test to a small one. On small pieces of code memopt works less dangerously. Disabling memopt helps, but that would drop performance down. You can disable it temporarily if stability is very critical. Just edit the opt.emconf file (and server.emconf, etc.) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][test] Test input/output files location
I am going to fix some commented tests from java.awt.geom package. I have several organizational questions before start to do. 1. Where is the best place to put test resource files (golden files)? Testing conventions [1] keep silence about this. There are many such files located near the tests, for example modules\awt\src\test\api\java\common\java\awt\geom\shapes\* modules\awt\src\test\api\java\common\java\awt\shapes\* 2. Where is the best place to put test output files? Now it is modules\awt\bin\test\java\awt\shapes\output modules\awt\bin\test\java\awt\geom\shapes\output [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] svnfind tool (was: Re: [classlib][test] fail statements omitted in many exception catching test cases)
Testing this script reminded me that I'd not mentioned the small script
I wrote after getting feed up typing:
find path -name .svn -prune -o ...
The script takes:
svnfind path [path2 ...] ...
and converts it to the previous form so that .svn directories are ignored.
Others might find it useful so I've included it below.
-Mark.
#!/bin/sh
while [ -n $1 ]; do
case $1 in
-*)
break
;;
*)
[EMAIL PROTECTED]$1
;;
esac
shift
done
while [ -n $1 ]; do
[EMAIL PROTECTED]$1
shift
done
if [ -z ${args[0]} ]; then
args[0]=-print
fi
exec find [EMAIL PROTECTED] -name .svn -prune -o [EMAIL PROTECTED]
On 27 September 2006 at 9:44, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~ /\bfail\s*\(/)
{
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases about exc
ep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the excepti
on
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases of our H
ar
mony classlib. So I set some rules to find out all lines of code related wi
th
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5 rules in
r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not of above
s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.jav
a:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTes
t.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\File
In
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\File
Ou
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind withou
t
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those bugs?
Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF
=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl
=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl
=
aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10
=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF
=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI
=
nputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback\ConfirmationCallba
=
ckTest.java:60\147
Re: [classlib][test] fail statements omitted in many exception catching test cases
Fixed.
Rui Hu wrote:
Thanks Richard.
I've looked at luni module and raised HARMONY-1618 about some bugs of those
kind.
On 9/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at
[1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
Yes, build script for JDWP agent should be aligned with the current classlib build structure. It should be easy, because it is generally oriented to the classlib structure and requires just a few changes. I can provide patch for this. I tried to build JDWP agent as a separate classlib component and it was built successfully with some known problems mentioned in README. Thanks. Ivan On 9/28/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: +1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: +1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
On 28 Sep 2006 18:25:58 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x1F2 day of Apache Harmony Alexey Varlamov wrote: 28 Sep 2006 17:50:57 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x1F2 day of Apache Harmony Elena Semukhina wrote: On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's ThreadTest is a kind of always failing test unfortunately. Now its failure is related to launcher related issue mentioned in another thread as well as the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch. On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new problems possibly related to H-1519 patch. So ThreadTest is very helpful in catching regressions and should be paid a special attention to each time it fails :) As for general statistics of kernel test failures, ThreadTest fails now on all platforms in all modes (jet, opt, int) and ClassLoaderTest and ClassAnnotationTest fail on opt (win, linux), which is under Egor's investigation. ClassLoaderTest, to be precise.. ClassAnnotatationsTest passes for me on linux It crashes sometimes (not very often) on OPT with the same trace as ClassLoaderTest which actually tells nothing... hmm.. ten times in a row it passed for me. If you reproduced the failure with memopt OFF, that would be valuable. If you cannot reproduce with memopt OFF, knowing that would be valuable too :) With memopt OFF, both tests pass on both linux and windows. -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena
Re: [doc] new Getting Started guides
On Sep 28, 2006, at 2:49 AM, Stepan Mishura wrote: On 9/28/06, Geir Magnusson Jr. wrote: On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: t is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. Yes, I remember that and I wanted to share my view what the fastest way is. Sure. We should put something to indicate the parts then. The federated checkout is nice because once you do it, you really do have two independent trees to work with, so you could simply just go into working_classlib and never come out :) We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. Good point. But what other components right now would you point to? A structure can be - Classlib . = pointers to subcomponents - Tools . = pointers to subcomponents -VM . = pointers to subcomponents Oh, I see - yeah indeed. BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. Sometimes it is hard to swallow a whole pile. J2SE implementation is a big pile. I don't see anything wrong here why not to suggest the newbie to try a piece of the pile. I see what you mean now. For example, what the problem with releasing 'keytool' or 'beans framework'? Why these parts should wait until we complete full toolset of classlib? Maybe the problem is a simple confusion over the word release. What do you mean here? We'd have a download called harmony-ketool- v1.0.tar.gz? I'm guessing that this isn't what you mean. Sorry for me being dense :) I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having subprojects that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. IMHO, we unintentionally pushed idea of independency components to project's backyard. I think this is not good. Sorry - I don't understand either. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... Yes, high mail traffic might be a problem it constantly grows. And subject's line definitely helps now but I'm not sure about future. Oh, we're definitely going to split lists someday. Also some parts of the project are indeed independent. For example, it may be possible to take some framework from classlib, say logging framework, and try it with another JRE. And the framework should work. This is true independence. So it seems more natural for me to create a sub- project for the framework to let it be more attractive for users: has less bugs, is faster, follows the spec. and so on. Why not? First, classlib is modular so users can do that already. Second, the Java SE spec license doesn't allow independent releases as in we are choosing to distribute this as shipping software, so we don't want to take on that issue. Thanks, Stepan. As for homepages, we already have that - basic pages for each major component. geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use :
Re: [drlvm] [launcher] Executable hangs
On Sep 28, 2006, at 3:41 AM, Egor Pasko wrote: Looks like a progress :) On the 0x1F2 day of Apache Harmony Armand Navabi wrote: That did not fix it for me. I thought I had both the bin directory and the default directory in my LD_LIBRARY_PATH. I just ran it again to make sure, and it still seems to get lost on execv(). Is there something special I need to call in gdb to skip it? you can always jump in GDB. And I love this feature. Now that should be easy enuough to debug out why the launcher does not see the LD_LIBRARY_PATH and tries to execv. Geir says, it should NOT execv. This is the bug. Seems like an easy one. This isn't *the* bug he's chasing. I think that the problem is that there's a / at the end of one of them (either .../bin/ or .../bin/ default/ - one of the trailing slashes should be removed... but I don't remember which one). I know our launcher constructs the LD_LIBRARY_PATH w/ one of the two w/ the slash, one w/o. We need to fix that for simple consistency, but it is not in itself a bug, as it does work fine. geir does main.c:1037 (oldPath = getenv (variableName);) work for you? BTW, I remember having to set HYLD_LIBRARY_PATH on OSX. I was very surprized)) -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
I suggest we work from a shared document like this http://wiki.apache.org/harmony/SourceHeaders to get all the source files covered. What do you think? Regards, Tim Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] current tests - can we focus on getting everything to pass?
On Sep 28, 2006, at 6:40 AM, Elena Semukhina wrote: On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Apparently there are some threading issues, which affect almost all suites (except may be smoke tests). I observe quite many sporadic crashes in c-unit, kernel and classlib tests. For example, the following assert fails often: drlvm/vm/thread/src/thread_native_suspend.c:351: hythread_set_safepoint_callback: Assertion `status == (0)' failed. Another incomprehensible error is described in HARMONY-1614. These defects most probably point to races in TM or VM internals, and are hard enough to insulate and root-cause. Aside from that, there are known stable failures, like kernel ThreadTest and ClassLoaderTest, or classlib's ThreadTest is a kind of always failing test unfortunately. Now its failure is related to launcher related issue mentioned in another thread as well as the HARMONY-1537 issue. All these issues are fixed with HARMONY-1582 patch. On the other hand, HARMONY-1582 reports that ThreadTest fails showing up new problems possibly related to H-1519 patch. So ThreadTest is very helpful in catching regressions and should be paid a special attention to each time it fails :) So a good question is how do we start? There is no patch yet for 1537, and there is still ongoing discussion of 1582, given it's complexity. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
So where are we here? On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote: On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread [drlvm] [launcher] Executable hangs. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Only me and you :-) Honetsly I think it happpens now Are there any known design flaws in it? I can think of two possible problems we may want to discuss. 1) Should native threads have daemon status or its completely java notion? This is TM related thing. 2) Should we attach thread to VM before attaching it to TM by calling jthread_atatch OR jthread_attach should callback VM to attach a thread to it? I didn't change original design of TM here .. it implements second choice. I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? No, this is not just different names. tm_suspend_enable asserts that thread is in disabled state before calling hythread_suspend_enable (in debug mode only). Thanks Evgueni -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][doc]Recommend to remove trunk\doc\kernel_doc and trunk\doc\vm_doc from svn repository.
On Sep 28, 2006, at 5:15 AM, Morozova, Nadezhda wrote: Do you think we can have the docs built on a regular basis (like, a script that triggers Doxygen build say 2 times a week + on demand to push updates if needed) and resulting docs stored on the website? This way, you don't have SVN versioning for auto-generated content and keep info available for all. I'm still pro stuffing the generated content into the svn fo the website, and then pushing that out, because in the next snapshot, I want to start getting into the habit of including the entire website generated docs (except tim's eclipse movie) in the tar file, so that users have information at the ready when they download. So +1 for : - getting the generated stuff out of classlib and drlvm trees - autogenerating as part of our CI - putting into SVN of website - publishing geir Best regards, Nadya Morozova -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 1:08 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][doc]Recommend to remove trunk\doc \kernel_doc and trunk\doc\vm_doc from svn repository. This has been a problem for some time - I recall commenting out the call to an ant target that cleaned that svn-checked out documentation. If we are going to remove them, then I think we need to add them to the website and ensure we update them regularly. (So that they exist in a form we can link to - I recall seeing links to the versions in svn in the past.) Regards, Mark. On 28 September 2006 at 16:30, Paulex Yang [EMAIL PROTECTED] wrote: Leo Li wrote: Hi, all: I have fixed the script to generate vm_doc but there is a problem: the newly generated vm_doc will override the original one which is under control of svn. Thus it will lead to build failure since vm_doc lacks from the perspective of svn. LOL, is it a problem of build script? Since the content under the directories of trunk\doc\kernel_doc and trunk\doc\vm_doc can be generated accordingly, I recommend to remove them from svn control as the doc of classlib does. Hmm...just had a look at the classlib/trunk/doc directory, I agree that current structure is interesting, there are three config files for Doxygen: kernel/kernel.cfg, classlib/classlib.cfg and vminterface/natives.cfg(I guess, for kernel class, classlib and native vmi respectively), while only two directories with Doxygen genereated documents: kernel_doc and vm_doc. IMHO, there is no reason to put the Doxygen generated files into SVN, which just like .class compiled by javac. I vote to remove the two directories, and keep the config files only. And, maybe we can add a build-doc target in the classlib/trunk/build.xml to make document creation more handy. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
On Sep 28, 2006, at 6:19 AM, Mark Hindess wrote: On 28 September 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrote: Sounds reasonable. The alternative is to not make clean fail, just print the warning and tidy up the remainder. That may be too easy to ignore though. Yes. I considered that and had the same concern. Even if I wrote the code to print the warning, I think I'd ignore it since it would scroll too quickly off the top of my screen at the beginning of the build. Nice work. I'd vote for failing fast with an optional override, to get people to fix these when they see them... :) geir -Mark. Regards, Tim Mark Hindess wrote: Yesterday, while looking at something unrelated, I noticed that some of the patternsets that are used to select the jars for the classlib modules were not up to date with the result that some classes would be missing from the resulting jars[0]. While it makes me slightly uneasy having a clean target that might fail, it turns out that this is one place where it is quite easy to check whether the patternsets are out of date. (Because if after the modules have cleaned classes in their patternsets there are still files left over then something is being create that isn't accounted for by the patternsets.) So the clean target will now fail with a message like (tested by reverting yesterdays change to the sound patternset): Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: /classlib/build/classes/org/apache/harmony/sound/utils/ ProviderService.cl ass I'm sure there are other ways to solve this problem but this seemed like a sensible quick fix to help catch these problems a little sooner [1]. Regards, Mark. [0] This might explain some of the awt/swing test failures so perhaps it is worth checking the exclude lists again? [1] Though I guess since we clean at the beginning of a build (not the end) then we might still find them in the build after the one that caused the break but that's better than only finding them by accident. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] fail statements omitted in many exception catching test cases
May be you can look at my JIRA too? Thanks :)
HARMONY-1604
2006/9/28, Tim Ellison [EMAIL PROTECTED]:
Fixed.
Rui Hu wrote:
Thanks Richard.
I've looked at luni module and raised HARMONY-1618 about some bugs of those
kind.
On 9/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at
[1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 from me On Thursday 28 September 2006 14:25 Oleg Khaschansky wrote: +1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? I've built it successfully on Linux but I unpacked JIRA separately from classlib and so had to copy some files from classlib from luni and correct some paths to point to it. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
I suppose two days silence means that there is no objects (maybe interest) against proposed patch. I would suggest to commit it ASAP. It really works! There are some cases when current VM crashes but the patch fixes it. I can work on bringing cunit tests to live as soon as the patch is committed This is just my understanding. Thanks Evgueni On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So where are we here? On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote: On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread [drlvm] [launcher] Executable hangs. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Only me and you :-) Honetsly I think it happpens now Are there any known design flaws in it? I can think of two possible problems we may want to discuss. 1) Should native threads have daemon status or its completely java notion? This is TM related thing. 2) Should we attach thread to VM before attaching it to TM by calling jthread_atatch OR jthread_attach should callback VM to attach a thread to it? I didn't change original design of TM here .. it implements second choice. I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? No, this is not just different names. tm_suspend_enable asserts that thread is in disabled state before calling hythread_suspend_enable (in debug mode only). Thanks Evgueni -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][thread] Thread.currentThread() is not alive anymore :(
Fixed, patch submitted to JIRA. Thread constructor used to initialize main thread simply didn't set alive status. This patch also corrects main thread's name and sets context class loader to SystemClassLoader. Thank you. Nik. On 9/22/06, Elena Semukhina [EMAIL PROTECTED] wrote: Kernel test ThreadTest fails due to Thread.currentThread().isAlive() returns false now. I've created a JIRA issue for this problem. https://issues.apache.org/jira/browse/HARMONY-1537 Does anyone want to study the issue and submit a patch for it? -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] svnfind tool (was: Re: [classlib][test] fail statements omitted in many exception catching test cases)
can you stuff this somewhere like the wiki or patch for website or
stuff somewhere in SVN? :)
geir
On Sep 28, 2006, at 7:53 AM, Mark Hindess wrote:
Testing this script reminded me that I'd not mentioned the small
script
I wrote after getting feed up typing:
find path -name .svn -prune -o ...
The script takes:
svnfind path [path2 ...] ...
and converts it to the previous form so that .svn directories are
ignored.
Others might find it useful so I've included it below.
-Mark.
#!/bin/sh
while [ -n $1 ]; do
case $1 in
-*)
break
;;
*)
[EMAIL PROTECTED]$1
;;
esac
shift
done
while [ -n $1 ]; do
[EMAIL PROTECTED]$1
shift
done
if [ -z ${args[0]} ]; then
args[0]=-print
fi
exec find [EMAIL PROTECTED] -name .svn -prune -o [EMAIL PROTECTED]
On 27 September 2006 at 9:44, Mark Hindess
[EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/
TimeTest.java +208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~ /
\bfail\s*\(/)
{
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED]
wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases
about exc
ep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because
the excepti
on
-throwing checking is disabled.
I've found that the fail statement is omitted in many test
cases of our H
ar
mony classlib. So I set some rules to find out all lines of code
related wi
th
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the
5 rules in
r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are
not of above
s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font
\TextLayoutTest.jav
a:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java
\lang\EnumTes
t.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests
\java\io\File
In
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests
\java\io\File
Ou
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this
kind withou
t
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more
bugs.
Anybody has better search rules or better solution to find out
those bugs?
Pl
s. share with us, thanks a lot.
--
Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util
\jar\JarF
=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util
\zip\Defl
=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util
\zip\Defl
=
aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091
\1092\1098\10
=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util
\zip\ZipF
=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util
\zip\ZipI
=
nputStreamTest.java:200
.\auth\src\test\java\common\javax\security\auth\callback
\ConfirmationCallba
=
snapshot...
As we've all been muttering for some time, it's high time for a new snapshot. I want to beat on drlvm for a few hours with apps to be sure, and then happy to push them out if ok. if not ok, we should just do HDKs (is anyone using the HDKs for development?) Is there anything standing in the way of the HDK for classlib? (I'll figure out answer to question for DRLVM...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Keeping the discussion out of the vote thread. Both this and javah aren't going into classlib anyway. I was going to suggest we put them into /tools, bring the javac and keytool over, and I volunteer to do it. Then add that to the federated build, and get into the jdk. geir On Sep 28, 2006, at 8:07 AM, Ivan Popov wrote: Yes, build script for JDWP agent should be aligned with the current classlib build structure. It should be easy, because it is generally oriented to the classlib structure and requires just a few changes. I can provide patch for this. I tried to build JDWP agent as a separate classlib component and it was built successfully with some known problems mentioned in README. Thanks. Ivan On 9/28/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: +1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: +1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
+1 On Sep 28, 2006, at 8:57 AM, Tim Ellison wrote: I suggest we work from a shared document like this http://wiki.apache.org/harmony/SourceHeaders to get all the source files covered. What do you think? Regards, Tim Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Hi Anton, I wanted to play with your site (http://www.harmonytest.org) and get the following (18:21 today): === HTTP Status 500 - Internal Server Error type Exception report message Internal Server Error description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: could not execute query at org.apache.harmony.testinfra.filters.HibernateSessionRequestFilter.doFilter(HibernateSessionRequestFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:409) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:528) at java.lang.Thread.run(Thread.java:534) oot cause javax.servlet.ServletException: could not execute query at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:696) at javax.servlet.http.HttpServlet.service(HttpServlet.java:809) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125) at org.apache.harmony.testinfra.filters.HibernateSessionRequestFilter.doFilter(HibernateSessionRequestFilter.java:47) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129) at java.security.AccessController.doPrivileged(Native Method) at
Re: [drlvm][classlib] thread library - let there be one!
On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. I agree making thread a standalone component at the level of enhanced/something probably isn't worth doing. What may make a sense is to consider thread a part of the portlib and make the portlib a separate component at that level. Portlib is the only piece which is shared between VM and classlib, this could justify it's appearance at the high level. Is there any downside to keeping it somewhere under /classlib/trunk My only guess would be the inability to build VM independently from the classlib. and simply make it a module by itself? If we can not have a portlib as a high level component (like classlib or drlvm), then at least having it as a separate module within classlib would be nice. Thanks, Andrey. Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll have a bottom part of hythread which will be shared between the classlib and DRLVM. Some additional steps could be: - pull the rest of the portlib out of the classlib, make it a shared component as well - migrate DRLVM to portlib Thanks, Andrey. geir Regards, Tim Weldon Washburn wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Artem Aliev wrote: Gier, The hythread is just most visible example. There are also signal handling problem. classlib hysig lib setup signal handlers and then drlvm overrides them by its owns. There are code duplication in classlib hyprt.dll drlvm port.lib: classlib/trunk/modules/luni/src/main/native/port vm/port/src These three pair of components contains significant part of the system dependent code for both VM and CLASSLIB. I think, all this code naturally defines portlib component that could be shared between classlib and VMs. So, as a first step, we could move all this code in to the one place, name portlib to have three directories classlib, drlvm, portlib. I think it is quite reasonable to call out the portlib and threadlib separate (in the repository) to the VM and classlib. As you point out, then VM and classlib can share the code -- though it will not become a requirement for VMs that run the harmony code to be using those libraries for their own implementation. Tim, One of the things to worry about is system-wide lock protocol. We will need to think through what locks portlib, threadlib and JVM are holding and if there are any deadlock possibilities. Another issue is the implementation of signal chaining. There seems to be code in hysignal.c that implement -Xrs. I guess the idea is that a Harmony JVM would somehow not link this code and use its own implementation. The bottom line is that we probably need to carefully pick through what is currently in classlib threads/signals and rearrange stuff so that it reduces the confusion. We need to make this part of the system much easier to work on. Do you have recommendations on next steps? Does it make sense to start moving stuff into the directories described above. Or is more discussion needed. As the second step, the pairs of libraries should be merged and the classlib and drlvm refactoried to have only 3 lib instead of 6. Yep, this would be part of the consolidation into new Harmony top- level components. It makes sense
Re: [drlvm][classlib] thread library - let there be one!
On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote: +1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?) We have to start first by pulling hythread out, but where? After thinking about it for 5 more seconds, putting it on the top level enhanced/something is IMO a bad idea. There's nothing worse than going to a project's SVN and finding tons of confusing things. I agree making thread a standalone component at the level of enhanced/something probably isn't worth doing. What may make a sense is to consider thread a part of the portlib and make the portlib a separate component at that level. Portlib is the only piece which is shared between VM and classlib, this could justify it's appearance at the high level. Is there any downside to keeping it somewhere under /classlib/trunk My only guess would be the inability to build VM independently from the classlib. Sure, you'll still need either to build the /portlib or the /classlib and simply make it a module by itself? If we can not have a portlib as a high level component (like classlib or drlvm), then at least having it as a separate module within classlib would be nice. This is one of those things where doing the small step (do it in classlib) and then consider the large step (do it as a peer) seems to be reasonable, but i don't feel too strongly... geir Thanks, Andrey. Hopefully we can clean up how drlvm handles the classlib portlib function table at the same time. Currently two versions of this table are created during startup. Portlib function table - let there be one! Seriously, this is incredibly difficult code to maintain. On 9/26/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, exactly. Regards, Tim Andrey Chernyshev wrote: On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote: Weldon, I agree with your comments and observations below. Let's take baby steps to get fully unified. I'm sure we all want to keep things working throughout. So what's the first stop? Move hythread as-is out of classlib to a peer in the tree? I can suggest the following steps: - pull out hythread from classlib, make it a shared component - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and upper layer (hythead_xxx) - migrate classlib code to the bottom layer (1) of hythread - migrate DRLVM's thread manager to (1) from APR Each step can be done without breaking the whole code stack. As a result, we'll have a bottom part of hythread which will be shared between the classlib and DRLVM. Some additional steps could be: - pull the rest of the portlib out of the classlib, make it a shared component as well - migrate DRLVM to portlib Thanks, Andrey. geir Regards, Tim Weldon Washburn wrote: On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote: Artem Aliev wrote: Gier, The hythread is just most visible example. There are also signal handling problem. classlib hysig lib setup signal handlers and then drlvm overrides them by its owns. There are code duplication in classlib hyprt.dll drlvm port.lib: classlib/trunk/modules/luni/src/main/native/port vm/ port/src These three pair of components contains significant part of the system dependent code for both VM and CLASSLIB. I think, all this code naturally defines portlib component that could be shared between classlib and VMs. So, as a first step, we could move all this code in to the one place, name portlib to have three directories classlib, drlvm, portlib. I think it is quite reasonable to call out the portlib and threadlib separate (in the repository) to the VM and classlib. As you point out, then VM and classlib can share the code -- though it will not become a requirement for VMs that run the harmony code to be using those libraries for their own implementation. Tim, One of the things to worry about is system-wide lock protocol. We will need to think through what locks portlib, threadlib and JVM are holding and if there are any deadlock possibilities. Another issue is the implementation of signal chaining. There seems to be code in hysignal.c that implement -Xrs. I guess the idea is that a Harmony JVM would somehow not link this code and use its own implementation. The bottom line is that we probably need to carefully pick through what is currently in classlib threads/signals and rearrange stuff so that it reduces the confusion. We need to make this part of the system much easier to work on. Do you have recommendations on next steps? Does it make sense to start
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
:) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Alexei, Thanks for the info - fixed. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: snapshot...
Geir, will this snapshot include awt native libraries on Windows? SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: As we've all been muttering for some time, it's high time for a new snapshot. I want to beat on drlvm for a few hours with apps to be sure, and then happy to push them out if ok. if not ok, we should just do HDKs (is anyone using the HDKs for development?) Is there anything standing in the way of the HDK for classlib? (I'll figure out answer to question for DRLVM...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Seems like the real-life testing broke the app :) Sorry for the inconvenience - I'm going to investigate it and bring it bask asap. On 9/28/06, Anton Luht [EMAIL PROTECTED] wrote: Alexei, Thanks for the info - fixed. -- Regards, Anton Luht, Intel Middleware Products Division -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[website][doc] please fix wrong link to the developer's guide
Hi, There's a little glitch in website: DRLVM page links into SVN for the developer's guide though the site directory has the correct file. Could somebody please apply the fix attached to JIRA 1631 https://issues.apache.org/jira/browse/HARMONY-1631? Nadya Morozova
Re: [build-test-infra] Build Test Infrastructure
Hello, The problem could be that hoster uses Mysql 4 while the app was configured for Mysql 5 - I've changed the settings - it's up again - I'll be watching it... On 9/28/06, Anton Luht [EMAIL PROTECTED] wrote: Seems like the real-life testing broke the app :) Sorry for the inconvenience - I'm going to investigate it and bring it bask asap. On 9/28/06, Anton Luht [EMAIL PROTECTED] wrote: Alexei, Thanks for the info - fixed. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: snapshot...
yes On Sep 28, 2006, at 11:01 AM, Alexey Petrenko wrote: Geir, will this snapshot include awt native libraries on Windows? SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: As we've all been muttering for some time, it's high time for a new snapshot. I want to beat on drlvm for a few hours with apps to be sure, and then happy to push them out if ok. if not ok, we should just do HDKs (is anyone using the HDKs for development?) Is there anything standing in the way of the HDK for classlib? (I'll figure out answer to question for DRLVM...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] svnfind tool
Geir Magnusson Jr. wrote:
can you stuff this somewhere like the wiki or patch for website or stuff
somewhere in SVN? :)
I normally do grep -r $something . | grep -v .svn
geir
On Sep 28, 2006, at 7:53 AM, Mark Hindess wrote:
Testing this script reminded me that I'd not mentioned the small script
I wrote after getting feed up typing:
find path -name .svn -prune -o ...
The script takes:
svnfind path [path2 ...] ...
and converts it to the previous form so that .svn directories are
ignored.
Others might find it useful so I've included it below.
-Mark.
#!/bin/sh
while [ -n $1 ]; do
case $1 in
-*)
break
;;
*)
[EMAIL PROTECTED]$1
;;
esac
shift
done
while [ -n $1 ]; do
[EMAIL PROTECTED]$1
shift
done
if [ -z ${args[0]} ]; then
args[0]=-print
fi
exec find [EMAIL PROTECTED] -name .svn -prune -o [EMAIL PROTECTED]
On 27 September 2006 at 9:44, Mark Hindess
[EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly stricter
on matching context around 'catch'/'fail', by handling comments slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/)
{
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED] wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases
about exc
ep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because the
excepti
on
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases
of our H
ar
mony classlib. So I set some rules to find out all lines of code
related wi
th
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5
rules in
r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not
of above
s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font\TextLayoutTest.jav
a:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java\lang\EnumTes
t.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\File
In
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests\java\io\File
Ou
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this kind
withou
t
any victims automatically, we must find out real bugs ourselves.*
Hope the result in attachment file can help us to find out more bugs.
Anybody has better search rules or better solution to find out those
bugs?
Pl
s. share with us, thanks a lot.
--Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\jar\JarF
=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl
=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\Defl
=
aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091\1092\1098\10
=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipF
=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java\util\zip\ZipI
=
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. +1 -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] svnfind tool
On Sep 28, 2006, at 11:34 AM, Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
can you stuff this somewhere like the wiki or patch for website or
stuff
somewhere in SVN? :)
I normally do grep -r $something . | grep -v .svn
Me too :)
geir
On Sep 28, 2006, at 7:53 AM, Mark Hindess wrote:
Testing this script reminded me that I'd not mentioned the small
script
I wrote after getting feed up typing:
find path -name .svn -prune -o ...
The script takes:
svnfind path [path2 ...] ...
and converts it to the previous form so that .svn directories are
ignored.
Others might find it useful so I've included it below.
-Mark.
#!/bin/sh
while [ -n $1 ]; do
case $1 in
-*)
break
;;
*)
[EMAIL PROTECTED]$1
;;
esac
shift
done
while [ -n $1 ]; do
[EMAIL PROTECTED]$1
shift
done
if [ -z ${args[0]} ]; then
args[0]=-print
fi
exec find [EMAIL PROTECTED] -name .svn -prune -o [EMAIL PROTECTED]
On 27 September 2006 at 9:44, Mark Hindess
[EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single
line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/
TimeTest.java
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/)
{
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
On 27 September 2006 at 15:02, Robert Hu [EMAIL PROTECTED]
wrote:
--090601000506020908060004
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=GB2312
Hi All,
In our unit test of classlib, there are huge number of test cases
about exc
ep
tion catching. The typical style of those cases is like that:
try {
someStatementShouldThrowAnException;
* fail(Expected an exception);*
} catch (SomeException e){
// Expected
}
If we omit the fail statement, the test case is wrong because
the
excepti
on
-throwing checking is disabled.
I've found that the fail statement is omitted in many test cases
of our H
ar
mony classlib. So I set some rules to find out all lines of code
related wi
th
it. If a line of code comform all the 5 rules, it may be a bug:
1.in a *Test.java file
2.does not start with //
3.contains catch
4.its previous line does not contains fail
5.its next line contains // or }
Then I found out 1711 lines of code in 309 files comform all the 5
rules in
r
450321. (Attachment file is the result.)
Of course not all of them are bug, because some test cases are not
of above
s
tyle.
And I also find out some real bugs, we can fix them easilly:
trunk\modules\awt\src\test\api\java\common\java\awt\font
\TextLayoutTest.jav
a:
652\658\664\670\676\685\698\704\711(line number)
trunk\modules\luni\src\test\java\org\apache\harmony\tests\java
\lang\EnumTes
t.
java:57
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests
\java\io\File
In
putStreamTest.java:36
trunk\modules\luni\src\test\java\org\apache\harmony\luni\tests
\java\io\File
Ou
tputStreamTest.java:35
more..
*I must say frankly that it's hard to find out all bugs of this
kind
withou
t
any victims automatically, we must find out real bugs
ourselves.*
Hope the result in attachment file can help us to find out more
bugs.
Anybody has better search rules or better solution to find out
those
bugs?
Pl
s. share with us, thanks a lot.
--Robert Hu
China Software Development Lab, IBM
--090601000506020908060004
Content-Type: text/plain;
name=result.txt
Content-Disposition: inline;
filename=result.txt
Content-Transfer-Encoding: quoted-printable
current position is trunk\modules
.\archive\src\test\java\org\apache\harmony\archive\tests\java
\util\jar\JarF
=
ileTest.java:66\79\190
.\archive\src\test\java\org\apache\harmony\archive\tests\java
\util\zip\Defl
=
aterOutputStreamTest.java:220\230
.\archive\src\test\java\org\apache\harmony\archive\tests\java
\util\zip\Defl
=
aterTest.java:188\619\724\785\792\859\1006\1013\1070\1077\1091
\1092\1098\10
=
99\1105\1106\1113\1114\1120\1121\1127\1128\1134\1135\1143\1179
.\archive\src\test\java\org\apache\harmony\archive\tests\java
\util\zip\ZipF
=
ileTest.java:67\291
.\archive\src\test\java\org\apache\harmony\archive\tests\java
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
On 9/27/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: (3) One more lock is added - hythread_lib_lock. How is that differ from the hythread_global_lock that we already have? Each extra lock to the system may add more possibilities for deadlocks, as well as can negatively impact the scalability (unless some of the existing locks are split). hythread_lib_lock acquires exactly the same lock as hythread_global_lock. Probably I miss something but we need to be compatible with IBM threading library now. This library has such function. That's why I added it. Sounds right? Well, this sort of, kind of sounds right but not quite. Its a little more subtle than being compatible with IBM threading library. The first goal is to identify the parts of IBM threading library that are JVM independent. It makes sense for DRLVM to be compatible with the independent parts. This should be a nobrainer. The parts of IBM threading library that assume a specific JVM implementation will be a problem. We will need to find a solution that is endorsed by all the stakeholders (including J9 folks). The hythread_global_lock falls into this category. For starts, I would like to see a concise description from the portlib owners on what hythread_global_lock protects, which locks have to be held before grabbing this lock, are there any restrictions on what system calls can be made while holding this lock (like sleep or wait), etc. Weldon, I completely agree with what your are saying. It's common problem of current hythread that should be resolved some how. I just go inline with current implementation and added two missing functions. Missing these can lead to the same problems as with hythread_exit discussed in another thread [drlvm] [launcher] Executable hangs. To get a better idea what's in the patch.diff, I printed it out. Its 120+ pages. Quite a big patch! Most of it looks like straight forward JNI interface glue. There are some tricky parts. I would like to know the design review process for these parts. Using grep, I found 20 locations where ...suspend_enable... and ...suspend_disable... have been added. And 25 locations where enable/disable have been removed. Failure in this logic can lead to incorrect reference pointer enumeration. These are probably the hardest bugs to find. Please tell us who has looked at this code in depth. Only me and you :-) Honetsly I think it happpens now You and Andrey Chernyshev and me need to review enable/disable very closely very soon. bugs in this area can lead to all sorts of hard to diagnose instability. Are there any known design flaws in it? I can think of two possible problems we may want to discuss. 1) Should native threads have daemon status or its completely java notion? This is TM related thing. 2) Should we attach thread to VM before attaching it to TM by calling jthread_atatch OR jthread_attach should callback VM to attach a thread to it? I didn't change original design of TM here .. it implements second choice. I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable() -- are these simply different names for the same binary executible. Or different binaries that do the same thing?? No, this is not just different names. tm_suspend_enable asserts that thread is in disabled state before calling hythread_suspend_enable (in debug mode only). Thanks Evgueni -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
[classlib] AWT/Swing deps
Ok, that was fun. Not. We need to finish making this easier for developers to build by having pre-built binaries somewhere. To start, I'm going to put a well-documented tree that contains the stuff needed for /png, /lcms and /jpg on my personal account and note it. If we can then make that part of fetch-depends, all will be well. Comments? Other ideas? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build-test-infra] Build Test Infrastructure
Anton, Thank you for a prompt reply! I have one more comment concerning a site design: it would be great to see a number of records in the current search request. For example, if I chose nothing, I would a total number of tests in the report. Actually I want to see a total number of passed tests. Why? Since the number of fails gives us an optimistic estimate due to report misses, I may calculate a number of fails as a total amount - number of passes. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 2:01 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure Alexei, VM hanged in the process of test execution - I killed it and tests proceeded - I'm not sure whether this crash is recorded as error or those tests are not included in the report. The report on site is the similar to the one I see in my local test_result/html report . On 9/28/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Anton, I'm looking at http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=2 jira=0 http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=3 jira=0 I see 5 errors and 14 failures. I just want to double check that we have less than 20 problems with running unit tests on DRLVM. Is it correct statement or some failures are missed? With best regards, Alexei Fedotov, Intel Middleware Products Division BTW, I have a small request for enhancement: the following request hides search options by the right margin of my screen. I would suggest reordering table rows in a way fixed width fields go first. http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=1 jira=0 -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 7:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure I think we'd want this to be registered user can add user Done. I'm still the only person with login - send me your login/password to register. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1609) Applet, ImageIO and Print modules
Indeed. Excellent work. A quick check shows this contribution should bring the japi results to 93.65% I look forward to the build file patch so we can test it properly. -Mark On 27 September 2006 at 23:01, Tim Ellison [EMAIL PROTECTED] wrote: Woo hoo! Good work Alexey and team. Tim Alexey Petrenko (JIRA) wrote: Applet, ImageIO and Print modules - Key: HARMONY-1609 URL: http://issues.apache.org/jira/browse/HARMONY-1609 Project: Harmony Issue Type: New Feature Components: Classlib, Contributions Reporter: Alexey Petrenko Attachments: apio.zip This contribution consists of Applet, ImageIO and Print modules implementat ion and tests. It also adds few classes to awt and swing modules which are depends on this modules. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] fail statements omitted in many exception catching test cases
I'll take a look.
-Mark.
On 28 September 2006 at 17:31, Alexei Zakharov [EMAIL PROTECTED] wrote:
May be you can look at my JIRA too? Thanks :)
HARMONY-1604
2006/9/28, Tim Ellison [EMAIL PROTECTED]:
Fixed.
Rui Hu wrote:
Thanks Richard.
I've looked at luni module and raised HARMONY-1618 about some bugs of tho
se
kind.
On 9/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Great job, Robert. ;-)
I will have a look at sql.
On 9/28/06, Rui Hu [EMAIL PROTECTED] wrote:
Great Mark!
I've merged your code into my script. The script can be downloaded at
[1].
Usage:
perl failFinder.pl root_of_module
e.g. Search out all related lines in luni module and redirect it to
result.txt
perl failFinder.pl trunk/modules/luni result.txt
e.g. Search out all related lines in all modules and redirect it to
result.txt
perl failFinder.pl trunk/modules/ result.txt
Anyone can find out the related lines of any modules.
[1]:
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/at
tachments/failFinder.pl
On 9/27/06, Mark Hindess [EMAIL PROTECTED] wrote:
This perl script does a marginally better job by being slightly
stricter
on matching context around 'catch'/'fail', by handling comments
slightly
better and by handling 'catch (...) { }' appearing on a single line.
It also finds a few more hits such as:
sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.jav
a
+208
which is a false positive but which uses assertTrue(false); which
should be fixed anyway.
-Mark.
#!/usr/bin/perl -w
use strict;
my $previous_line = ;
my $possible_line_number;
while () {
next if (/^\s*$/); # skip blank lines
if ($possible_line_number) {
if (m!^\s*(//|/\*|})!) {
print $ARGV, ' +', $possible_line_number, \n;
}
undef $possible_line_number;
}
if (!m!^\s*(/?\*|//)! /\bcatch\s*\(/ $previous_line !~
/\bfail\s*\(/) {
$possible_line_number = $.;
if (/catch\s*\([^\)]+\)\s*{\s*}/) {
print $ARGV, ' +', $possible_line_number, \n;
undef $possible_line_number;
}
}
$previous_line = $_;
}
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
On 28 September 2006 at 13:57, Tim Ellison [EMAIL PROTECTED] wrote: I suggest we work from a shared document like this http://wiki.apache.org/harmony/SourceHeaders to get all the source files covered. What do you think? Seems reasonable. I've put my name against a couple of directories. -Mark. Regards, Tim Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp]
now my updated svn repo doesn't build... Let me do a clean... geir On Sep 28, 2006, at 1:03 PM, Geir Magnusson Jr wrote: Please stop adding things to DRLVM until I can be sure we have something stable for the snapshot. Also, is this from a JIRA? Please put the JIRA ID as the first line of the commmit. geir Original Message Subject: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Date: Thu, 28 Sep 2006 16:53:55 - From: [EMAIL PROTECTED] Reply-To: harmony-dev@incubator.apache.org To: [EMAIL PROTECTED] Author: wjwashburn Date: Thu Sep 28 09:53:54 2006 New Revision: 450919 URL: http://svn.apache.org/viewvc?view=revrev=450919 Log: committing 1372 mods, the Linux and windows build update works about as well as before the mods... Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/ vm/vmcore/src/util/mem_alloc.cpp? view=diffrev=450919r1=450918r2=450919 == --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Thu Sep 28 09:53:54 2006 @@ -308,5 +308,5 @@ assert (base); // Subtract a small number (like 1) from the real base so that // no valid vtable offsets will ever be 0. -return (POINTER_SIZE_INT) (base - 1); +return (POINTER_SIZE_INT) (base - 8); } //vm_get_vtable_base - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp]
no dice. can't build on a clean. Shall we roll it back? geir On Sep 28, 2006, at 1:28 PM, Geir Magnusson Jr. wrote: now my updated svn repo doesn't build... Let me do a clean... geir On Sep 28, 2006, at 1:03 PM, Geir Magnusson Jr wrote: Please stop adding things to DRLVM until I can be sure we have something stable for the snapshot. Also, is this from a JIRA? Please put the JIRA ID as the first line of the commmit. geir Original Message Subject: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Date: Thu, 28 Sep 2006 16:53:55 - From: [EMAIL PROTECTED] Reply-To: harmony-dev@incubator.apache.org To: [EMAIL PROTECTED] Author: wjwashburn Date: Thu Sep 28 09:53:54 2006 New Revision: 450919 URL: http://svn.apache.org/viewvc?view=revrev=450919 Log: committing 1372 mods, the Linux and windows build update works about as well as before the mods... Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/ trunk/vm/vmcore/src/util/mem_alloc.cpp? view=diffrev=450919r1=450918r2=450919 = = --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Thu Sep 28 09:53:54 2006 @@ -308,5 +308,5 @@ assert (base); // Subtract a small number (like 1) from the real base so that // no valid vtable offsets will ever be 0. -return (POINTER_SIZE_INT) (base - 1); +return (POINTER_SIZE_INT) (base - 8); } //vm_get_vtable_base - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/mem_alloc.cpp]
Ok, I'm rolling back (talked to weldon - he's in transit) geir On Sep 28, 2006, at 1:34 PM, Geir Magnusson Jr. wrote: no dice. can't build on a clean. Shall we roll it back? geir On Sep 28, 2006, at 1:28 PM, Geir Magnusson Jr. wrote: now my updated svn repo doesn't build... Let me do a clean... geir On Sep 28, 2006, at 1:03 PM, Geir Magnusson Jr wrote: Please stop adding things to DRLVM until I can be sure we have something stable for the snapshot. Also, is this from a JIRA? Please put the JIRA ID as the first line of the commmit. geir Original Message Subject: svn commit: r450919 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Date: Thu, 28 Sep 2006 16:53:55 - From: [EMAIL PROTECTED] Reply-To: harmony-dev@incubator.apache.org To: [EMAIL PROTECTED] Author: wjwashburn Date: Thu Sep 28 09:53:54 2006 New Revision: 450919 URL: http://svn.apache.org/viewvc?view=revrev=450919 Log: committing 1372 mods, the Linux and windows build update works about as well as before the mods... Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/ trunk/vm/vmcore/src/util/mem_alloc.cpp? view=diffrev=450919r1=450918r2=450919 == --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ mem_alloc.cpp Thu Sep 28 09:53:54 2006 @@ -308,5 +308,5 @@ assert (base); // Subtract a small number (like 1) from the real base so that // no valid vtable offsets will ever be 0. -return (POINTER_SIZE_INT) (base - 1); +return (POINTER_SIZE_INT) (base - 8); } //vm_get_vtable_base - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: snapshot...
Hello, will this snapshot include the recent ImageIO contributions? Thanks, Martin On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: yes On Sep 28, 2006, at 11:01 AM, Alexey Petrenko wrote: Geir, will this snapshot include awt native libraries on Windows? SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: As we've all been muttering for some time, it's high time for a new snapshot. I want to beat on drlvm for a few hours with apps to be sure, and then happy to push them out if ok. if not ok, we should just do HDKs (is anyone using the HDKs for development?) Is there anything standing in the way of the HDK for classlib? (I'll figure out answer to question for DRLVM...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: snapshot...
Martin Cordova wrote: Hello, will this snapshot include the recent ImageIO contributions? No, that will have to wait for the snapshot after it has been voted in. You should be able to combine the contribution with the snapshot quite easily if you choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: snapshot...
On 28 September 2006 at 19:56, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Hello, will this snapshot include the recent ImageIO contributions? No, that will have to wait for the snapshot after it has been voted in. You should be able to combine the contribution with the snapshot quite easily if you choose. Not that easily. There are no build scripts in the contribution - though the comments indicate that a patch will be contributed. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [launcher] Executable hangs
Making progress...
Ok, the problem with execv() has been solved. It wasn't finding the
path because of a stupid mistake on my part. Here was the problem:
1047if (newPathToAdd[i] != NULL strstr(oldPath,
newPathToAdd[i]) != 0) {
(gdb) p newPathToAdd[i]
$2 = 0x8067ae8
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default
(gdb) p oldPath
$3 = 0xbfe4c554
/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default
I had to change /homes/anavabi to /u/u12/anavabi in LD_LIBRARY_PATH and
then the paths are found, so it never gets to the execv line. FYI, the
default directory is the one that should not contain a trailing slash.
Thanks for the help on this one.
Now gdb is working like a champ, but java helloworld is still having
problems. Here is a stack trace of what happens when I try to run
helloworld in gdb:
(gdb) run helloworld
Starting program:
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java
helloworld
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 12424)]
[New Thread 32769 (LWP 12427)]
[New Thread 16386 (LWP 12428)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 12424)]
0xb7f72d94 in _dl_relocate_object () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7f72d94 in _dl_relocate_object () from /lib/ld-linux.so.2
#1 0xb7a99fa3 in getutmpx () from /lib/libc.so.6
#2 0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
#3 0xb7a9a745 in _dl_open () from /lib/libc.so.6
#4 0xb79aed00 in ?? () from /lib/libdl.so.2
#5 0xfffe in ?? ()
#6 0xb7f8 in ?? () from /lib/ld-linux.so.2
#7 0xbf9cab68 in ?? ()
#8 0xb7f7ffd4 in ?? () from /lib/ld-linux.so.2
#9 0xb7f7fca0 in ?? () from /lib/ld-linux.so.2
#10 0x000c in ?? ()
#11 0xbf9cac38 in ?? ()
#12 0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
#13 0xb7f75862 in _dl_catch_error () from /lib/ld-linux.so.2
#14 0xb79af299 in dlerror () from /lib/libdl.so.2
#15 0xb79aed54 in dlopen () from /lib/libdl.so.2
#16 0xb6ecca78 in apr_dso_load (res_handle=0x0, path=0x0,
pool=0x8090c40) at dso.c:139
#17 0xb6d3baa1 in Dll_JIT (this=0x80a8640,
dll_filename=0x80a8774
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//libjitrino.so)
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/jit/dll_jit.cpp:62
#18 0xb6df0f42 in vm_load_jit (
file_name=0x80a8774
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default//libjitrino.so,
handle=0xbf9cb1bc) at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp:628
#19 0xb6951a9e in DrlEMImpl::buildChains (this=0x80a7e80,
[EMAIL PROTECTED])
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/em/src/DrlEMImpl.cpp:436
#20 0xb6951256 in DrlEMImpl::init (this=0x80a7e80) at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/em/src/DrlEMImpl.cpp:362
#21 0xb694f239 in DrlEMFactory::createAndInitEMInstance ()
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/em/src/DrlEMImpl.cpp:51
#22 0xb6969a72 in CreateInstance (p_instance=0xb6fc3c28, pool=0x808ec38)
at /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/em/src/em_intf.cpp:131
#23 0xb6d37eee in CmCreateInstance (p_instance=0xb6fc3c28,
name=0xb6f1f764 em)
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmstart/src/compmgr/component_manager_impl.cpp:583
#24 0xb6deed2b in process_properties_dlls (p_env=0xb6fc3a80)
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp:147
#25 0xb6df00ea in create_vm (p_env=0xb6fc3a80, vm_arguments=0xbf9cb570)
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm_main.cpp:355
#26 0xb6d6865a in JNI_CreateJavaVM (p_vm=0xbf9cb56c, p_env=0xbf9cb568,
vm_args=0xbf9cb570)
at
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp:1269
#27 0x0804994d in invocation (portLibrary=0xbf9cb7d0, argc=2,
argv=0xbf9cbbc4, handle=134642856, version=65540,
ignoreUnrecognized=1 '\001', mainClass=0xbf9cd3a9 helloworld,
classArg=1, isJvmSubDir=0,
propertiesFileName=0x8067be0
/u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/harmonyvm.properties,
isStandaloneJar=0, vmdllsubdir=0xbf9cb608 default) at main.c:623
#28 0x08049095 in gpProtectedMain (args=0xbf9cb7b0) at main.c:360
#29 0x0804b5ad in signalProtectedMain (portLibrary=0xbf9cb7d0,
arg=0xbf9cb7b0) at cmain.c:78
#30 0xb7f573f0 in hysig_protect (portLibrary=0xbf9cb7d0, fn=0x804b59c
signalProtectedMain, fn_arg=0xbf9cb7b0,
handler=0x804b410 genericSignalHandler, handler_arg=0x0,
flags=124, result=0xbf9cb7a8) at hysignal.c:332
#31 0x0804b692 in main (argc=2, argv=0xbf9cbbc4, envp=0xbf9cbbd0) at
cmain.c:103
Let me know if there is any other debugging information I can provide.
Thanks,
Armand
Geir Magnusson Jr. wrote:
On Sep 28, 2006, at 3:41 AM, Egor Pasko wrote:
Looks like a progress :)
On the 0x1F2 day of Apache Harmony Armand
Re: snapshot...
2006/9/28, Mark Hindess [EMAIL PROTECTED]: On 28 September 2006 at 19:56, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Hello, will this snapshot include the recent ImageIO contributions? No, that will have to wait for the snapshot after it has been voted in. You should be able to combine the contribution with the snapshot quite easily if you choose. Not that easily. There are no build scripts in the contribution - though the comments indicate that a patch will be contributed. Yep, I'm going to prepare build files in next few days. And svn add script as it required by good issue resolution guideline :) SY, Alexey -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] snapshots deployed (r450941)
Snapshots are built, tested and deployed to site. I found a few things while testing, such as not being able to run jedit out of the box on windows. (HARMONY-1639) Ran fine on linux though, but that's an older version. I'll check with latest. Also re-discovered a problem that we knew about, that we don't seem to be calculating serialVersionUIDs right. (HARMONY-1123). I'm going to look at that now, as that's keeping us from running Geronimmo 1.1.1, which I think would be useful. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
