I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently.
It could be a side effect of the recent adoption of DRLVM build for classlib binaries. The trick is that drlvm should put it's own hythread library into the deploy JRE. Before that change drlvm wasn't building the original hythread library at all, but now libhythr.so is copied from the class libraries into the deploy directory along with all other native class libraries. There could be two ways to resolve it: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; (b) More graceful fix - split the "process.components" target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the "build" target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. Thanks, Andrey. On 6/30/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Friday 30 June 2006 21:39 Salikh Zakirov wrote: > Zakirov, Salikh wrote: > > By the way, there are some other issues with current state of DRLVM, > > as the following smoke tests (run by 'build.sh test') fail on > > Linux/ia32: > > > > util.DoPrivileged > > classloader.LogLoader > > classloader.SysRes > > > > I'm going to bisect recent commits to find the failure cause. > > The bisection haven't helped at all, since the older versions > of DRLVM reproduce the same errors or do not work at all > (with fixed class library version: latest). > > The above tests are failing with segfault in hythr library, > > #0 0x54e48c28 in hythread_tls_get (thread=0x0, key=1) > at ../../shared/thread/hythreadinspect.c:134 > #1 0x54f8d609 in hyport_tls_get (portLibrary=0x54f97ae0) > at ../../shared/port/hytlshelpers.c:52 > #2 0x54f8e57d in hyerror_set_last_error (portLibrary=0x54f97ae0, > platformCode=2, portableCode=-308) at ../../shared/port/hyerror.c:231 > > after reading NULL thread pointer from TLS. > > Apparently, hythread_attach() isn't called anywhere in the DRLVM, > but is required for some classlib functions in order to work properly. > > I've seen no major changes to thread files in CLASSLIB, > so it makes me wonder why this has broken in DRLVM? > > I have also found that DRLVM's drop-in replacement of libhythr.so is > no longer built or installed into jre/bin. I've just found the same problem. When everything is built from the scratch or after "build.sh clean" the hythr library in DRLVM deploy repository is correct. When the build is incremental the hythr library is taken from classlib. You can replace it manually from lnx_ia32_gcc_debug/semis/vm/hythr/_bin location. I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. -- 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]
-- Andrey Chernyshev 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]
