String>>indexOfSubCollection:startingAt: bug? -- Invalid access to memory location

I have a Dolphin program that reads a bunch of files and outputs two
files for each one read. The program runs fine most of the time, but
occasionally it gives me an error (Invalid access to memory location.
Reading 0x7588001, IP 0x10012F86) in
SequenceableCollection>>indexOfSubCollection:startingAt:. It always
occurs when I'm performing a copyReplaceAll:with: on a String. If I
restart the SequenceableCollection method and step through it using the
debugger, everything works fine, and I can later resume the process
without any problems.

Since the debugger highlights "targetSequence size" in
SequenceableCollection>>indexOfSubCollection:startingAt: as the error,
I'm guessing that the error is really occurring in the
String>>indexOfSubCollection:startingAt: primitive. Could that primitive
be walking off the end of the string? I didn't check but I believe the
receiver string is greater than 512 bytes, so it should be using the
Boyer-Moore algorithm (assuming that the comment is correct).


John Brant

Here is a test that shows the failure:

| strings search current |
search := String new: 26.
strings := OrderedCollection new.
1000 timesRepeat:
        [current := String new: 970.
        current indexOfSubCollection: search startingAt: 965.
        strings add: current]


The #indexOfSubCollection:startingAt: should always return 0 since the
string we are searching for is longer than the remaining elements.
However, if the string is close to the end of the memory segment, it
fails. This occurs about the 15th time through the loop on my machine.


John Brant

"John Brant" <[hidden email]> wrote in message
news:e5Pmc.53$au1.68726@attbi_s51...
Thanks for the bug report John. I'll investigate and report back shortly.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
There is definitely a bug in the primitive, which doesn't check properly
that the subcollection fits within the search interval if startingAt > 1.

There is a hotfix VM available at:

http://object-arts.com/Lib/update/Dolphin/5.1/DolphinVM005.zip

This should be extracted over the top of the existing DolphinVM005.dll in
"C:\Program Files\Common Files\Object Arts\Dolphin Smalltalk 5.1"

Since the ToGo stubs used for deploying ToGo applications also incorporate
most of the VM code, there are hotfixed versions of these too:

http://object-arts.com/Lib/update/Dolphin/5.1/ToGoStubs.zip

These should be extracted over the existing stubs in "C:\Program
Files\Object Arts\Dolphin Smalltalk 5.1"

Regards

Blair

Blair,

> There is definitely a bug in the primitive, which doesn't check properly
> that the subcollection fits within the search interval if startingAt > 1.

Thanks for your rapid response to this.  I decided to put my money where
my mouth is by creating an installer for these updates.  FWIW, I already
found some problems with my various compiler DLLs, though I suspect it's
the same file, simply installed via a LiveUpdate.  Anyway, I took the
latest of them for my compiled installer.

To those inclinded to try this, I can only say "you've been warned", and
that my image still loads after compiling and running it.  It also
appears to have udpated the correct files.  Perhaps an InnoSetup guru
could take a look at it.  Please note the use of ignoreversion; I found
that necessary because the stub versions did not change.

With OA's permission, I would be happy to compile this and place it on
needle, and OA is of course free to do the same.  In that case, it would
be best to edit the URLs.

Have a good one,

Bill


[Setup]
AppName = Dolphin Smalltalk binaries
AppVerName = Dolphin Smalltalk binaries
AppPublisher = Wilhelm K. Schwab, Ph.D. for Object Arts, Ltd.
AppPublisherURL = http://needle.anest.ufl.edu/anest4/bills/
AppSupportURL = http://needle.anest.ufl.edu/anest4/bills/
AppUpdatesURL = http://needle.anest.ufl.edu/anest4/bills/
DefaultDirName = C:\Program Files\Object Arts\Dolphin Smalltalk 5.1
DisableDirPage = yes
DefaultGroupName = Dolphin Smalltalk binaries
DisableProgramGroupPage = yes
AlwaysRestart = no
OutputBaseFilename = Dolphin Smalltalk binaries
DisableStartupPrompt = yes


[Components]
Name:vm; Description:Updated VM and stubs; Types:full compact;
Name:compiler; Description:Updated compiler; Types:full compact;


