harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [drlvm] my latest round of patches broke something
Date Tue, 26 Sep 2006 13:40:53 GMT
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
usage similar on Linux and Windows. I've prepared this patch when I've
discovered that hythread_attach_to_group function in TM works correctly on
Linux but on Windows it works incorrectly, so all (hy)threads created with
hythread_create store correct OS thread handle and all (hy)threads attached
with hythread_attach_to_group store pointer to OS handle, i.e. different
values!


2006/9/26, Evgueni Brevnov <evgueni.brevnov@gmail.com>:
>
> 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_thread_get returns an address of the td field of
> apr_thread_t structure. The user may access this address even after
> corresponding apr_thread_t structure is destroyed. So there will be a
> garbage at that adress. I belive this is the main reason why APR
> developers implemented this function like we have it now.
>
> 2) Our patched APR library become incompatible with original one. So
> any external application which uses apr_os_thread_get function may
> fail with patched APR.
>
> Thanks
> Evgueni
>
> On 9/26/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > 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 <vvgorr@gmail.com> wrote:
> > >>
> > >>
> > >>
> > >> On 9/26/06, Dmitry Durnev <dmitry.a.durnev@gmail.com> wrote:
> > >> >
> > >> > On 9/26/06, Vladimir Gorr <vvgorr@gmail.com> 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? And one more note is our patch
> > >> is not
> > >> > related
> > >> > > with eliminating the ActiveMQ crash. It's another story.
> > >> > >
> > >> > > Thanks,
> > >> > > Vladimir.
> > >> >
> > >> > For me nothing works under windows (on latest drlvm/debug build)
> > >> > without this patch. Even "Hello, world" fails(after printing "Hello
> > >> > world!") with
> > >> >
> > >> > SEH handler: shutdown error
> > >> >
> > >> > and shows 2 debug messegaboxes(1 is from the launcher).
> > >> > And this happens irrespective of my JAVA_HOME setting, I tried both
> > >> > to unset it, and to point to Harmony JRE...
> > >> > Debugging shows that in apr_thread_ext.c in
> > >> apr_thread_set_priority()
> > >> > SetThreadPriority(*os_thread,...) call fails with access
> > >> violation...
> > >> > So I think your patch, Vladimir, is useful :)
> > >>
> > >>
> > >> Dmitry,
> > >>
> > >> did you run 'build.bat clean' before starting the build process?
> > >>
> > >
> > >
> > > 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 thread.c file for *H-1457*. This file
> > > contains a
> > > fix for the APR bug.
> > >
> > > (BTW it'd be not bad to mention about this issue on the APR dev
> > > list. Sure
> > > it makes sense).
> > >
> > > Our patch is a workaround to avoid this bug.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Vladimir.
> > >
> > >
> > > Maybe a clue for your issue is here. At least I have same issue
> > > right now.
> > >>
> > >> Thanks,
> > >> Vladimir.
> > >>
> > >> --
> > >> >
> > >> > Dmitry A. Durnev,
> > >> > 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
> > >> >
> > >> >
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message