[squeak-dev] Priority of WeakArray finalizationProcess
leves at elte.hu
Sun Jun 13 18:35:29 UTC 2010
On Sun, 13 Jun 2010, Joachim Geidel wrote:
> After finding the "official" download for the IAB32 plugin binary at
> http://code.google.com/p/pharo/issues/detail?id=1360, comment #3, attachment
> squeakVMWithAlien.zip, I could run a first test of JNIPort in Squeak 4.1 on
> Windows XP SP3.
> It exhibited the same deadlock I saw on Mac OS X, and the deadlock went away
> when I prevented finalization to run in parallel to the JVM startup by
> lowering the priority of the finalizationProcess to 20. So the problem does
> not seem to be platform dependent.
> The JNIPort tests pass except for one failure because of the broken UTF-16
> encoder (http://bugs.squeak.org/view.php?id=7544) and three errors because
> the function vsnprintf is not found in the standard library, but this is
> only needed for a special callback hook of the Java virtual machine which
> allows redirecting debugging output such that it can be traced in Smalltalk
> instead being emitted on stderr.
> I don't have the crashes you see. I just used the VM and IAB32ABI.dll which
> are in squeakVMWithAlien.zip. What operating system do you have? Is it a 64
> bit system?
I used Igor's NativeBoost VM, since it has the Alien plugin, but something
must be wrong with that, because the code works with the VM you linked.
So I could start the JVM and reproduce the deadlock. The problem seems to
be that somehow the JVM's mutex (sharedMutex) is not released by the UI
process (which is starting the JVM). When I interrupt the process, I get a
debugger with this stack trace:
 in Semaphore>>critical:
If I select JVMWithoutCallbacks(JVM)>>own: in the debugger and inspect the
instance variable "sharedMutex", I find that the UI process is still the
owner of the mutex, the mutex's semaphore has no signals and the process
is in the list of the semaphore. But the process is not in the critical
section of the mutex, because the block containing the #critical: send is
already evaluated (JNIPortWeakRegistry>>registerValueOf:). So the mutex is
"locked", but it's not used by the process that "locks" it.
The deadlock occurs, because the finalization process is trying to access
the same mutex to finalize the objects, while it's also in the critical
section of the WeakRegistry's semaphore. While this is happening, the UI
process is trying to register new objects to the WeakRegistry.
I couldn't find out how can the Mutex have this invalid state.
> Am 13.06.10 14:46 schrieb Levente Uzonyi:
>> That's bad news. I tried to start the JVM again with the following
>> | jvmSettings |
>> JNIPortJNIInterface libraryFile: 'C:\Program
>> jvmSettings := (JVMSettings new)
>> name: 'JVM with ghost class generation';
>> jvmSettings usesGhosts: true.
>> jvmSettings jniPortSettings useJNIHelperLibrary: false.
>> jvmSettings runtimeSettings classpath:
>> Cursor execute showWhile: [JVM newWithSettings: jvmSettings].
>> But it crashes:
>> Current byte code: 98
>> Primitive index: 1060
>> Loaded plugins:
>> C:\Program Files\Java\jre6\bin\client\jvm.dll
>> IA32ABI 1 May 2010 (e)
>> LocalePlugin 29 April 2010 (i)
>> B2DPlugin 29 April 2010 (i)
>> BitBltPlugin 29 April 2010 (i)
>> SecurityPlugin 29 April 2010 (i)
>> FilePlugin 29 April 2010 (i)
>> LargeIntegers v1.5 29 April 2010 (i)
>> MiscPrimitivePlugin 29 April 2010 (i)
>> The Smalltalk Stack:
>> 289028824 JNIVTableMethod>call:
>> 289027948 JNIPortVTableClient>call:withArguments:
>> 289027828 JNIPortVTableClient>call:with:with:
>> 289027736 JNIPortJNIEnv>EnsureLocalCapacity_capacity:
>> 289027644 JVM>initializeLocalCapacity
>> 288899024 JVM>initializeFromSettings:
>> 288898932 JVM class>newWithSettings:
>> 288898672 UndefinedObject>?
>> 288898580 BlockClosure>ensure:
>> 288898488 Cursor>showWhile:
>> 288897964 UndefinedObject>?
>> 288890960 Compiler>evaluate:in:to:notifying:ifFail:logged:
>> 288890868 TextEditor>evaluateSelection
>> 288890776 BlockClosure>on:do:
>> 288890684 TextEditor>evaluateSelection
>> 288890592 TextEditor>doIt
>> Any ideas how I could start it without crashing?
>>> Joachim Geidel
More information about the Squeak-dev