[Files]
Source:C:\Installers\DolphinFixes\DolphinVM005.dll; DestDir:C:\Program
Files\Common Files\Object Arts\Dolphin Smalltalk 5.1; Components: vm
Source:C:\Installers\DolphinFixes\DolphinCR005.dll; DestDir:C:\Program
Files\Common Files\Object Arts\Dolphin Smalltalk 5.1; Components: compiler
Source:C:\Installers\DolphinFixes\ConsoleToGo.exe; DestDir:C:\Program
Files\Object Arts\Dolphin Smalltalk 5.1; Flags: ignoreversion;
Components: vm
Source:C:\Installers\DolphinFixes\GUIToGo.exe; DestDir:C:\Program
Files\Object Arts\Dolphin Smalltalk 5.1; Flags: ignoreversion;
Components: vm
Source:C:\Installers\DolphinFixes\IPDolphinToGo.dll; DestDir:C:\Program
Files\Object Arts\Dolphin Smalltalk 5.1; Flags: ignoreversion;
Components: vm


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:c80oub$12gs$[hidden email]... ...

This is a nice idea Bill, thanks for posting the script.  While I don't
qualify as an InnoSetup guru, I do have some suggestions.

Instead of
"C:\Program Files\Object Arts\Dolphin Smalltalk 5.1"
use
{reg:HKLM\Software\Object Arts\Dolphin Smalltalk 5.1,|{pf}\Object
Arts\Dolphin Smalltalk 5.1}

Instead of
"C:\Program Files\Common Files\Object Arts\Dolphin Smalltalk 5.1"
use
{cf}\Object Arts\Dolphin Smalltalk 5.1

I have not tested this, but I believe this (or something like it) would
work.  It will use OS constants for "Program Files" and "Common Files" and
get the actual Dolphin program directory from the registry.  It is possible
that someone might have a non-standard configuration with different path
names.  Hmmm actually I suppose non-English versions of Windows might use
different path names.  The above constants should handle that.

Chris

Chris,

> This is a nice idea Bill, thanks for posting the script.  

Thanks for reviewing it.


 > While I don't
> qualify as an InnoSetup guru, I do have some suggestions.
[snip]

Nice!  Using pf/cf is clearly the right thing to do.  Did you reverse
engineer "reg:HKLM\Software\Object Arts\Dolphin Smalltalk 5.1", or is
that documented?  I see the |, so it should work if not present, but
what if it has been modified?


> I have not tested this, but I believe this (or something like it) would
> work.  It will use OS constants for "Program Files" and "Common Files" and
> get the actual Dolphin program directory from the registry.  It is possible
> that someone might have a non-standard configuration with different path
> names.  Hmmm actually I suppose non-English versions of Windows might use
> different path names.  The above constants should handle that.

That was easier than I expected.  My concern was that some file name
manipulation would fail, but that either wasn't involved, or worked
(probably the former).  What file name manipulation?  Here's the guts of
the Smalltalk code that wrote the script:

        source := 'C:\Installers\DolphinFixes'.
        script := InnoSetupScript new
                addSection:( InnoSetupScriptSectionSetup new beDolphinPatch; yourself );
                yourself.


        dirVMCR := '{cf}\Object Arts\Dolphin Smalltalk 5.1'.
        dirStubs := '{reg:HKLM\Software\Object Arts\Dolphin Smalltalk
5.1,|{pf}\Object Arts\Dolphin Smalltalk 5.1}'.

        "Components"
        vmComponent := script componentsSection
                addComponentName:'vm'
                description:'Updated VM and stubs'.

        compilerComponent := script componentsSection
                addComponentName:'compiler'
                description:'Updated compiler'.


        ( script filesSection addFileName:source, '\DolphinVM005.dll' )
                belongTo:vmComponent;
                destinationDirectory:dirVMCR.

        ( script filesSection addFileName:source, '\DolphinCR005.dll' )
                belongTo:compilerComponent;
                destinationDirectory:dirVMCR.

        #( 'ConsoleToGo.exe' 'GUIToGo.exe' 'IPDolphinToGo.dll' ) do:[ :fileName |
                ( script filesSection addFileName:source, '\', fileName )
                        belongTo:vmComponent;
                        destinationDirectory:dirStubs;
                        ignoreVersion "Not a good idea!!".
        ].


I am hoping to get away from maintaining separate scripts, though that
won't happen right away, because my existing scripts "aint broke".
Until now, I've used this code only for packaging updates to Windows,
and it is still a little rough.

A revised script appears below.  As before, "you have been warned", and
it appears to work.  Caveat: I did not remove the registry entries, nor
have I agressively checked for unintended consequences of the installer.
  I deleted the files, and found that they returned after running the
revised installer.

Have a good one,

Bill




