Yes, this makes sense. In that case, my vote would be to apply Atrem's patch
new_queued_cond_var.patch in H-1519. Let's run with this and the new
thread.c( that we have already applied from H-1457 ) for a while. If we
discover no new issues, we can go chat about them on the APR list?
Thanks,
Ran
On Sep 29, 2006, at 2:48 PM, Rana Dasgupta wrote:
On 9/26/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>Just to be clear: I suggest we apply new_queued_cond_var.patch
>attached to HARMONY-1519 - provided that Artem will answer
>comments.
Hi,
I went through both the patches apr_cond.pa
On 9/26/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>Just to be clear: I suggest we apply new_queued_cond_var.patch
>attached to HARMONY-1519 - provided that Artem will answer >comments.
Hi,
I went through both the patches apr_cond.patch and
new_queued_cond_var.patch on H-1519.
There is
2006/9/26, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
On Sep 26, 2006, at 2:29 AM, Alexey Varlamov wrote:
> [snip]
>>
>> > H-1519 may be
>> > needed ( I suspect it is ), but we can look at it after the first
>> > two fixes
>> > have gone in?
>>
>> Look away
>
> The H-1519 spotted major issue, comm
I have some concerns about changes introduced in
build\patches\win\APR\threadproc\win32\thread.c. Namely for
apr_os_thread_get function. The implementation is simple so only one
line makes the difference *thethd = &(thd->td);. It was *thethd =
thd->td; before. I see two problems here:
1) apr_os_t
On 9/26/06, Ilya Berezhniuk <[EMAIL PROTECTED]> wrote:
1) I guess user must not get os thread handle for destroyed thread. On Linux
apr_os_thread_get does "*thethd = thd->td", it will not work with destroyed
structure too. I've simply made Win implementation to be like on Linux.
Native thread is
Yes, it would be good if someone approached APR on this.
Does someone wish to volunteer?
geir
On Sep 26, 2006, at 4:22 AM, Vladimir Gorr wrote:
On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
On 9/26/06, Dmitry Durnev <[EMAIL PROTECTED]> wrote:
>
> On 9/26/06, Vladimir Gorr <[EMAIL P
1) I guess user must not get os thread handle for destroyed thread. On Linux
apr_os_thread_get does "*thethd = thd->td", it will not work with destroyed
structure too. I've simply made Win implementation to be like on Linux.
2) Quite the contrary, it makes apr_os_thread_get and apr_os_thread_put
On 9/26/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
[snip]
>
> > H-1519 may be
> > needed ( I suspect it is ), but we can look at it after the first
> > two fixes
> > have gone in?
>
> Look away
The H-1519 spotted major issue, committed patch to APR thread_cond*
certainly has holes.
It seems
Yes, "build update" really helps, thanks.
On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
I meant *build.bat update*, certainly. In this case all works fine w/o my
patch,
I'd like to slightly continue the discussion about this patch. No needs to
apply it now
after Geir committed the thre
On Sep 26, 2006, at 2:29 AM, Alexey Varlamov wrote:
[snip]
> H-1519 may be
> needed ( I suspect it is ), but we can look at it after the first
> two fixes
> have gone in?
Look away
The H-1519 spotted major issue, committed patch to APR thread_cond*
certainly has holes. I believe we have to
On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
On 9/26/06, Dmitry Durnev <[EMAIL PROTECTED]> wrote:
>
> On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>
> [...]
> > 3) we should ignore the patch you inlined in the message before this
> one
> >
> >
> > I'm not sure. This patch elimi
On 9/26/06, Dmitry Durnev <[EMAIL PROTECTED]> wrote:
On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
[...]
> 3) we should ignore the patch you inlined in the message before this one
>
>
> I'm not sure. This patch eliminates a lot of test failures as I
mentioned
> before (BTW you also comme
On 9/26/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
[...]
3) we should ignore the patch you inlined in the message before this one
I'm not sure. This patch eliminates a lot of test failures as I mentioned
before (BTW you also commented on same issue into H-1457).
Do we want to live with this?
OK. It looks like somebody already added the directories. My apologies for
wasting 2 hours of Rana and Evgueni's time on IM on this...
On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
I am able to add thread.c but able to commit it. I get:
Adding APR\threadproc
svn: Commit fai
I am able to add thread.c but able to commit it. I get:
Adding APR\threadproc
svn: Commit failed (details follow):
svn: MKCOL of
'/repos/asf/!svn/wrk/bbfafe9d-10ff-d74c-b9e0-85d8767d721d/incubato
r/harmony/enhanced/drlvm/trunk/build/patches/win/APR/threadproc': 405 Method
Not
Allowed (ht
[snip]
> H-1519 may be
> needed ( I suspect it is ), but we can look at it after the first
> two fixes
> have gone in?
Look away
The H-1519 spotted major issue, committed patch to APR thread_cond*
certainly has holes. I believe we have to fix it anyway. And the last
fix suggested by Artem Ali
On Sep 26, 2006, at 12:25 AM, Vladimir Gorr wrote:
On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Vladimir Gorr wrote:
> On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> > Under what platfrom, what b
On Sep 25, 2006, at 5:07 PM, Rana Dasgupta wrote:
Hi Weldon/Geir,
Looks like we have quite a few Windows failures. Could one of you
folks
please add in the the new file:
patches/win/APR/threadproc/win32/thread.c
that is in 1457, but possibly got dropped from the commit?
Possibly? Mos
On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Vladimir Gorr wrote:
> On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> > Under what platfrom, what build?
>>
>>
>> On Windows for build I've built from th
On 9/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Vladimir Gorr wrote:
> On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> > Under what platfrom, what build?
>>
>>
>> On Windows for build I've built from the
Vladimir Gorr wrote:
> On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> > Under what platfrom, what build?
>>
>>
>> On Windows for build I've built from the latest sources (at 449592
>> revision).
>>
>
> Sorry I wa
Vladimir Gorr wrote:
> On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote:
>>
>> > As for me (and other people) a lot of tests fail for the latest
>> > sources (revision 449592).
>> > I've run the build.bat clean; build.bat update;
Hi Weldon/Geir,
Looks like we have quite a few Windows failures. Could one of you folks
please add in the the new file:
patches/win/APR/threadproc/win32/thread.c
that is in 1457, but possibly got dropped from the commit?
We also need H-1340 to fix the assert in the fat monitor. H-1519 may b
On 9/25/06, Ilya Berezhniuk <[EMAIL PROTECTED]> wrote:
Geir, Vladimir,
I've returned from vacation today, so my 2 cents to this discussion...
I guess the problem have appeared because in r449399 the changes for
win/apr_thread_ext.c
were committed, but new file patches/win/APR/threadproc/win32/
I looked at it( gc.LOS hang ) for a while and my findings are somewhat
similar to Alexey's. The problem occurs for me all the time irrespective of
where the trace statement apprears( ref: Weldon's comment ). On breaking in,
the call stack at hang is:
ntdll.dll!7c90eb94()
ntdll.dll!7c90ea53()
k
Folks,
You may find interesting investigations in HARMONY-1519 [1] of bugs in
patched APR condition variables on Win32, which affect wait()
behavior.
[1]http://issues.apache.org/jira/browse/HARMONY-1519?page=all
2006/9/25, Weldon Washburn <[EMAIL PROTECTED]>:
The hang on gc.LOS on windows has
The hang on gc.LOS on windows has been present for at least one week. I
broke into the hung DRLVM with microsoft debugger. Its running jitted code
that loops. The loop seems to involve synchronization primitives (see email
chain "[drlvm] gc.LOS hangs on win32")
I still suspect a bug that is so
Geir, Vladimir,
I've returned from vacation today, so my 2 cents to this discussion...
I guess the problem have appeared because in r449399 the changes for
win/apr_thread_ext.c
were committed, but new file patches/win/APR/threadproc/win32/thread.c was
not committed. These changes are work togeth
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote:
> As for me (and other people) a lot of tests fail for the latest
> sources (revision 449592).
> I've run the build.bat clean; build.bat update; build.bat command
> in compliance with co
On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> Under what platfrom, what build?
On Windows for build I've built from the latest sources (at 449592
revision).
Sorry I was mistaken :-(. JAVA_HOME refers to RI and therefore
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote:
> As for me (and other people) a lot of tests fail for the latest
> sources (revision 449592).
> I've run the build.bat clean; build.bat update; build.bat command
> in compliance with co
On 9/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Under what platfrom, what build?
On Windows for build I've built from the latest sources (at 449592
revision).
Thanks,
Vladimir.
On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote:
> BTW I've forgot to say ActiveMQ 4.0 works w/o any
Under what platfrom, what build?
On Sep 25, 2006, at 5:50 AM, Vladimir Gorr wrote:
BTW I've forgot to say ActiveMQ 4.0 works w/o any problems.
Thanks,
Vladimir.
On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
As for me (and other people) a lot of tests fail for the latest
sources
(
On Sep 25, 2006, at 5:19 AM, Vladimir Gorr wrote:
As for me (and other people) a lot of tests fail for the latest
sources (revision 449592).
I've run the build.bat clean; build.bat update; build.bat command
in compliance with comments for H-1457.
It's very strange for me it mentions here all
BTW I've forgot to say ActiveMQ 4.0 works w/o any problems.
Thanks,
Vladimir.
On 9/25/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote:
As for me (and other people) a lot of tests fail for the latest sources
(revision 449592).
I've run the *build.bat clean; build.bat update; build.bat* command in
c
As for me (and other people) a lot of tests fail for the latest sources (revision 449592).
I've run the build.bat clean; build.bat update; build.bat command in compliance with comments for H-1457.
It's very strange for me it mentions here all C-unit tests work fine. Sorry I cannot confirm this.
The
Ok, I'm not as worried - I went back a few days to r447025 and still
have the problem, so it's not from this morning. I guess this has
been masked all along by the logger problem. Noted in JIRA HARMONY-1560
geir
On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote:
This is completely m
This is completely my fault.
The latest round of patches, while I dutifully do smoke, c-unit and
kernel tests for each patch, I didn't do any app testing.
I tried to run ActiveMQ, and it breaks with an asset in
object_handles.cpp : 99
I'm going to back out the two GC patches I applied and
39 matches
Mail list logo
