Program that crashes at runtime, runs well in debug mode!

[paravantis]

Paul,

You are, as usually, right on all points.

We do have plenty of patience so worry not.


John

[John S]

I tried a few variations of the following code to try to make it crash.  I thought that the nested trims caused some trouble but this simple code doesn't crash.

Code Select Expand


def test as string
test = "  white space before and after  "

test = ""
print "+",test,"+"

test = LTRIM$(RTRIM$(test))
print "+",test,"+"

PRINT "Press Any Key To Close"
DO:UNTIL INKEY$ <> ""



Then I tried:

Code Select Expand

as string
test = "  white space before and after  "

print "+",test,"+"

test = TRIM(test)
print "+",test,"+"

PRINT "Press Any Key To Close"
DO:UNTIL INKEY$ <> ""

sub trim(s as string),string
return ltrim$(rtrim$(s))
endsub

sub trimN(n as double),string
return trim(str$(n))
endsub



edit:  I could NOT get it to crash.  John, have you tried isolating this area of code to try to duplicate the failure?

[J B Wood (Zumwalt)]

There is a problem somewhere in an inner loop.
I'll look at this more when I get home, heading to see Santa..

[paravantis]

John S,

After a full day in front of my computer, I now see floaters and have decided to let Paul slay the beast!

He seems to think there is memory corruption somewhere and it seems to me that playing around with code trying to make it crash may not be very fruitful!

Needless to say that I appreciate your kind endeavors!


John

[Ionic Wind Support Team]

OK found it.  See I only needed a little time.  Don't know if you could call it a bug, just a misunderstanding between me and some assembly code

For years I have been using a fast string copy routine that uses aligned dwords to move data 4 bytes at a time instead of one.  Much faster than other methods.  And it works very fast.  The problem is in some cases it will copy a dword worth of data to the end of the string, causing 1-3 bytes extra needed in the destination memory.   When you are working with defined strings this isn't a problem

string a
a = ltrim$(a)

There are 255 bytes there.

a = ltrim$(rtrim$(a))

The output of rtrim$ is located in heap memory, which is allocated to the exact length of the return plus 1 for the NULL.  ltrim$ uses the fast copy routine to remove the space to another allocated string which is then returned. 

So lets say for example the initial string is " hello ".  Which is 8 bytes long.  rtrim$ allocates a return string that is 7 bytes long and copies up to the space, using that fast string copy routine.  Since it is only 7 bytes the NULL sits on a partial dword boundry and it causes 1 extra byte to overwrite the destination memory.

Now that overwrite may or may not cause an exception, depending on how close to the end of heap block it was overwritten at.

Anyway I have a solution for it, of course, and will have an update this evening.

Your program was tested after the change for all grid sizes from 4 - 20 using debug mode 2 with no more crashes.

Paul.

[paravantis]

Do I earn the title of "misunderstanding between Paul and assembly"-hunter extraordinaire or what?

At how many such kills, do I earn a free copy of the next major version of eBasic?


John

[seberbach]

Paul, someday you might start handing out T-shirts for people like John........

Steve

[Ionic Wind Support Team]

John,
At least two more kills

Also to answer your previous question... when you debug an executable windows handles heap memory differently, to catch things like overwrites.  It allocates more than the requested size to place guard bytes around the allocated block.  Unfortunately it never generated a proper exception for me to trace. 

Paul.

[paravantis]

Paul,

If you would care to forward me a "beta" version of the next update to fiddle with prior to releasing it, I am game.

This because I seem to have an affinity to ...issues.

Seriously: put me on the beta testers group!

John

[Zen]

We don't have a beta testers group as such. Basically, you find a bug and Paul fixes it. It is already out of beta stages, hence it being released but obvioulsy some bugs don't get found no matter how hard you try to find them.

Lewis

[barry]

In my last job before retirement I wrote code to process mission critical data being sent to us from our transfer agent overnight.  My assigned task in writing this was to make it perfect.  Yes, my bosses believed in perfection and I was supposed not to disillusion them.

Anyway it all worked perfectly for 7 years, processing several million data records each night without fail until it finally found that one combination I hadn't considered.  I was no longer involved in that project and it took a while for them to call me in since that program had been so trouble-free they only considered the possibility it could be at fault when everything else had been eliminated.

When they did call me in I found that very weird combination of data that tripped it up, fixed the program, and everyone was happy again.

In my entire career that is the bug of which I'm most proud.

Barry  (who knows there ain't no bug-free code)