On the 0x25B day of Apache Harmony Geir Magnusson, Jr. wrote: > On Jan 11, 2007, at 2:18 AM, Egor Pasko wrote: > > > On the 0x25A day of Apache Harmony Geir Magnusson, Jr. wrote: > >> Two things : > >> > >> 1) shouldn't we start running tests using -Xem:server? :) > > > > +1, but not excluding our current workloads > > of course not :) > > > > >> 2) Does anyone object to declaring gcc 4.x as our "supported" > >> compiler? What do we lose? (IOW, what platforms don't have gcc > >> 4.x?) I'll ask this again in a different thread > > > > concerning this change guided by gcc 3.x, it is quite simple and has > > no negative influence on other configurations. In this case we should > > do the change regardless of our "supported" configuration, > > shouldn't we? > > Yep. The real issue is with snapshots/builds, so that we have the > right libstc++. I suppose that in reality, we'll be building and > certifying on the actual platforms that we support, and therefore > should really be using the toolchain the distro ships with (for those > that actually ship w/ developer tools)
Agreed in general: to build for a limited numer of platforms that we "support" and leave the other platforms to other integrators. In specific libstdc++ issue I still believe that whe can ship it linked statically for our snapshots and releases (at cost of some pain, but..) > geir > > > > > >> geir > >> > >> On Jan 10, 2007, at 7:42 AM, Mikhail Fursov wrote: > >> > >>> I wrote the code that fail and I hope that this is not GCC 3.4 bug > >>> but my > >>> missunderstanding. However I do not understand why for a vector of > >>> pointers > >>> that does not contain NULLs gcc3.4 generates code that passes NULL > >>> to a > >>> comparator. > >>> > >>> The only workaround I know: replace std::sort(..) with > >>> std::stable_sort(..). > >>> I'm going to provide a patch this week. > >>> > >>> > >>> > >>> On 10 Jan 2007 15:07:53 +0600, Egor Pasko <[EMAIL PROTECTED]> > >>> wrote: > >>>> > >>>> On the 0x25A day of Apache Harmony Pavel Ozhdikhin wrote: > >>>>> Naveen, > >>>>> > >>>>> Using gcc 4.1.0 or newer will likely help in your case. There > >>>> was JIRA > >>>> issue > >>>>> about similar failure: > >>>>> > >>>>> http://issues.apache.org/jira/browse/HARMONY-1873 > >>>>> > >>>>> The comments reads that earlier gcc version have a bug in > >>>>> std::sort > >>>>> implementation. That particular issue was fixed by simplifying the > >>>>> comparator expression but the root cause is a bug in gcc. > >>>> > >>>> I would vote to workaround the possible GCC bug. Finding the right > >>>> GCC > >>>> bugreport would have been ideal. > >>>> > >>>>> Thanks, > >>>>> Pavel > >>>>> > >>>>> > >>>>> On 1/10/07, Naveen Neelakantam <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> I am seeing a segfault when I use the -Xem:server option. I > >>>> depend > >>>>>> on this option working. > >>>>>> > >>>>>> Thanks, > >>>>>> Naveen > >>>>>> > >>>>>> Begin forwarded message: > >>>>>> > >>>>>>> From: "Naveen Neelakantam (JIRA)" <[EMAIL PROTECTED]> > >>>>>>> Date: January 9, 2007 5:29:27 PM CST > >>>>>>> To: [EMAIL PROTECTED] > >>>>>>> Subject: [jira] Created: (HARMONY-2956) [jit] segfault with - > >>>>>>> Xem:server option > >>>>>>> > >>>>>>> [jit] segfault with -Xem:server option > >>>>>>> -------------------------------------- > >>>>>>> > >>>>>>> Key: HARMONY-2956 > >>>>>>> URL: https://issues.apache.org/jira/browse/ > >>>>>>> HARMONY-2956 > >>>>>>> Project: Harmony > >>>>>>> Issue Type: Bug > >>>>>>> Components: DRLVM > >>>>>>> Environment: RHEL4 update 4, x86, core2 duo > >>>>>>> Reporter: Naveen Neelakantam > >>>>>>> > >>>>>>> > >>>>>>> The problem seems to occur with any long running program, > >>>> but you > >>>>>>> can trigger it with the DaCapo benchmarks: > >>>>>>> > >>>>>>>> java -showversion -Xem:server -jar dacapo-2006-10.jar fop > >>>>>>> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache > >>>>>>> Software Foundation or its licensors, as applicable. > >>>>>>> java version "1.5.0" > >>>>>>> pre-alpha : not complete or compatible > >>>>>>> svn = r494559, (Jan 9 2007), Linux/ia32/gcc 3.4.6, debug build > >>>>>>> http://incubator.apache.org/harmony > >>>>>>> SIGSEGV in VM code. > >>>>>>> Stack trace: > >>>>>>> 1: Jitrino::Ia32::edge_comparator::getEdgeExecCount > >>>>>>> (Jitrino::Edge const*) (??:-1) > >>>>>>> 2: ?? (00180234 > >>>>>>> :180234) > >>>>>>> 3: ?? (0017f79e > >>>>>>> :17) > >>>>>>> 4: ?? (0017f7b0 > >>>>>>> :17) > >>>>>>> 5: ?? (0017f7b0 > >>>>>>> :17) > >>>>>>> 6: ?? (0017f7b0 > >>>>>>> :17) > >>>>>>> 7: ?? (0017f6d3 > >>>>>>> :17) > >>>>>>> 8: Jitrino::Ia32::BottomUpLayout::linearizeCfgImpl() > >>>> (??:-1) > >>>>>>> 9: Jitrino::Ia32::Linearizer::linearizeCfg() (??:-1) > >>>>>>> 10: Jitrino::Ia32::Linearizer::doLayout > >>>>>>> (Jitrino::Ia32::Linearizer::LinearizerType, > >>>>>>> Jitrino::Ia32::IRManager*) (??:-1) > >>>>>>> 11: Jitrino::Ia32::Layouter::runImpl() (??:-1) > >>>>>>> 12: Jitrino::Ia32::SessionAction::run() (??:-1) > >>>>>>> 13: Jitrino::runPipeline(Jitrino::CompilationContext*) > >>>> (??:-1) > >>>>>>> 14: Jitrino::compileMethod > >>>> (Jitrino::CompilationContext*) > >>>>>>> (??:-1) > >>>>>>> 15: Jitrino::Jitrino::CompileMethod > >>>>>>> (Jitrino::CompilationContext*) (??:-1) > >>>>>>> 16: JIT_compile_method_with_params (??:-1) > >>>>>>> 17: Dll_JIT::compile_method_with_params(void*, Method*, > >>>>>>> OpenMethodExecutionParams) (/home/dcsfiles/neelakan/Sandbox/ > >>>> Harmony/ > >>>>>>> stable/working_vm/vm/vmcore/include/dll_jit_intf.h:86) > >>>>>>> 18: compile_do_compilation_jit(Method*, JIT*) (/home/ > >>>>>>> dcsfiles/neelakan/Sandbox/Harmony/stable/working_vm/vm/ > >>>> vmcore/src/ > >>>>>>> jit/compile.cpp:645) > >>>>>>> 19: vm_compile_method (/home/dcsfiles/neelakan/Sandbox/ > >>>>>>> Harmony/stable/working_vm/vm/vmcore/src/class_support/ > >>>>>>> C_Interface.cpp:2462) > >>>>>>> 20: DrlEMImpl::compileMethod(Method*) (/home/dcsfiles/ > >>>>>>> neelakan/Sandbox/Harmony/stable/working_vm/vm/em/src/ > >>>> DrlEMImpl.cpp: > >>>>>>> 545) > >>>>>>> 21: CompileMethod (/home/dcsfiles/neelakan/Sandbox/ > >>>> Harmony/ > >>>>>>> stable/working_vm/vm/em/src/em_intf.cpp:49) > >>>>>>> 22: compile_do_compilation (/home/dcsfiles/neelakan/ > >>>> Sandbox/ > >>>>>>> Harmony/stable/working_vm/vm/vmcore/src/jit/compile.cpp:752) > >>>>>>> 23: compile_me(Method*) (/home/dcsfiles/neelakan/ > >>>> Sandbox/ > >>>>>>> Harmony/stable/working_vm/vm/vmcore/src/jit/compile.cpp:772) > >>>>>>> 24: IP is 0xB6972162 <native code> > >>>>>>> 25: ?? (??:-1) > >>>>>>> 26: dacapo/parser/ConfigFileTokenManager.jjStartNfa_0 > >>>> (IJ)I > >>>>>>> (ConfigFileTokenManager.java:-1) > >>>>>>> 27: dacapo/parser/ > >>>>>>> ConfigFileTokenManager.jjMoveStringLiteralDfa2_0(JJ)I > >>>>>>> (ConfigFileTokenManager.java:-1) > >>>>>>> 28: dacapo/parser/ > >>>>>>> ConfigFileTokenManager.jjMoveStringLiteralDfa1_0(J)I > >>>>>>> (ConfigFileTokenManager.java:-1) > >>>>>>> 29: dacapo/parser/ > >>>>>>> ConfigFileTokenManager.jjMoveStringLiteralDfa0_0()I > >>>>>>> (ConfigFileTokenManager.java:-1) > >>>>>>> 30: dacapo/parser/ConfigFileTokenManager.getNextToken() > >>>>>>> Ldacapo/parser/Token; (ConfigFileTokenManager.java:-1) > >>>>>>> 31: dacapo/parser/ConfigFile.jj_consume_token(I) > >>>> Ldacapo/ > >>>>>>> parser/Token; (ConfigFile.java:-1) > >>>>>>> 32: dacapo/parser/ConfigFile.config()Ldacapo/parser/ > >>>> Config; > >>>>>>> (ConfigFile.java:-1) > >>>>>>> 33: dacapo/parser/ConfigFile.configFile()Ldacapo/ > >>>> parser/ > >>>>>>> Config; (ConfigFile.java:-1) > >>>>>>> 34: dacapo/parser/Config.parse(Ljava/io/InputStream;) > >>>>>>> Ldacapo/parser/Config; (Config.java:-1) > >>>>>>> 35: dacapo/TestHarness.<init>(Ljava/io/InputStream;)V > >>>>>>> (TestHarness.java:-1) > >>>>>>> 36: dacapo/TestHarness.main([Ljava/lang/String;)V > >>>>>>> (TestHarness.java:-1) > >>>>>>> 37: vm_invoke_native_array_stub (/home/dcsfiles/ > >>>> neelakan/ > >>>>>>> Sandbox/Harmony/stable/working_vm/vm/vmcore/src/util/ia32/base/ > >>>>>>> invoke_native_stub_ia32.asm:41) > >>>>>>> 38: JIT_execute_method_default(void*, _jmethodID*, > >>>> jvalue*, > >>>>>>> jvalue*) (/home/dcsfiles/neelakan/Sandbox/Harmony/stable/ > >>>> working_vm/ > >>>>>>> vm/vmcore/src/util/ia32/base/ini_iA32.cpp:199) > >>>>>>> 39: DrlEMImpl::executeMethod(_jmethodID*, jvalue*, > >>>> jvalue*) > >>>>>>> (/home/dcsfiles/neelakan/Sandbox/Harmony/stable/working_vm/ > >>>> vm/em/ > >>>>>>> src/DrlEMImpl.cpp:514) > >>>>>>> 40: ExecuteMethod (/home/dcsfiles/neelakan/Sandbox/ > >>>> Harmony/ > >>>>>>> stable/working_vm/vm/em/src/em_intf.cpp:43) > >>>>>>> 41: vm_execute_java_method_array(_jmethodID*, jvalue*, > >>>>>>> jvalue*) (/home/dcsfiles/neelakan/Sandbox/Harmony/stable/ > >>>> working_vm/ > >>>>>>> vm/vmcore/src/jit/ini.cpp:51) > >>>>>>> 42: call_static_method_no_ref_result (/home/dcsfiles/ > >>>>>>> neelakan/Sandbox/Harmony/stable/working_vm/vm/vmcore/src/jni/ > >>>>>>> jni_method.cpp:1155) > >>>>>>> 43: CallStaticVoidMethodA(JNIEnv_External*, _jobject*, > >>>>>>> _jmethodID*, jvalue*) (/home/dcsfiles/neelakan/Sandbox/Harmony/ > >>>>>>> stable/working_vm/vm/vmcore/src/jni/jni_method.cpp:1563) > >>>>>>> 44: invoke_primitive_method (/home/dcsfiles/neelakan/ > >>>>>>> Sandbox/Harmony/stable/working_vm/vm/vmcore/src/kernel_classes/ > >>>>>>> native/java_lang_reflect_VMReflection.cpp:184) > >>>>>>> Segmentation fault > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> This message is automatically generated by JIRA. > >>>>>>> - > >>>>>>> If you think it was sent incorrectly contact one of the > >>>>>>> administrators: https://issues.apache.org/jira/secure/ > >>>>>>> Administrators.jspa > >>>>>>> - > >>>>>>> For more information on JIRA, see: http://www.atlassian.com/ > >>>>>>> software/jira > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> -- > >>>> Egor Pasko > >>>> > >>>> > >>> > >>> > >>> -- > >>> Mikhail Fursov > >> > >> > > > > -- > > Egor Pasko > > > > -- Egor Pasko
