On Nov 26, 2007 10:37 PM, David Glasser <glasser@davidglasser.net> wrote:
>
> On Nov 26, 2007 6:37 AM, Mark Phippard <markphip@gmail.com> wrote:
> > I have been getting some crashes lately in Subclipse (using 1.5
> > trunk). Kind of sporadic, not obvious recipe. I finally bothered to
> > take the time to look at the crash output (this is on OSX). I saw
> > this:
> >
> > Thread 22 Crashed:
> > 0 libjvm.dylib 0x9bc16fb8 JVM_MonitorWait + 11444
> > 1 libjvm.dylib 0x9bcd98bb JVM_IsInterrupted + 1797
> > 2 libsvnjavahl-1.0.dylib 0x50cf8f6c
> > JNIEnv_::CallVoidMethod(_jobject*, _jmethodID*, ...) + 52 (jni.h:1034)
> > 3 libsvnjavahl-1.0.dylib 0x50cde64d
> > ProgressListener::onProgress(long long, long long, apr_pool_t*) + 495
> > (ProgressListener.cpp:128)
> > 4 libsvnjavahl-1.0.dylib 0x50cde6c6
> > ProgressListener::progress(long long, long long, void*, apr_pool_t*) +
> > 82 (ProgressListener.cpp:77)
> > 5 libsvn_ra_neon-1.0.dylib 0x50c946f0 ra_neon_neonprogress + 99
> > 6 libneon.26.dylib 0x515e2f0f ne_read_response_block + 145
> > 7 libneon.26.dylib 0x515e33b5 ne_discard_response + 34
> > 8 libneon.26.dylib 0x515e45aa ne_request_dispatch + 46
> > 9 libsvn_ra_neon-1.0.dylib 0x50c98c18 svn_ra_neon__request_dispatch + 238
> > 10 libsvn_ra_neon-1.0.dylib 0x50c98598 parsed_request + 577
> > 11 libsvn_ra_neon-1.0.dylib 0x50c987ba svn_ra_neon__parsed_request + 114
> > 12 libsvn_ra_neon-1.0.dylib 0x50c8a71c reporter_finish_report + 539
> > 13 libsvn_client-1.0.dylib 0x512e3190 reporter_finish_report + 433
> > 14 libsvn_wc-1.0.dylib 0x50ffeff0 svn_wc_crawl_revisions3 + 1613
> > 15 libsvn_client-1.0.dylib 0x512e380a svn_client_status3 + 1605
> > 16 libsvnjavahl-1.0.dylib 0x50ce74c5 SVNClient::status(char
> > const*, svn_depth_t, bool, bool, bool, bool, StatusCallback*) + 335
> > (SVNClient.cpp:172)
> > 17 libsvnjavahl-1.0.dylib 0x50cef3b1
> > Java_org_tigris_subversion_javahl_SVNClient_status + 323
> > (org_tigris_subversion_javahl_SVNClient.cpp:179)
> >
> > I think I know what the problem is. We recently started using the new
> > progress notifications. I think what happens is I take an option to
> > do an Update. We set the progress listener so that we can provide
> > feedback. At some point during this process, Eclipse kicks off a
> > status refresh in another thread (also normal). There is only one
> > JavaHL object. When the status operation starts, the progress
> > listener is still set because update is running. When update ends, it
> > is nulling out the progress listener.
> >
> > SVNClient.setProgressListener(null);
> >
> > Status goes to send a progress notification, and something is now null.
> >
> > I have changed Subclipse so that we no longer null out the listener,
> > and instead just swallow the notifications that we do not want inside
> > our object. I wonder if there is some kind of safety checks that can
> > be added in the JavaHL C++ code though so that it does not crash. I
> > do not think what I am doing is that abnormal so someone else might
> > run into this.
>
> Is .setProgressListener new in 1.5?
Yes.
> I'm not very familiar with JavaHL, but it seems like the problem is
> having a static progress listener in the first place. Is there really
> no context object or something that can get the progress listener?
The method is allowing us to provide the implementation of the
callback. See the IRC thread for more details from Dan. I do not
think there is anything static here, but since I am using a single
SVNClient object in multiple threads, I have to be careful to not
change the context.
Keep in mind that when I say it used in multiple threads, the
overwhelming majority of the time it is just one thing running (and we
also have some of our own synchronization via the Eclipse job
management support). But, due to the highly threaded nature of
Eclipse, it is definitely possible for things like status refreshes to
happen while other operations are running.
In this case, I do not think this is too hard to solve. We really
only need one progress listener, and we really did not have any need
to set it and null it around each operation. So we can just set it
once and forget it. I am a little worried about other things that are
stored in the context where maybe this will not always be the case.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 27 04:44:31 2007