Access Violations in 4.0 VM

> I've run into problems with Dolphin crashing after I turned it into a
> COM server and started calling on it from a VisualBasic client. It
> happens often enough to be a problem, but not often enough to track down
> easily. :-(
>
> I apologize for the length of this post, but it is a nebulous enough
> problem that I'm not sure what details may be relevant. In trying to
> simplify, I did uncover that with even the default image the VM causes
> access violations which are caught and so never bother the user. But
> perhaps it's masking some real problems for me? If anyone has any ideas
> on this, or any other aspect of my problem, or how I might proceed, I'm
> listening...
>
> First, let me get the environment out of the way. Dolphin 4.01.03 With
> Gorisek's Source Tracking System, SUnit w/Jeff's browser, and a few of
> Ian's goodies. Windows 2000 Pro SP2. VisualStudio 6.0 SP5, VisualBasic
> with vbUnit3.06.02 Pro (eval) integrated.
>
> Overall, it appears to fall apart more readily when the image is
> stressed, by making more COM calls in sequence or by letting the memory
> footprint grow before letting it idle long enough for garbage collection
> to kick in and reduce the memory utilized.
>
> It's been failing a lot of different ways -- sometimes with access
> violations or protection fault walkbacks and sometimes just terminating
> without a word. Once recently when it did that, I checked the .errors
> file and it looks like it got  an initial gpFault and then a couple of
> additional gpFaults while trying to create a WalkbackDialog. Another
> time it gave an OK dialog saying it had hit a breakpoint and then died.
> Looking at the .errors showed a sequence of over 240 gpFaults within 2
> seconds!
>
> At one point I got the idea of attaching the VisualStudio C++ debugger
> to the Dolphin process. I saw that as it ran it would often encounter a
> number of Access Violations but keep running. When it eventually hits
> the wall, it's either problems with the Heap such as "HEAP[Dolphin.exe]:
> Invalid Address specified to RtlSizeHeap(c10000,c438a0)" or
> "HEAP[Dolphin.exe]: HEAP: Free Heap block c45618 modified at c45654
> after it was freed", or it's problems with hitting a UserBreakpoint such
> as at NTDLL 77fa018c, which was being called through 3 other levels in
> NTDLL from OLE32 from OLEAUT32 from DOLPHINVM004 10012536().
>
> Another indication of things going awry is when a 2nd instance of
> Dolphin gets started. I've registered the COM implementation classes and
> classFactories for them. So when I have the development image open the
> COM client usually just connects to it. But sometimes, right in the
> middle of a series of COM calls, a second instance of Dolphin.exe gets
> started. Does this tell me anything useful, other than perhaps the 1st
> instance has become unresponsive in some way?
>
> I've been trying to isolate and simplify what was being called and still
> being able to reproduce some manifestation of the problem. Since the
> Access Violations showing up in the C++ debugger seemed to be a definite
> precursor of the eventual crash, I only worried about what would cause
> one of them to appear while simplifying the test. Unfortunately I then
> noticed that in just the initial loading of my working image (before any
> COM calls are made on it) there are a couple of instances of
> "First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation" right in between loading "riched20.dll" and "shlwapi.dll".
>
> I went back to the distributed Default.img and found that the image
> would load cleanly. BUT, when I opened a Class Hierarchy Browser it then
> got:
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>     - Loaded 'C:\Program Files\Common Files\Object Arts\Dolphin
> Smalltalk 4.0\DolphinCR004.dll', no matching symbolic information found.
>
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>
> Granted, if I wasn't looking at the C++ debugger's output I wouldn't
> know there was any problem. Is this considered normal? From what I
> understand, an access violation is occurring but it's being caught and
> the program is continuing. I'm all for robust code, but should the
> violation even occur in the first place? If access violations are
> expected and ignored at some level, how do I ever figure out what's
> going wrong and eventually crashing the program? Help!
>
> Wishing I was back working only in Smalltalk...
> -Bill
>
> -------------------------------------------
> Bill Dargel            [hidden email]
> Shoshana Technologies
> 100 West Joy Road, Ann Arbor, MI 48105  USA
>
>

> ...
> I went back to the distributed Default.img and found that the image
> would load cleanly. BUT, when I opened a Class Hierarchy Browser it then
> got:
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>     - Loaded 'C:\Program Files\Common Files\Object Arts\Dolphin
> Smalltalk 4.0\DolphinCR004.dll', no matching symbolic information found.
>
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>
> Granted, if I wasn't looking at the C++ debugger's output I wouldn't
> know there was any problem. Is this considered normal? From what I
> understand, an access violation is occurring but it's being caught and
> the program is continuing. I'm all for robust code, but should the
> violation even occur in the first place?

> I've run into problems with Dolphin crashing after I turned it into a
> COM server and started calling on it from a VisualBasic client. It
> happens often enough to be a problem, but not often enough to track down
> easily. :-(
>
> I apologize for the length of this post, but it is a nebulous enough
> problem that I'm not sure what details may be relevant. In trying to
> simplify, I did uncover that with even the default image the VM causes
> access violations which are caught and so never bother the user. But
> perhaps it's masking some real problems for me? If anyone has any ideas
> on this, or any other aspect of my problem, or how I might proceed, I'm
> listening...
>
> First, let me get the environment out of the way. Dolphin 4.01.03 With
> Gorisek's Source Tracking System, SUnit w/Jeff's browser, and a few of
> Ian's goodies. Windows 2000 Pro SP2. VisualStudio 6.0 SP5, VisualBasic
> with vbUnit3.06.02 Pro (eval) integrated.
>
> Overall, it appears to fall apart more readily when the image is
> stressed, by making more COM calls in sequence or by letting the memory
> footprint grow before letting it idle long enough for garbage collection
> to kick in and reduce the memory utilized.
>
> It's been failing a lot of different ways -- sometimes with access
> violations or protection fault walkbacks and sometimes just terminating
> without a word. Once recently when it did that, I checked the .errors
> file and it looks like it got  an initial gpFault and then a couple of
> additional gpFaults while trying to create a WalkbackDialog. Another
> time it gave an OK dialog saying it had hit a breakpoint and then died.
> Looking at the .errors showed a sequence of over 240 gpFaults within 2
> seconds!
>
> At one point I got the idea of attaching the VisualStudio C++ debugger
> to the Dolphin process. I saw that as it ran it would often encounter a
> number of Access Violations but keep running. When it eventually hits
> the wall, it's either problems with the Heap such as "HEAP[Dolphin.exe]:
> Invalid Address specified to RtlSizeHeap(c10000,c438a0)" or
> "HEAP[Dolphin.exe]: HEAP: Free Heap block c45618 modified at c45654
> after it was freed", or it's problems with hitting a UserBreakpoint such
> as at NTDLL 77fa018c, which was being called through 3 other levels in
> NTDLL from OLE32 from OLEAUT32 from DOLPHINVM004 10012536().
>
> Another indication of things going awry is when a 2nd instance of
> Dolphin gets started. I've registered the COM implementation classes and
> classFactories for them. So when I have the development image open the
> COM client usually just connects to it. But sometimes, right in the
> middle of a series of COM calls, a second instance of Dolphin.exe gets
> started. Does this tell me anything useful, other than perhaps the 1st
> instance has become unresponsive in some way?
>
> I've been trying to isolate and simplify what was being called and still
> being able to reproduce some manifestation of the problem. Since the
> Access Violations showing up in the C++ debugger seemed to be a definite
> precursor of the eventual crash, I only worried about what would cause
> one of them to appear while simplifying the test. Unfortunately I then
> noticed that in just the initial loading of my working image (before any
> COM calls are made on it) there are a couple of instances of
> "First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation" right in between loading "riched20.dll" and "shlwapi.dll".
>
> I went back to the distributed Default.img and found that the image
> would load cleanly. BUT, when I opened a Class Hierarchy Browser it then
> got:
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>     - Loaded 'C:\Program Files\Common Files\Object Arts\Dolphin
> Smalltalk 4.0\DolphinCR004.dll', no matching symbolic information found.
>
>     - First-chance exception in Dolphin.exe (DLL): 0xC0000005: Access
> Violation.
>
> Granted, if I wasn't looking at the C++ debugger's output I wouldn't
> know there was any problem. Is this considered normal? From what I
> understand, an access violation is occurring but it's being caught and
> the program is continuing. I'm all for robust code, but should the
> violation even occur in the first place? If access violations are
> expected and ignored at some level, how do I ever figure out what's
> going wrong and eventually crashing the program? Help!
>
> Wishing I was back working only in Smalltalk...
> -Bill
>
> -------------------------------------------
> Bill Dargel            [hidden email]
> Shoshana Technologies
> 100 West Joy Road, Ann Arbor, MI 48105  USA
>
>