VSE Virtual Machine sources

> Sometimes when VSE will crash it will ask if I want to open the
> debugging environment on the crashed virtual machine.  If I wanted to
> do this I would need the VM sources, right?  Does Cincom make these
> sources available to their customers?
>
> Thanks,
>
> -Carl Gundel
> http://www.libertybasic.com
> http://www.runbasic.com
>
> ***           this signature added by listserv             ***
> *** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
> *** for archive browsing and VSWE-L membership management  ***

> Sometimes when VSE will crash it will ask if I want to open the
> debugging environment on the crashed virtual machine.  If I wanted to
> do this I would need the VM sources, right?  Does Cincom make these
> sources available to their customers?
>
> Thanks,
>
> -Carl Gundel
> http://www.libertybasic.com
> http://www.runbasic.com
>
> ***           this signature added by listserv             ***
> *** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
> *** for archive browsing and VSWE-L membership management  ***

> Hey Carl,
>
> There are 3 common cases where VSE crashes:
>
> 1. You are calling 3rd party component (API call, COM call etc.) and this component is buggy. Then you need the PDB for that component. Microsoft provides PDBs for most of their stuff. Visual Studio can even load those on the fly form the internet.
>
> 2. There is a bug in the VM. The PDB from Cincom might help in some situations. However, there are 2 major cases here.
> 2a. Bug in some static VM code, e.g. the GC algorithm or some other helper function. PDB will help.
> 2b. Bug in some on-the-fly generated (JIT compiled) code. That code does not have PDBs and is difficult do debug. I don't know if there are people (outside Cincom) with knowledge how to debug this.
>
> 3. Bug in some API declaration in your Smalltalk code, or simply just passing wrong or invalid parameters to the API. PDBs here will help, but most probably the stack trace that Ivar mentioned will help you most.
>
>
> In my experience, 90% of all GPFs are due to bug in category 3. Category 2 bugs (the one that need Cincom intervention) are rare, and people do report them on the list and work around or how to avoid them. Example of category 2 bug is ... [ :a :b | String with: a with: b ] valueWithArguments: 'AB'. The primitive does check the size of the object, but doesn't check that it's actually a pointer object. But as I said, search the list archives to see if you can find information.
>
>
> As Ivar mentioned, it's possible to reconstruct the Smalltalk stack. The linked document describes how. I've used this often to reconstruct the stack and figure out if it crashes in a certain pattern. I suggest that you:
> 1. Start Microsoft Excel.
> 2. Dump the raw stack contents in the memory viewer in Visual Studio.
> 3. Use the value of the ESP and EBP registers to figure out what part of the stack to dump.
> 4. Paste the raw stack contents (raw data) into Excel.
> 5. Start decoding the stack by hand. This can be quite time consuming, but with time, you learn to recognize some patterns.
> 6. Fix the bug!
>
> Some special things.
> - If it is a class method, you will need one extra lookup to get the name of the class.
> - You will learn very fast to recognize the address of <nil>. It's a static object that never moves in memory. However, it's different depending on VM versions. If I remember correctly, the one my ex employer used had the address 0x10026060 (or something in that range).
> - The document that Ivar sent only describes normal Smalltalk stack frames. When in API call, the stack frame is different and if you try to decode the stack, you will get garbage. As far as I know, there is no documentation on the API call frames. But if I remember correctly, it's easy to spot API call frames (from the function return addresses) and in the API call frame you can find a pointer to the top "real" Smalltalk frame. I don't know the exact recipe, but with some trial and error, you will learn how to easily spot the stack pointers and frames.
> - Use Excel and give data different colors. This makes the stack frames much more visible and easy to understand what crashed it.
>
> I hope this helps.
>
>
>
> -----Original Message-----
> From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Ivar Maeland
> Sent: 11. oktober 2011 15:43
> To: [hidden email]
> Subject: Re: VSE Virtual Machine sources
>
> It depends a little what kind of crash occurred, but even without the source code you can still open the crashed VM in Visual Studio and examine the stack to determine what the last methods executed were.
> It is a little outdated with current version of VS, but the following explains how to walk the Smalltalk stack.
> http://www.tec4.ca/smalltalk/walking_a_smalltalk_stack_dump.html
>
>
> Ivar Maeland, B.Sc., MCAD
> Product Developer
> Policy Works Inc.
> Commercial Management Systems
>
> Toll Free: 1.800.260.3676 ext.109
> Direct: 403.450.1109
> www.policyworks.com
>
>
>
> -----Original Message-----
> From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Carl Gundel
> Sent: October 10, 2011 10:12 AM
> To: [hidden email]
> Subject: VSE Virtual Machine sources
>
> Sometimes when VSE will crash it will ask if I want to open the debugging environment on the crashed virtual machine.  If I wanted to do this I would need the VM sources, right?  Does Cincom make these sources available to their customers?
>
> Thanks,
>
> -Carl Gundel
> http://www.libertybasic.com
> http://www.runbasic.com
>
> ***           this signature added by listserv             ***
> *** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
> *** for archive browsing and VSWE-L membership management  ***
>
> ***           this signature added by listserv             ***
> *** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
> *** for archive browsing and VSWE-L membership management  ***
>
> ***           this signature added by listserv             ***
> *** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
> *** for archive browsing and VSWE-L membership management  ***
>