You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2009/03/24 15:10:43 UTC
Remaining M9 issues
I'm trying to catch up on the remaining M9 blockers, and have gleaned
the following, please correct me where I'm wrong, or provide more info.
The goal is to ensure we have no regressions, not that we fix all known
bugs in this milestone.
- Blockers -
1. RMI test failures on Linux [HARMONY-6090, 6091 and 6092 provide a
partial fix to this, but tests still fail intermittently]
?JIRA? Regression?
2. hymem.exe crashes on Vista
?JIRA? Regression?
3. Various AWT/Swing crashes/ failures
?JIRA? Regression?
4. Dacapo benchmark failure HARMONY-6041
Regression caused by patch in r727327. Propose Regis fix or roll-back
this patch.
- Non-blockers -
1. HttpURLConnectionTest and HttpsURLConnectionTest fail on some
systems [Test issue - fix available from Regis in HARMONY-6120 but may
not be committed until after M9]
Test case problem. Fix for test available but not committed.
2. org.apache.harmony.archive.tests.java.util.jar.ManifestTest fails
on Windows XP [Tim is working on this]
Fixed.
3. VM crash in classlib tests on Linux -
org.apache.harmony.luni.tests.java.net.MulticastSocketTest and
org.apache.harmony.xnet.provider.jsse.SSLSocketImplTest
Chunrong identified cause as r691267.
Not a regression from M8.
4. Classlib test failures on Vista in
org.apache.harmony.luni.tests.java.net.MulticastSocketTest
and org.apache.harmony.luni.tests.java.net.SocketTest [Firewall issue?]
Identified as firewall problem.
Re: Remaining M9 issues
Posted by Sian January <si...@googlemail.com>.
Looking in the mail archives we have allowed Swing/AWT crashes through
before (e.g. http://mail-archives.apache.org/mod_mbox/harmony-dev/200811.mbox/%3C49138D1F.10305@gmail.com%3E)
but that mail doesn't state explicitly what the crashes were so it's
hard to know if there's anything new. However there has been no
active development in Swing or AWT since M8 so IMHO it's more likely
that the tests are unreliable or there are intermittent failures than
that there are regressions.
2009/3/24 Tim Ellison <t....@gmail.com>:
> I'm trying to catch up on the remaining M9 blockers, and have gleaned
> the following, please correct me where I'm wrong, or provide more info.
> The goal is to ensure we have no regressions, not that we fix all known
> bugs in this milestone.
>
>
> - Blockers -
>
> 1. RMI test failures on Linux [HARMONY-6090, 6091 and 6092 provide a
> partial fix to this, but tests still fail intermittently]
>
> ?JIRA? Regression?
>
> 2. hymem.exe crashes on Vista
>
> ?JIRA? Regression?
>
> 3. Various AWT/Swing crashes/ failures
>
> ?JIRA? Regression?
>
> 4. Dacapo benchmark failure HARMONY-6041
>
> Regression caused by patch in r727327. Propose Regis fix or roll-back
> this patch.
>
>
>
> - Non-blockers -
>
>
> 1. HttpURLConnectionTest and HttpsURLConnectionTest fail on some
> systems [Test issue - fix available from Regis in HARMONY-6120 but may
> not be committed until after M9]
>
> Test case problem. Fix for test available but not committed.
>
>
> 2. org.apache.harmony.archive.tests.java.util.jar.ManifestTest fails
> on Windows XP [Tim is working on this]
>
> Fixed.
>
>
> 3. VM crash in classlib tests on Linux -
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest and
> org.apache.harmony.xnet.provider.jsse.SSLSocketImplTest
>
> Chunrong identified cause as r691267.
> Not a regression from M8.
>
>
> 4. Classlib test failures on Vista in
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest
> and org.apache.harmony.luni.tests.java.net.SocketTest [Firewall issue?]
>
> Identified as firewall problem.
>
>
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Remaining M9 issues
Posted by Sian January <si...@googlemail.com>.
2009/3/24 Tim Ellison <t....@gmail.com>:
> I'm trying to catch up on the remaining M9 blockers, and have gleaned
> the following, please correct me where I'm wrong, or provide more info.
> The goal is to ensure we have no regressions, not that we fix all known
> bugs in this milestone.
>
>
> - Blockers -
>
> 1. RMI test failures on Linux [HARMONY-6090, 6091 and 6092 provide a
> partial fix to this, but tests still fail intermittently]
>
> ?JIRA? Regression?
>
> 2. hymem.exe crashes on Vista
>
> ?JIRA? Regression?
>
> 3. Various AWT/Swing crashes/ failures
>
> ?JIRA? Regression?
>
> 4. Dacapo benchmark failure HARMONY-6041
>
> Regression caused by patch in r727327. Propose Regis fix or roll-back
> this patch.
>
>
>
> - Non-blockers -
>
>
> 1. HttpURLConnectionTest and HttpsURLConnectionTest fail on some
> systems [Test issue - fix available from Regis in HARMONY-6120 but may
> not be committed until after M9]
>
> Test case problem. Fix for test available but not committed.
>
>
> 2. org.apache.harmony.archive.tests.java.util.jar.ManifestTest fails
> on Windows XP [Tim is working on this]
>
> Fixed.
>
>
> 3. VM crash in classlib tests on Linux -
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest and
> org.apache.harmony.xnet.provider.jsse.SSLSocketImplTest
>
> Chunrong identified cause as r691267.
> Not a regression from M8.
Chunrong - would you be able to open a JIRA for this if there isn't
one already? It would be good to get it fixed for M10.
>
>
> 4. Classlib test failures on Vista in
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest
> and org.apache.harmony.luni.tests.java.net.SocketTest [Firewall issue?]
>
> Identified as firewall problem.
>
>
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Remaining M9 issues
Posted by Nathan Beyer <nd...@apache.org>.
2009/3/25 Alexei Fedotov <al...@gmail.com>:
> Nathan,
> I have just thrown a ping to Rustem. Even if found, this tool hardly
> can be donated without upper level managerial support. Maybe Xiao Feng
> would help us.
Even if we can't get the actual tool - it would be nice to know more
about what it did and what input was used.
>
> Honestly, I'm reluctant native bridge supporter myself. I dare to
> think of it as another layer of wrappers. Removing the wrappers would
> result in more compact code. I see the only viable argument in the
> native bridge defense is "java is easier, why should we use C".
>
> Thanks.
>
>
> On Thu, Mar 26, 2009 at 4:52 AM, Nathan Beyer <nd...@apache.org> wrote:
>> On Wed, Mar 25, 2009 at 2:53 PM, Mark Hindess
>> <ma...@googlemail.com> wrote:
>>>
>>> In message <33...@gmail.com>, Nathan Beyer
>>> writes:
>>>>
>>>> On Mar 25, 2009, at 5:40 AM, Tim Ellison <t....@gmail.com> wrote:
>>>>
>>>> > Nathan Beyer wrote:
>>>> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
>>>> >> <t....@gmail.com> wrote:
>>>> >>> 3. Various AWT/Swing crashes/ failures
>>>> >>
>>>> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
>>>> >> https://issues.apache.org/jira/browse/HARMONY-6123
>>>> >
>>>> > Looks like a problem in the X.11 libraries, and looking around it
>>>> > seems that we are far from the only ones who have uncovered this problem.
>>>> >
>>>> Agreed, but I got the impression that the new behavior is considered
>>>> correct and it will be up to apps to fix their own code. Have you
>>>> found any indication to the contrary?
>>>
>>> Well, there have been mistakes in the past - such as nested locking not
>>> working as documented in the XLockDisplay man page and with locks being
>>> held by the toolkit when user callbacks were invoked - but I think it is
>>> quite likely that we need to do something to fix this.
>>>
>>> We currently call XInitThreads to allow multi-threaded support but we
>>> do not actually seem to call XLockDisplay. I don't think this can be
>>> correct though I don't know which xlib calls need to be locking - I'm
>>> guessing at least the two mentioned in your JIRA. If we had access
>>> to the native bridge tool, we could probably make a safe fix of just
>>> wrapping all Xlib calls with a lock but that would probably be overkill.
>>> Having access to the native bridge tool would be useful anyway.[0]
>>
>> Is anyone from Intel still around that could provide some insight into
>> the 'native bridge tool'? Anyone know who we could contact to maybe
>> get some more information? This would help out with some of the Vista
>> issues I'm seeing in Swing as well.
>>
>>>
>>> I will try to get an ubuntu 8.10 kvm image installed and have a look at this
>>> problem but since awt/swing are not really a priority for me.
>>>
>>>> > Since it is not a regression, and apparently not caused by anything we
>>>> > can fix (unless we can find a workaround), I propose that we declare
>>>> > it a "Non-Blocker" for M9.
>>>
>>> +1
>>>
>>>> I'm fine with that. Maybe indicate it is a known issue.
>>>
>>> 1+ It should be mentioned in the release notes.
>>>
>>> Regards,
>>> Mark.
>>>
>>> [0] I think there are some modularity problems lurking here... I think
>>> luni depends on the org.apache.harmony.misc.accessors which depends on
>>> some native bridge code in awt. I suspect the common native bridge
>>> probably should be brought back in to the misc module.
>>>
>>>
>>>
>>
>
>
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://www.telecom-express.ru/
> http://people.apache.org/~aaf/
>
Re: Remaining M9 issues
Posted by Alexei Fedotov <al...@gmail.com>.
Nathan,
I have just thrown a ping to Rustem. Even if found, this tool hardly
can be donated without upper level managerial support. Maybe Xiao Feng
would help us.
Honestly, I'm reluctant native bridge supporter myself. I dare to
think of it as another layer of wrappers. Removing the wrappers would
result in more compact code. I see the only viable argument in the
native bridge defense is "java is easier, why should we use C".
Thanks.
On Thu, Mar 26, 2009 at 4:52 AM, Nathan Beyer <nd...@apache.org> wrote:
> On Wed, Mar 25, 2009 at 2:53 PM, Mark Hindess
> <ma...@googlemail.com> wrote:
>>
>> In message <33...@gmail.com>, Nathan Beyer
>> writes:
>>>
>>> On Mar 25, 2009, at 5:40 AM, Tim Ellison <t....@gmail.com> wrote:
>>>
>>> > Nathan Beyer wrote:
>>> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
>>> >> <t....@gmail.com> wrote:
>>> >>> 3. Various AWT/Swing crashes/ failures
>>> >>
>>> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
>>> >> https://issues.apache.org/jira/browse/HARMONY-6123
>>> >
>>> > Looks like a problem in the X.11 libraries, and looking around it
>>> > seems that we are far from the only ones who have uncovered this problem.
>>> >
>>> Agreed, but I got the impression that the new behavior is considered
>>> correct and it will be up to apps to fix their own code. Have you
>>> found any indication to the contrary?
>>
>> Well, there have been mistakes in the past - such as nested locking not
>> working as documented in the XLockDisplay man page and with locks being
>> held by the toolkit when user callbacks were invoked - but I think it is
>> quite likely that we need to do something to fix this.
>>
>> We currently call XInitThreads to allow multi-threaded support but we
>> do not actually seem to call XLockDisplay. I don't think this can be
>> correct though I don't know which xlib calls need to be locking - I'm
>> guessing at least the two mentioned in your JIRA. If we had access
>> to the native bridge tool, we could probably make a safe fix of just
>> wrapping all Xlib calls with a lock but that would probably be overkill.
>> Having access to the native bridge tool would be useful anyway.[0]
>
> Is anyone from Intel still around that could provide some insight into
> the 'native bridge tool'? Anyone know who we could contact to maybe
> get some more information? This would help out with some of the Vista
> issues I'm seeing in Swing as well.
>
>>
>> I will try to get an ubuntu 8.10 kvm image installed and have a look at this
>> problem but since awt/swing are not really a priority for me.
>>
>>> > Since it is not a regression, and apparently not caused by anything we
>>> > can fix (unless we can find a workaround), I propose that we declare
>>> > it a "Non-Blocker" for M9.
>>
>> +1
>>
>>> I'm fine with that. Maybe indicate it is a known issue.
>>
>> 1+ It should be mentioned in the release notes.
>>
>> Regards,
>> Mark.
>>
>> [0] I think there are some modularity problems lurking here... I think
>> luni depends on the org.apache.harmony.misc.accessors which depends on
>> some native bridge code in awt. I suspect the common native bridge
>> probably should be brought back in to the misc module.
>>
>>
>>
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://people.apache.org/~aaf/
Re: Remaining M9 issues
Posted by Nathan Beyer <nd...@apache.org>.
On Wed, Mar 25, 2009 at 2:53 PM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> In message <33...@gmail.com>, Nathan Beyer
> writes:
>>
>> On Mar 25, 2009, at 5:40 AM, Tim Ellison <t....@gmail.com> wrote:
>>
>> > Nathan Beyer wrote:
>> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
>> >> <t....@gmail.com> wrote:
>> >>> 3. Various AWT/Swing crashes/ failures
>> >>
>> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
>> >> https://issues.apache.org/jira/browse/HARMONY-6123
>> >
>> > Looks like a problem in the X.11 libraries, and looking around it
>> > seems that we are far from the only ones who have uncovered this problem.
>> >
>> Agreed, but I got the impression that the new behavior is considered
>> correct and it will be up to apps to fix their own code. Have you
>> found any indication to the contrary?
>
> Well, there have been mistakes in the past - such as nested locking not
> working as documented in the XLockDisplay man page and with locks being
> held by the toolkit when user callbacks were invoked - but I think it is
> quite likely that we need to do something to fix this.
>
> We currently call XInitThreads to allow multi-threaded support but we
> do not actually seem to call XLockDisplay. I don't think this can be
> correct though I don't know which xlib calls need to be locking - I'm
> guessing at least the two mentioned in your JIRA. If we had access
> to the native bridge tool, we could probably make a safe fix of just
> wrapping all Xlib calls with a lock but that would probably be overkill.
> Having access to the native bridge tool would be useful anyway.[0]
Is anyone from Intel still around that could provide some insight into
the 'native bridge tool'? Anyone know who we could contact to maybe
get some more information? This would help out with some of the Vista
issues I'm seeing in Swing as well.
>
> I will try to get an ubuntu 8.10 kvm image installed and have a look at this
> problem but since awt/swing are not really a priority for me.
>
>> > Since it is not a regression, and apparently not caused by anything we
>> > can fix (unless we can find a workaround), I propose that we declare
>> > it a "Non-Blocker" for M9.
>
> +1
>
>> I'm fine with that. Maybe indicate it is a known issue.
>
> 1+ It should be mentioned in the release notes.
>
> Regards,
> Mark.
>
> [0] I think there are some modularity problems lurking here... I think
> luni depends on the org.apache.harmony.misc.accessors which depends on
> some native bridge code in awt. I suspect the common native bridge
> probably should be brought back in to the misc module.
>
>
>
Re: Remaining M9 issues
Posted by Mark Hindess <ma...@googlemail.com>.
In message <33...@gmail.com>, Nathan Beyer
writes:
>
> On Mar 25, 2009, at 5:40 AM, Tim Ellison <t....@gmail.com> wrote:
>
> > Nathan Beyer wrote:
> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
> >> <t....@gmail.com> wrote:
> >>> 3. Various AWT/Swing crashes/ failures
> >>
> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
> >> https://issues.apache.org/jira/browse/HARMONY-6123
> >
> > Looks like a problem in the X.11 libraries, and looking around it
> > seems that we are far from the only ones who have uncovered this problem.
> >
> Agreed, but I got the impression that the new behavior is considered
> correct and it will be up to apps to fix their own code. Have you
> found any indication to the contrary?
Well, there have been mistakes in the past - such as nested locking not
working as documented in the XLockDisplay man page and with locks being
held by the toolkit when user callbacks were invoked - but I think it is
quite likely that we need to do something to fix this.
We currently call XInitThreads to allow multi-threaded support but we
do not actually seem to call XLockDisplay. I don't think this can be
correct though I don't know which xlib calls need to be locking - I'm
guessing at least the two mentioned in your JIRA. If we had access
to the native bridge tool, we could probably make a safe fix of just
wrapping all Xlib calls with a lock but that would probably be overkill.
Having access to the native bridge tool would be useful anyway.[0]
I will try to get an ubuntu 8.10 kvm image installed and have a look at this
problem but since awt/swing are not really a priority for me.
> > Since it is not a regression, and apparently not caused by anything we
> > can fix (unless we can find a workaround), I propose that we declare
> > it a "Non-Blocker" for M9.
+1
> I'm fine with that. Maybe indicate it is a known issue.
1+ It should be mentioned in the release notes.
Regards,
Mark.
[0] I think there are some modularity problems lurking here... I think
luni depends on the org.apache.harmony.misc.accessors which depends on
some native bridge code in awt. I suspect the common native bridge
probably should be brought back in to the misc module.
Re: Remaining M9 issues
Posted by Nathan Beyer <nb...@gmail.com>.
On Mar 25, 2009, at 5:40 AM, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
>> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison
>> <t....@gmail.com> wrote:
>>> 3. Various AWT/Swing crashes/ failures
>>
>> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
>> https://issues.apache.org/jira/browse/HARMONY-6123
>
> Looks like a problem in the X.11 libraries, and looking around it
> seems
> that we are far from the only ones who have uncovered this problem.
>
Agreed, but I got the impression that the new behavior is considered
correct and it will be up to apps to fix their own code. Have you
found any indication to the contrary?
> Since it is not a regression, and apparently not caused by anything we
> can fix (unless we can find a workaround), I propose that we declare
> it
> a "Non-Blocker" for M9.
>
I'm fine with that. Maybe indicate it is a known issue.
> Regards,
> Tim
Re: Remaining M9 issues
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison <t....@gmail.com> wrote:
>> 3. Various AWT/Swing crashes/ failures
>
> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
> https://issues.apache.org/jira/browse/HARMONY-6123
Looks like a problem in the X.11 libraries, and looking around it seems
that we are far from the only ones who have uncovered this problem.
Since it is not a regression, and apparently not caused by anything we
can fix (unless we can find a workaround), I propose that we declare it
a "Non-Blocker" for M9.
Regards,
Tim
Re: Remaining M9 issues
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison <t....@gmail.com> wrote:
> I'm trying to catch up on the remaining M9 blockers, and have gleaned
> the following, please correct me where I'm wrong, or provide more info.
> The goal is to ensure we have no regressions, not that we fix all known
> bugs in this milestone.
>
>
> - Blockers -
>
> 1. RMI test failures on Linux [HARMONY-6090, 6091 and 6092 provide a
> partial fix to this, but tests still fail intermittently]
>
> ?JIRA? Regression?
>
> 2. hymem.exe crashes on Vista
>
> ?JIRA? Regression?
>
> 3. Various AWT/Swing crashes/ failures
Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10
https://issues.apache.org/jira/browse/HARMONY-6123
>
> ?JIRA? Regression?
>
> 4. Dacapo benchmark failure HARMONY-6041
>
> Regression caused by patch in r727327. Propose Regis fix or roll-back
> this patch.
>
>
>
> - Non-blockers -
>
>
> 1. HttpURLConnectionTest and HttpsURLConnectionTest fail on some
> systems [Test issue - fix available from Regis in HARMONY-6120 but may
> not be committed until after M9]
>
> Test case problem. Fix for test available but not committed.
>
>
> 2. org.apache.harmony.archive.tests.java.util.jar.ManifestTest fails
> on Windows XP [Tim is working on this]
>
> Fixed.
>
>
> 3. VM crash in classlib tests on Linux -
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest and
> org.apache.harmony.xnet.provider.jsse.SSLSocketImplTest
>
> Chunrong identified cause as r691267.
> Not a regression from M8.
>
>
> 4. Classlib test failures on Vista in
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest
> and org.apache.harmony.luni.tests.java.net.SocketTest [Firewall issue?]
>
> Identified as firewall problem.
>
>
>
Re: hymem crash
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> In message <49...@gmail.com>, Tim Ellison writes:
>> Nathan Beyer wrote:
>>> Maybe I've just been doing something wrong all along. One way it
>>> works, another it crashes. Here's what I'm doing.
>>>
>>> 1. I have the basic federated build setup.
>>> 2. 'ant rebuild' from top-folder, 'trunk'
>>> 3. 'cd working_classlib\modules\portlib'
>>> 4. 'ant test' - all of the native test pass just fine
>> a good sign
>>
>>> 5. 'cd ..\..\..\' - go back up to top-folder
>>> 6. 'robocopy /mir target\hdk working_classlib\deploy' - copy the
>>> federated build to classlib's deploy folder
>>> 7. 'cd working_classlib'
>>> 8. 'ant test' - after a bit, portlib tests are run and hymem.exe test
>>> blows up in the 'hymem_free_memory' method
>> "blows up" = access violation? Can you run in windbg and see what is
>> happening?
>>
>> Let me try on my WinXP install and see if the same happens.
>
> This might be a problem with the hythr from classlib being replaced by
> the hythr from drlvm - IIRC they have different APIs. Try copying everything
> *except* hythr.dll?
That was my thought too, but then wouldn't you expect much more
catastrophe than a single hymem test failure??
(just rebuilding now)
Regards,
Tim
Re: hymem crash (was: Re: Remaining M9 issues)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <49...@gmail.com>, Tim Ellison writes:
>
> Nathan Beyer wrote:
> > Maybe I've just been doing something wrong all along. One way it
> > works, another it crashes. Here's what I'm doing.
> >
> > 1. I have the basic federated build setup.
> > 2. 'ant rebuild' from top-folder, 'trunk'
> > 3. 'cd working_classlib\modules\portlib'
> > 4. 'ant test' - all of the native test pass just fine
>
> a good sign
>
> > 5. 'cd ..\..\..\' - go back up to top-folder
> > 6. 'robocopy /mir target\hdk working_classlib\deploy' - copy the
> > federated build to classlib's deploy folder
> > 7. 'cd working_classlib'
> > 8. 'ant test' - after a bit, portlib tests are run and hymem.exe test
> > blows up in the 'hymem_free_memory' method
>
> "blows up" = access violation? Can you run in windbg and see what is
> happening?
>
> Let me try on my WinXP install and see if the same happens.
This might be a problem with the hythr from classlib being replaced by
the hythr from drlvm - IIRC they have different APIs. Try copying everything
*except* hythr.dll?
Regards,
Mark.
hymem crash (was: Re: Remaining M9 issues)
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Maybe I've just been doing something wrong all along. One way it
> works, another it crashes. Here's what I'm doing.
>
> 1. I have the basic federated build setup.
> 2. 'ant rebuild' from top-folder, 'trunk'
> 3. 'cd working_classlib\modules\portlib'
> 4. 'ant test' - all of the native test pass just fine
a good sign
> 5. 'cd ..\..\..\' - go back up to top-folder
> 6. 'robocopy /mir target\hdk working_classlib\deploy' - copy the
> federated build to classlib's deploy folder
> 7. 'cd working_classlib'
> 8. 'ant test' - after a bit, portlib tests are run and hymem.exe test
> blows up in the 'hymem_free_memory' method
"blows up" = access violation? Can you run in windbg and see what is
happening?
Let me try on my WinXP install and see if the same happens.
Regards,
Tim
> Is this the wrong way to test the class library? Why would this funk
> up the portlib tests?
Re: hymem crash
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Here's what I'm doing.
>
> 1. I have the basic federated build setup.
> 2. 'ant rebuild' from top-folder, 'trunk'
> 3. 'cd working_classlib\modules\portlib'
> 4. 'ant test' - all of the native test pass just fine
That does nothing for me. I have to run it from the working_classlib
directory ant script (to set up the environment vars correctly) and pass
in a couple of defines:
cd working_classlib
ant -Dtest.portlib=true -Dbuild.module=portlib test
> 5. 'cd ..\..\..\' - go back up to top-folder
> 6. 'robocopy /mir target\hdk working_classlib\deploy' - copy the
> federated build to classlib's deploy folder
> 7. 'cd working_classlib'
> 8. 'ant test' - after a bit, portlib tests are run and hymem.exe test
> blows up in the 'hymem_free_memory' method
Works for me :
-run-native-tests:
[echo] hycpu: passed
[echo] hyerror: passed
[echo] hyfile: passed
[echo] hyfiletext: passed
[echo] hygp: passed
[echo] hymem: passed
[echo] hynls: passed
[echo] hyport: passed
[echo] hystr: passed
[echo] hytime: passed
[echo] hysysinfo: passed
[echo] hyipcmutex: passed
[echo] hymmap: passed
> Is this the wrong way to test the class library? Why would this funk
> up the portlib tests?
>
>> I will put what I can in an issue. I was hoping another vista user would pop
>> up and validate or invalidate.
>>
>>
>>> Thanks,
>>> Tim
>
Re: Remaining M9 issues
Posted by Nathan Beyer <nb...@gmail.com>.
On Wed, Mar 25, 2009 at 12:28 PM, Nathan Beyer <nb...@gmail.com> wrote:
>
>
> On Mar 25, 2009, at 5:54 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> Tim Ellison wrote:
>>>
>>> 2. hymem.exe crashes on Vista
>>>
>>> ?JIRA? Regression?
>>
>> Nathan, any details on this crash you are seeing?
>>
>> Looking at the tests, they are testing the fundamental hymem_ functions
>> in the portlibrary, and not particularly extensively. If these are
>> failing then the class library natives would be completely broken.
>>
>> You say there is a crash dialog. Can you put it into a JIRA please, or
>> a stack trace, or some of the printf's, ...
>>
Maybe I've just been doing something wrong all along. One way it
works, another it crashes. Here's what I'm doing.
1. I have the basic federated build setup.
2. 'ant rebuild' from top-folder, 'trunk'
3. 'cd working_classlib\modules\portlib'
4. 'ant test' - all of the native test pass just fine
5. 'cd ..\..\..\' - go back up to top-folder
6. 'robocopy /mir target\hdk working_classlib\deploy' - copy the
federated build to classlib's deploy folder
7. 'cd working_classlib'
8. 'ant test' - after a bit, portlib tests are run and hymem.exe test
blows up in the 'hymem_free_memory' method
Is this the wrong way to test the class library? Why would this funk
up the portlib tests?
>
> I will put what I can in an issue. I was hoping another vista user would pop
> up and validate or invalidate.
>
>
>> Thanks,
>> Tim
>
Re: Remaining M9 issues
Posted by Nathan Beyer <nb...@gmail.com>.
On Mar 25, 2009, at 5:54 AM, Tim Ellison <t....@gmail.com> wrote:
> Tim Ellison wrote:
>> 2. hymem.exe crashes on Vista
>>
>> ?JIRA? Regression?
>
> Nathan, any details on this crash you are seeing?
>
> Looking at the tests, they are testing the fundamental hymem_
> functions
> in the portlibrary, and not particularly extensively. If these are
> failing then the class library natives would be completely broken.
>
> You say there is a crash dialog. Can you put it into a JIRA please,
> or
> a stack trace, or some of the printf's, ...
>
I will put what I can in an issue. I was hoping another vista user
would pop up and validate or invalidate.
> Thanks,
> Tim
Re: Remaining M9 issues
Posted by Tim Ellison <t....@gmail.com>.
Tim Ellison wrote:
> 2. hymem.exe crashes on Vista
>
> ?JIRA? Regression?
Nathan, any details on this crash you are seeing?
Looking at the tests, they are testing the fundamental hymem_ functions
in the portlibrary, and not particularly extensively. If these are
failing then the class library natives would be completely broken.
You say there is a crash dialog. Can you put it into a JIRA please, or
a stack trace, or some of the printf's, ...
Thanks,
Tim