System Monitor - application example; access violation when window closed.

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Open System Monitor
2. Close System Monitor
3. Repeat 

What is the expected output? What do you see instead?

The Strongtalk environment crashes with an access violation error

What version of the product are you using? On what operating system?

R162; Windows Vista 64 bit.

Please provide any additional information below.
If you open and close the System Monitor example a few times it often 
crashes the environment.
I think this is due to the update process sending an invalidate message to 
a window that has been closed; this leads on to an access violation when a 
rectangle that no longer exists is updated.  System Monitor can be made 
less crashprone by checking to see if the applications top level window 
visual is not nil prior to invalidating the window.

Original issue reported on code.google.com by [email protected] on 28 Aug 2009 at 5:35

[GoogleCodeExporter]

Thanks for the bug report.

I did a bit of investigation into this. There are several problems here.

1. The proxy VM primitives (used when calling out to external code in the FFI) 
were
not checking that the pointer was valid (or at least non-NULL) before trying to
setting the contents of the structure pointed to by the proxy, leading to the 
access
violation you saw.
2. Although the Window code releases its scratchRECT proxy, it doesn't nil it 
out, so
that when the SystemMonitor process tries to update the window it tries to 
update the
proxy which is no longer valid.
3. The SystemMonitor doesn't cancel its background thread when the window is 
closed.

I've fixed the first of these issues locally. That avoids the intermittent 
access
violation when you close the SystemMonitor window. Instead it pops up a
StackTraceInspector on the process, which is at least a Smalltalk level error 
which
doesn't immediately trash your environment.

I plan to check in some changes to add Aliens support to the VM in the next few 
days.
I will check in the proxy fix and load up new binaries and a new image at the 
same time.

Note that I did still manage to create an access violation in the 
StackTraceInspector
when I clicked on the StandardWindow following the fix. Not sure yet what is 
causing
this, but I have seen some similar issues with the StackTraceInspector in other
scenarios, so this may just be a recurrence of one of those. When I finish the 
Aliens
work I plan to come back to this. In the meantime, the safest thing to do when a
StackTraceInspector appears is just to close the StackTraceInspector window. 
This
seems safe.

Original comment by [email protected] on 31 Aug 2009 at 1:06

• Changed state: Started

[GoogleCodeExporter]

Original comment by [email protected] on 31 Aug 2009 at 1:08

• Added labels: OpSys-Windows, Type-Defect, Usability

[GoogleCodeExporter]

Original comment by [email protected] on 31 Aug 2009 at 1:16

• Added labels: Priority-Medium

[GoogleCodeExporter]

I've checked in the fix to the proxy primitives as part of my Aliens port. New
binaries and a new image are available from the download section. This should 
fix the
access violation error, but you may get a StackTraceInspector instead. At least 
this
leaves you inside the Smalltalk environment rather than terminating the VM.

I'll leave this item as open due to the remaining problems (2 and 3 in my list 
above)
for the time being. Can you confirm that this fixes the immediate problem of the
access violation for you?

Original comment by [email protected] on 15 Sep 2009 at 1:55

[GoogleCodeExporter]

Just confirming that this fix is preventing the access violation; many thanks.

Original comment by [email protected] on 16 Oct 2009 at 7:53