You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Enrico Migliore <en...@fatti.com> on 2006/04/06 17:04:46 UTC
[sablevm] SIGSEGV signal received from Cygwin
Hi,
I'm doing some testing on SableVM, and noticed that is receives the very
same segmentation fault signal that JCHEVM does, from
pthread_key_create() which is embedded in:
/usr/bin/cygwin1.dll
I read around that this problem could be fixed, but the error means that
the Cygwin platform can only be used for developing, studying and
testing and not for real world use.
Let me recap the problems we face when trying to port JCHEVM and SableVM
on Windows:
problem 1: POSIX dependancy
---------------------------------
The code contains a certain number of POSIX calls (dependancies). Much
of them can be easily replaced, but some might be hard to replace.
problem 2: GCC extensions
-----------------------------
The code contains some GCC extensions which are not ANSI.
problem 3: Which compiler?
-----------------------------
GCC seems to be the best candidate but MSVC is more popular.
problem 4: Native code dependancies
---------------------------------------
The Harmony class library depends on the port layer:
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
Is this layer available for MSVC?
Enrico
---------------------------------------------------------------------
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
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Etienne Gagnon <eg...@sablevm.org>.
Enrico Migliore wrote:
> Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string
> in a struct in order not to receive that signal,
> therefore, I'm pretty much sure that somewhere in the Pthread library
> there's an access to an area used to initialize constants:
> something that maybe GCC likes but Windows doesn't.
> That's just a guess.
I have to look more carfully to the port library, and see what thread
supports it provides. I've had lots of professorish things to do over
the last days, so I didn't get enough time to look deeply. I'll get
back to you about it.
> The documentation included in SableVM trunk is more than good.
> Therefore, I would like to try do this job. I'm not sure I'll succeed
> but I want to
>
> As far as the port is concerned, there are 3 things to talk about:
>
> build system in MSVC
> -----------------------
> to my knowledge, MSVC doesn't have a build system like UNIX (autotool +
> configure) therefore, I think that the "config.h" file will have to be
> built manually.
This shouldn't be too much of a problem. SableVM has no intrinsict
dependence on auto* tools. It does, however, require m4. This could be
eliminated if we decided to allow for a Java dependency for building
(i.e. ant & sablecc-based code generator).
Yet, on shorter term, some simpler make file is feasible. All you
actually need to build is libsablevm.dll. There's no need for the
sablevm launcher; we already know that the harmony one works, and it is
much more complete...
> how to modify the source files?
> ------------------------------
> Let's say that removing a POSIX dependancy in a SableVM file means:
> replacing some lines of codes and replacing some include files. How am I
> suppost to deal with this kind of thing? Should I modify the trunk or my
> sandbox?
Ideally, initial work should happen in your sandbox. This way you can
use it to do backups of your code, even when it doesn't compile, without
disturbing anybody.
I am playing with the idea of making a copy of current trunk in
sablevm/branches/last-stable, and simply allowing for a broken trunk
during the Harmony transition (not as broken as a typical sandbox;
should at least compile).
We have a strict policy on using the "svn merge" operation. We can
discuss it the day you need it.
> how to track source modifications
> ----------------------------------
> Let's say that one source file gets modified by one of SableVM
> developers, and another is added to the trunk. Should I rely on SVN to
> know where the modifications were done?
Not sure I understand the question... Developers may only checkin code
they wrote themselves. This way, svn keeps a clear history of who wrote
what.
I think this discussion should probably continue on sablevm-devel@, as
not to add too much noise into harmony-dev@. We could, there, discuss
of work distribution among you, hadrien and me, as well as any other
interested contributor, to get a working sablevm+harmony duo as soon and
as cleanly as possible.
We should come back to this list for any topic related to the class-lib
and port library side of things.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Etienne,
>Enrico Migliore wrote:
>
>
>>I debugged the classical HelloWorld class with DDD and found the problem
>>in the following function:
>>
>>_svmf_init(void)
>>{
>>pthread_once(...); <---- SEGSEGV signal
>>
>>
>
>That's definitely a cygwin bug. I see.
>
>
>
The SEGSEGV signal is issued by Windows when the program does an
"Illegal storage access".
The following simple example does receive the signal:
void my_function (char *pippo)
{
pippo[0] = '\0';
}
int main (int argc, char** argv)
{
my_function("Hello World");
return 0;
}
Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string
in a struct in order not to receive that signal,
therefore, I'm pretty much sure that somewhere in the Pthread library
there's an access to an area used to initialize constants:
something that maybe GCC likes but Windows doesn't.
That's just a guess.
>>In any case, before starting the port, I think that I and the people who
>>would like to help, will have analyze the code file by file.
>>
>>
>
>Actually, you should really start looking at:
>
> src/libsablevm/include/jni_system_specific.h
> src/libsablevm/system.c
> src/libsablevm/system.h
>
>These are the files which contain system-specific code. Outside of
>these files, the only real dependencies are POSIX calls. [I think
>there's some exception in System.getCurrentMillis() implementation that
>shouldn't even be in the VM to start with, as there's no VM-specific
>functionality in it... I had to live with Classpath's decisions on
>their VM interface.]
>
>If you really want to read every single source file (!), then you should
>definitely:
>0.1) [prerequisite] read the JVMS fully, a few times over
>0.2) [prerequisite] read the JNI spec fully, a few times over
>1) read my Ph.D. thesis
>2) read the documents in doc/
>3) ask questions on sablevm-devel@ for clarifications
>
>Going that deep shouldn't be necessary, though. Identifying POSIX
>dependencies and replacing them with VMI-port calls should be sufficient
>to start with.
>
>Etienne
>
>
The documentation included in SableVM trunk is more than good.
Therefore, I would like to try do this job. I'm not sure I'll succeed
but I want to
As far as the port is concerned, there are 3 things to talk about:
build system in MSVC
-----------------------
to my knowledge, MSVC doesn't have a build system like UNIX (autotool +
configure) therefore, I think that the "config.h" file will have to be
built manually.
how to modify the source files?
------------------------------
Let's say that removing a POSIX dependancy in a SableVM file means:
replacing some lines of codes and replacing some include files. How am I
suppost to deal with this kind of thing? Should I modify the trunk or my
sandbox?
how to track source modifications
----------------------------------
Let's say that one source file gets modified by one of SableVM
developers, and another is added to the trunk. Should I rely on SVN to
know where the modifications were done?
ciao,
Enrico
---------------------------------------------------------------------
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
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Etienne Gagnon <eg...@sablevm.org>.
Enrico Migliore wrote:
> I debugged the classical HelloWorld class with DDD and found the problem
> in the following function:
>
> _svmf_init(void)
> {
> pthread_once(...); <---- SEGSEGV signal
That's definitely a cygwin bug. I see.
>>> problem 1: POSIX dependancy
>>> ---------------------------------
>>>...
>> I think that moving to Harmony's port library should solve this. I
>> agree that it shouldn't be hard to fix.
>>
> Are you referring to the work-in-progress that is adapting SableVM to
> the VMI?
Yep.
>>> problem 2: GCC extensions
>>> -----------------------------
>>...
>> this: use Hans Boehm's atomic_ops library to get this code out of
>> SableVM. See:
>>
>> http://sablevm.org/bugs/179
Just FYI, fixing this is a short term objective. (i.e. work in progress).
> In any case, before starting the port, I think that I and the people who
> would like to help, will have analyze the code file by file.
Actually, you should really start looking at:
src/libsablevm/include/jni_system_specific.h
src/libsablevm/system.c
src/libsablevm/system.h
These are the files which contain system-specific code. Outside of
these files, the only real dependencies are POSIX calls. [I think
there's some exception in System.getCurrentMillis() implementation that
shouldn't even be in the VM to start with, as there's no VM-specific
functionality in it... I had to live with Classpath's decisions on
their VM interface.]
If you really want to read every single source file (!), then you should
definitely:
0.1) [prerequisite] read the JVMS fully, a few times over
0.2) [prerequisite] read the JNI spec fully, a few times over
1) read my Ph.D. thesis
2) read the documents in doc/
3) ask questions on sablevm-devel@ for clarifications
Going that deep shouldn't be necessary, though. Identifying POSIX
dependencies and replacing them with VMI-port calls should be sufficient
to start with.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Etienne,
>Enrico Migliore wrote:
>
>
>>I'm doing some testing on SableVM, and noticed that is receives the very
>>same segmentation fault signal that JCHEVM does, from
>>pthread_key_create() which is embedded in:
>>
>>/usr/bin/cygwin1.dll
>>
>>I read around that this problem could be fixed, but the error means that
>>the Cygwin platform can only be used for developing, studying and
>>testing and not for real world use.
>>
>>
>
>Can you expand a little on this. I am not sure what you mean.
>
>
>
I debugged the classical HelloWorld class with DDD and found the problem
in the following function:
_svmf_init(void)
{
pthread_once(...); <---- SEGSEGV signal
....
}
>>problem 1: POSIX dependancy
>>---------------------------------
>>The code contains a certain number of POSIX calls (dependancies). Much
>>of them can be easily replaced, but some might be hard to replace.
>>
>>
>
>I think that moving to Harmony's port library should solve this. I
>agree that it shouldn't be hard to fix.
>
>
Are you referring to the work-in-progress that is adapting SableVM to
the VMI?
>
>
>>problem 2: GCC extensions
>>-----------------------------
>>The code contains some GCC extensions which are not ANSI.
>>
>>
>
>When compiling a switch interpreter (--with-treading=switch), there
>shouldn't be GCC extensions. The only exception is atomic operations
>which cannot be expressed in C. Yet, I've found an elegant solution to
>this: use Hans Boehm's atomic_ops library to get this code out of
>SableVM. See:
>
> http://sablevm.org/bugs/179
>
>
Ok
>
>
>>problem 3: Which compiler?
>>-----------------------------
>>GCC seems to be the best candidate but MSVC is more popular.
>>
>>
>
>Ideally, I'd like both to work. Getting the faster direct/inlined
>interpreters to work with MSVC might be tricky (require inline assembly
>or linking to an asm library), but the switch interpreter shouldn't be a
>problem.
>
>
>
I see what you're saying....
>>problem 4: Native code dependancies
>>---------------------------------------
>>The Harmony class library depends on the port layer:
>>
>>http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
>>
>>
>
>Yep, using this layer and atomic_ops should hopefully be sufficient to
>remove all system-specific dependencies. If anything is missing, we
>should probably abstract it into the port layer.
>
>
>
In any case, before starting the port, I think that I and the people who
would like to help, will have analyze the code file by file.
>Now, the interesting thing would be for Harmony native code to compile
>and work on something other than ia32. SableVM already works on pretty
>much anything (using gcc, so far), as long as libffi and GNU classpath
>compiles on the target. The only other limitation is 2 operations that
>cannot be expressed in C: compare_and_swap and clear_cache.
>
>Etienne
>
>
>
That's another reasonable goal :-)
Enrico
---------------------------------------------------------------------
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
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Etienne Gagnon <eg...@sablevm.org>.
Enrico Migliore wrote:
> I'm doing some testing on SableVM, and noticed that is receives the very
> same segmentation fault signal that JCHEVM does, from
> pthread_key_create() which is embedded in:
>
> /usr/bin/cygwin1.dll
>
> I read around that this problem could be fixed, but the error means that
> the Cygwin platform can only be used for developing, studying and
> testing and not for real world use.
Can you expand a little on this. I am not sure what you mean.
> problem 1: POSIX dependancy
> ---------------------------------
> The code contains a certain number of POSIX calls (dependancies). Much
> of them can be easily replaced, but some might be hard to replace.
I think that moving to Harmony's port library should solve this. I
agree that it shouldn't be hard to fix.
> problem 2: GCC extensions
> -----------------------------
> The code contains some GCC extensions which are not ANSI.
When compiling a switch interpreter (--with-treading=switch), there
shouldn't be GCC extensions. The only exception is atomic operations
which cannot be expressed in C. Yet, I've found an elegant solution to
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM. See:
http://sablevm.org/bugs/179
> problem 3: Which compiler?
> -----------------------------
> GCC seems to be the best candidate but MSVC is more popular.
Ideally, I'd like both to work. Getting the faster direct/inlined
interpreters to work with MSVC might be tricky (require inline assembly
or linking to an asm library), but the switch interpreter shouldn't be a
problem.
> problem 4: Native code dependancies
> ---------------------------------------
> The Harmony class library depends on the port layer:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
Yep, using this layer and atomic_ops should hopefully be sufficient to
remove all system-specific dependencies. If anything is missing, we
should probably abstract it into the port layer.
Now, the interesting thing would be for Harmony native code to compile
and work on something other than ia32. SableVM already works on pretty
much anything (using gcc, so far), as long as libffi and GNU classpath
compiles on the target. The only other limitation is 2 operations that
cannot be expressed in C: compare_and_swap and clear_cache.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [port library] windows manager
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/4/7, Enrico Migliore <en...@fatti.com>:
>
> >>Does instead, the port library for UNIX support any windows manager?
> >
> >AFAIK you generally choose a windowing manager and code to it -- I'm
> >unaware of any cross-manager port libraries (but I'm not a UI person so
> >there may well be such a thing).
There is a wxWindows cross platform C++ library but it has a very big
abstraction layer overhead on top of platform APIs. Also there is GTK+ which
has a win32 port and some linux native applications like gimp and xchat have
win32 native ports to windows. QT is also free for non profit usage, but
only for non-profit.
I see what you are saying: all windowing native issues are managed by
> SWT or AWT, therefore the port library dosen't include and windowing
> native functions. Right?
I am not a UI person as well but as far as I know you are right. Porting
layers for UI are huge and not trivial, and there is nothing about UI in the
port library.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [port library] windows manager
Posted by Enrico Migliore <en...@fatti.com>.
Hi Tim,
>Of course, the plan is for Harmony to have AWT and Swing code.
>
>
>
Ok
>>Does instead, the port library for UNIX support any windows manager?
>>
>>
>
>AFAIK you generally choose a windowing manager and code to it -- I'm
>unaware of any cross-manager port libraries (but I'm not a UI person so
>there may well be such a thing).
>
>Regards,
>Tim
>
>
>
I see what you are saying: all windowing native issues are managed by
SWT or AWT, therefore the port library dosen't include and windowing
native functions. Right?
Enrico
---------------------------------------------------------------------
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
Re: [port library] windows manager
Posted by Tim Ellison <t....@gmail.com>.
Enrico Migliore wrote:
>> Enrico Migliore wrote:
>>> does the MSVC port library support the windowing system of Windows?
>>
>> No (but I can recommend SWT as a cross-platform windowing model ;-) )
>>
> the consequence of that is that, at the moment, the Harmony Class
> Library can only support console based applications, right?
Well we can't run apps that require AWT or Swing at the moment, but we
can run GUI apps (like Eclipse and RSSOwl) that are SWT-based.
Of course, the plan is for Harmony to have AWT and Swing code.
> I don't get exactly how and in which terms we can use the SWT
> (cross-platform GUI develiped by IBM)....
SWT is available under the EPL. I was only teasing though, it is not a
solution for our need to write the JSE windowing libraries.
> Does instead, the port library for UNIX support any windows manager?
AFAIK you generally choose a windowing manager and code to it -- I'm
unaware of any cross-manager port libraries (but I'm not a UI person so
there may well be such a thing).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [port library] windows manager
Posted by Enrico Migliore <en...@fatti.com>.
Hi Tim,
>Enrico Migliore wrote:
>
>
>>does the MSVC port library support the windowing system of Windows?
>>
>>
>
>No (but I can recommend SWT as a cross-platform windowing model ;-) )
>
>
>
the consequence of that is that, at the moment, the Harmony Class
Library can only support console based applications, right?
I don't get exactly how and in which terms we can use the SWT
(cross-platform GUI develiped by IBM)....
Does instead, the port library for UNIX support any windows manager?
>>And yet, what happened to the proposal of using the Apache Portable
>>Runtime as an interface to the native layer?
>>
>>
>
>I believe it remains a proposal. Artem Aliev did some work on using APR
>as a portability layer (by coding the Harmony portlib to APR) in late
>February, and reported his findings to the list[1]. AFAIK nobody has
>continued this work.
>
>[1]
>http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c187bb05d0602221037i50d755bdrbb30f95fcfc718ab@mail.gmail.com%3e
>
>Regards,
>Tim
>
>
I see....
ciao,
Enrico
---------------------------------------------------------------------
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
Re: [port library] windows manager
Posted by Tim Ellison <t....@gmail.com>.
Enrico Migliore wrote:
> does the MSVC port library support the windowing system of Windows?
No (but I can recommend SWT as a cross-platform windowing model ;-) )
> And yet, what happened to the proposal of using the Apache Portable
> Runtime as an interface to the native layer?
I believe it remains a proposal. Artem Aliev did some work on using APR
as a portability layer (by coding the Harmony portlib to APR) in late
February, and reported his findings to the list[1]. AFAIK nobody has
continued this work.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c187bb05d0602221037i50d755bdrbb30f95fcfc718ab@mail.gmail.com%3e
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
[port library] windows manager
Posted by Enrico Migliore <en...@fatti.com>.
Tim Ellison wrote:
>Enrico Migliore wrote:
><snip>
>
>
>>problem 4: Native code dependancies
>>---------------------------------------
>>The Harmony class library depends on the port layer:
>>
>>http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
>>
>>
>>Is this layer available for MSVC?
>>
>>
>
>Yes it is written using MSVC (and in fact would require some
>modification to make it work with gcc on Windows).
>
>Regards,
>Tim
>
>
>
Hi Tim,
does the MSVC port library support the windowing system of Windows?
And yet, what happened to the proposal of using the Apache Portable
Runtime as an interface to the native layer?
Enrico
---------------------------------------------------------------------
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
Re: [sablevm] SIGSEGV signal received from Cygwin
Posted by Tim Ellison <t....@gmail.com>.
Enrico Migliore wrote:
<snip>
> problem 4: Native code dependancies
> ---------------------------------------
> The Harmony class library depends on the port layer:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
>
>
> Is this layer available for MSVC?
Yes it is written using MSVC (and in fact would require some
modification to make it work with gcc on Windows).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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