Re: JavaHL: Thread safety and Progress Notifications

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?

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?

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org