[Setup]
AppName = Dolphin Smalltalk binaries
AppVerName = Dolphin Smalltalk binaries
AppPublisher = Wilhelm K. Schwab, Ph.D. for Object Arts, Ltd.
AppPublisherURL = http://needle.anest.ufl.edu/anest4/bills/
AppSupportURL = http://needle.anest.ufl.edu/anest4/bills/
AppUpdatesURL = http://needle.anest.ufl.edu/anest4/bills/
DefaultDirName = {reg:HKLM\Software\Object Arts\Dolphin Smalltalk
5.1,|{pf}\Object Arts\Dolphin Smalltalk 5.1}
DisableDirPage = yes
DefaultGroupName = Dolphin Smalltalk binaries
DisableProgramGroupPage = yes
AlwaysRestart = no
OutputBaseFilename = Dolphin Smalltalk binaries
DisableStartupPrompt = yes


[Components]
Name:vm; Description:Updated VM and stubs; Types:full compact;
Name:compiler; Description:Updated compiler; Types:full compact;


[Files]
Source:C:\Installers\DolphinFixes\DolphinVM005.dll; DestDir:{cf}\Object
Arts\Dolphin Smalltalk 5.1; Components: vm
Source:C:\Installers\DolphinFixes\DolphinCR005.dll; DestDir:{cf}\Object
Arts\Dolphin Smalltalk 5.1; Components: compiler
Source:C:\Installers\DolphinFixes\ConsoleToGo.exe;
DestDir:{reg:HKLM\Software\Object Arts\Dolphin Smalltalk
5.1,|{pf}\Object Arts\Dolphin Smalltalk 5.1}; Flags: ignoreversion;
Components: vm
Source:C:\Installers\DolphinFixes\GUIToGo.exe;
DestDir:{reg:HKLM\Software\Object Arts\Dolphin Smalltalk
5.1,|{pf}\Object Arts\Dolphin Smalltalk 5.1}; Flags: ignoreversion;
Components: vm
Source:C:\Installers\DolphinFixes\IPDolphinToGo.dll;
DestDir:{reg:HKLM\Software\Object Arts\Dolphin Smalltalk
5.1,|{pf}\Object Arts\Dolphin Smalltalk 5.1}; Flags: ignoreversion;
Components: vm



--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:c811dj$vti$[hidden email]...
>
> Nice!  Using pf/cf is clearly the right thing to do.  Did you reverse
> engineer "reg:HKLM\Software\Object Arts\Dolphin Smalltalk 5.1", or is
> that documented?  I see the |, so it should work if not present, but
> what if it has been modified?

I just figured that Dolphin probably had a way to know where it was
installed and looked for what I thought was a likely registry key.  Since I
know I did not create that key the Dolphin setup must have.  Additionally
given the default we provide it is not really critical for it to be there.
If someone manually moved the files without changing the registry or changed
the registry entry without moving the files then I guess that would be a
problem.  However there is only so much one can do to handle exceptional
circumstances.  I suppose one could set the default application directory
based on the registry key then show it to the user and let them select a
different location (if they know that they moved their files).  However I
suspect that most people don't move their program files after installation.
Besides anyone who does that probably will want to update their files
manually anyway. ;)

One other very minor suggestion would be to use script relative paths for
the source files rather than absolute paths.  That would allow others to use
what ever directory structure they want more easily (like on a network drive
or something).

Chris

Chris,

> One other very minor suggestion would be to use script relative paths for
> the source files rather than absolute paths.  That would allow others to use
> what ever directory structure they want more easily (like on a network drive
> or something).

For reasons unknown (or perhaps simply forgotten), I gravitated toward
absolute paths and have not regretted it (yet??).  The more I pull into
Smalltalk code, the "cheaper" the scripts become.  My hunch is that as I
get better at writing the Smalltalk methods, the scripts will use
absolute paths for clarity, with the Smalltalk code using a mix of
absolute and image-relative paths as appropriate.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

On Fri, 14 May 2004 13:38:26 -0500,
Bill Schwab <[hidden email]> wrote:
> Chris,
>
>> One other very minor suggestion would be to use script relative paths for
>> the source files rather than absolute paths.  That would allow others to use
>> what ever directory structure they want more easily (like on a network drive
>> or something).
>
> For reasons unknown (or perhaps simply forgotten), I gravitated toward
> absolute paths and have not regretted it (yet??).

Although I'm about four months late, I can predict that you will run
into trouble with non-English systems, as e.g. in Germany "Program
Files" is called "Programme".

s.