# harmony-dev mailing list archives

##### Site index · List index
Message view
Top
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm] Status of drlvm
Date Wed, 19 Jul 2006 15:15:24 GMT
```Apparently segfault disappears if one replaces the "hyzlib" library
(which is compiled from re-distributed zlib at
modules\archive\src\main\native\zlib_dist) with the "natural" libz
which comes with the Linux installation (I'm using GCC 3.3.4 as well).
It seems there is still a conflict between drlvm which is linked to
libz.so and classlib which is linked to libhyzlib.so even if the
workaround HARMONY-853 is applied.

To use the natural zlib on Linux, I did the following:
- removed \$(DLLPATH)libhyzlib.so entry in MDLLIBFILES across
classlib's makefiles
- added  LDFLAGS = -lz to archive/linux/makefile.
- changed #define HY_ZIP_DLL_NAME to be "z" in
archive/src/main/native/include/shared/zipsup.h

Do people believe this is a right way to go?
Note that for Windows, we'll have either to :
- keep zlib compiled from zlib_dist, or
- download the binaries via "ant fetch-depends" similarly to the drlvm
build (it can be taken from http://www.zlib.net/zlib123-dll.zip).

What will be the preferences? I would stick to the second approach
since recompiling zlib seems to be an odd work.

Thanks,
Andrey.

On 7/19/06, Nataly Naumova <natalya.s.naumova@gmail.com> wrote:
>
> I've applied both patches, but `segfault` is reproducible nevertheless.
> gdb says that:
> (gdb) run Hello
> Starting program:
> /export/lab_drlbuild/test_tmp/20060719/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/ij
> Hello
> [New Thread 1083593376 (LWP 11375)]
> [New Thread 1425222576 (LWP 11477)]
> [New Thread 1427856304 (LWP 11479)]
> [New Thread 1430490032 (LWP 11480)]
> [New Thread 1433123760 (LWP 11482)]
> [New Thread 1446890416 (LWP 11489)]
> [New Thread 1450089392 (LWP 11508)]
> [New Thread 1453329328 (LWP 11509)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1453329328 (LWP 11509)]
> 0x40783aa2 in malloc_consolidate () from /lib/tls/libc.so.6
>
> Thamks.
> --
> Nataly Naumova,
> Intel Middleware Products Division
>
> On 7/18/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> > Nataly,
> >
> > I believe you need to accept both patches mentioned by Silikh in the initial
> > e-mail of this thread,
> > namely, H-898 & H-853. Could you please check if the 'seg fault' issue
> > disappears for gcc 3.3.4
> > as well?
> >
> > Thanks,
> >
> > On 7/18/06, Nataly Naumova <natalya.s.naumova@gmail.com> wrote:
> > >
> > > Vladimir and all,
> > > I've compiled with gcc 3.3.4 and received `seg faults` since July,08
> > > till now. I'm not applying any patches, and take just *pure* drlvm
> > > from SVN.
> > > DRLVM build for July,05 is fine, then the build was broken (on linux).
> > > Maybe we should look through the commits since July,05 till July 08 ?
> > > There were not too many commits there.
> > >
> > > Thanks.
> > >
> > > --
> > > Nataly Naumova,
> > > Intel Middleware Products Division
> > >
> > > On 7/18/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> > > > The reason of the 'seg fault' issue is clear for me now.
> > > > I see this issue occurs when I used the gcc of 3.4.2 version.
> > > > All works fine for the *gcc (GCC) 3.3.3 (SuSE Linux).*
> > > > Could anybody else confirm or deny this?
> > > >
> > > > Thanks in advance,
> > > > Vladimir.
> > > >
> > > > On 7/18/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> > > > >
> > > > >  Ignore please my previous e-mail. I was slightly mistaken :-(.
> > > > >
> > > > > Thanks,
> > > > >  Vladimir.
> > > > >
> > > > >
> > > > >  On 7/18/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> > > > > >
> > > > > >  Probably I've understood the reason of the segmentation fault
on
> > > Linux
> > > > > > platform.
> > > > > >
> > > > > > I almost sure it is related with the build system. An argument
why I
> > > > > > think so is the following.
> > > > > >
> > > > > > The basic_istringstream() class from the /usr/include/g++/sstream
> > > > > > include should be used
> > > > > >
> > > > > > to construct the configuration environment for the execution
manager
> > > > > > (vm/em/src/DrlEMIml.cpp file).
> > > > > >
> > > > > > However the recent build uses this class from the
> > > > > > /usr/lib/libstdc++.so.5 library instead and as a result
> > > > > >
> > > > > > DRLVM fails. I'm going to continue this investigation and prepare
a
> > > > > > patch to fix this issue
> > > > > >
> > > > > > if someone doesn't already know how. Volunteers?
> > > > > >
> > > > > > Thanks,
> > > > > >  Vladimir.
> > > > > >
> > > > > >
> > > > > >  On 7/18/06, Andrey Chernyshev < a.y.chernyshev@gmail.com>
wrote:
> > > > > > >
> > > > > > > On 7/17/06, Vladimir Gorr < vvgorr@gmail.com> wrote:
> > > > > > > > On 7/17/06, Salikh Zakirov < Salikh.Zakirov@intel.com>
wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Can anyone share their experience on running
DRLVM built from
> > > SVN?
> > > > > > > > >
> > > > > > > > > On my workstations, it requires several fixes
in order to run
> > > > > > > properly:
> > > > > > > > >
> > > > > > > > > HARMONY-898 'workaround to get correct hythr.dll'
(both for
> > > Linux
> > > > > > > and
> > > > > > > > > Windows)
> > > > > > > > > HARMONY-853 'DRLVM+classlib segfaults in hyzlib'
(on Linux)
> > > > > > > > >
> > > > > > > > > Without HARMONY-898, DRLVM segfaults after reading
NULL from
> > > TLS.
> > > > > > > > > Without HARMONY-853, DRLVM segfaults in libhyzlib.so
on Linux.
> > > > > > > > >
> > > > > > > > > I would suggest that the patches from HARMONY-898
and
> > > HARMONY-853
> > > > > > > be
> > > > > > > > > applied,
> > > > > > > > > because DRLVM doesn't work at all for me without
these fixes.
> > > > > > > > >
> > > > > > > > > Any other experiences? Is anyone besides me running
DRLVM from
> > > > > > > SVN?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I've built the DRLVM on Linux for the following cases:
> > > > > > > >
> > > > > > > > 1. w/o patches listed above;
> > > > > > > >
> > > > > > > > 2. w/ H-898 patch;
> > > > > > > >
> > > > > > > > 3. w/ H-898 & H-853 patches.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 'Segmentation fault' occurs for all cases, unfortunately.
> > > > > > > >
> > > > > > >
> > > > > > > I was able to run most of smoke tests on Linux a few days
ago, but
> > > now
> > > > > > >
> > > > > > > I'm having the same segfault failure.
> > > > > > > Some observations are:
> > > > > > >
> > > > > > > - In the interpreted mode (-Xint option) it reports
> > > > > > > ClassNotFoundException, so
> > > > > > > it seems VM can no longer load the classes from jars on
Linux. I
> > > was
> > > > > > > able to run
> > > > > > > a single "Hello" class though.
> > > > > > >
> > > > > > > - Segfault actually happens during VM shutdown, after the
main()
> > > is
> > > > > > > already completed with CNFE error. I wasn't able to find
the exact
> > > > > > > point of segfault though - it seems it happens somewhere
in a
> > > jitted
> > > > > > > code, gdb doesn't show a much of useful info in that case:
> > > > > > >
> > > > > > > #0  0x40788aa2 in malloc_consolidate () from /lib/tls/libc.so.6
> > > > > > > #1  0x00000010 in ?? ()
> > > > > > > #2  0x4083c7c8 in main_arena () from /lib/tls/libc.so.6
> > > > > > > #3  0x00000000 in ?? ()
> > > > > > > #4  0x4083c7b4 in main_arena () from /lib/tls/libc.so.6
> > > > > > > #5  0x4083c798 in main_arena () from /lib/tls/libc.so.6
> > > > > > > #6  0x4083c780 in __malloc_initialize_hook () from
> > > /lib/tls/libc.so.6
> > > > > > > #7  0x4083aff4 in ?? () from /lib/tls/libc.so.6
> > > > > > > #8  0x0855cdd0 in ?? ()
> > > > > > > #9  0x00037230 in ?? ()
> > > > > > > #10 0x56500158 in ?? ()
> > > > > > > #11 0x40789bf6 in _int_free () from /lib/tls/libc.so.6
> > > > > > > Previous frame inner to this frame (corrupt stack?)
> > > > > > >
> > > > > > > I'm continuing investigation, the same behavior is observed
on
> > > Linux
> > > > > > > if run with classlib's launcher.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrey.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Vladimir.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > Terms of use :
> > > http://incubator.apache.org/harmony/mailing.html
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > harmony-dev-unsubscribe@incubator.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > > > > > harmony-dev-help@incubator.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrey Chernyshev
> > > > > > > Intel Middleware Products Division
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > > > > To unsubscribe, e-mail:
> > > harmony-dev-unsubscribe@incubator.apache.org
> > > > > > > For additional commands, e-mail:
> > > harmony-dev-help@incubator.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

--
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------