STB View corruption...

I have mentioned this before, but I thought I would mention it again and
provide more information because it is still troubling me.

I am working with a view that frequently decides to become corrupt, but only
when I am working on a Windows NT machine.  The corruption occurs when a
view is saved to an STB byte array, this happens when it is saved, or even
tested.  The corruption does not occur consistently.  I can work with the
view for a little while with no problems, and then bang it becomes corrupt.
The kind corruption however does seem to be consistent.  It is always a
class name that gets mangled.  For example I just saw a corruption where
'IdentityDictionary' became  '"Qó
tityDictionary'.  This class name has been
corrupt before, but so have other class names as well.

Since the size of the corrupt portion of the class name seems to be 4 bytes
I suspect it may have something to do with a Long value, FYI: (LargeInteger
fromBytes: #[132 81 243 11]) = 200495492.  Does this number ring any bells?

I captured a good view and a bad view to files.  The files are the same
size.  I then did a binary compare:

C:\>fc /B 04182001badView.bin 04182001goodView.bin
Comparing files 04182001badView.bin and 04182001GOODVIEW.BIN
000000F5: 84 49
000000F6: 51 64
000000F7: F3 65
000000F8: 0B 6E

There is more information in my previous postings on this issue.  Is anyone
else doing serious view development on Windows NT with Dolphin 4.x?

Unfortunately I can't move entirely to Windows 2000 yet, so this corruption
problem is a bit of an issue.  I am also concerned about what impact this
issue may have in deployed applications on NT.  I am considering using STB
as an application data format, but I am not sure if I can trust it after
these issues.  So far it only seems to apply to views, but I do not
understand why.

I am currently using Dolphin 4.01.1.  If anyone has any thoughts about this
I would love to hear them.

Chris

Chris,

> I am working with a view that frequently decides to become corrupt, but
only
> when I am working on a Windows NT machine.

I'm assuming the other OS is 2k as opposed to 9x?  Do you ever work on 9x
boxes?


>  The corruption occurs when a
> view is saved to an STB byte array, this happens when it is saved, or even
> tested.  The corruption does not occur consistently.  I can work with the
> view for a little while with no problems, and then bang it becomes
corrupt.
> The kind corruption however does seem to be consistent.  It is always a
> class name that gets mangled.  For example I just saw a corruption where
> 'IdentityDictionary' became  '"Qó tityDictionary'.  This class name has
been
> corrupt before, but so have other class names as well.

Not that this is a solution, but, have you tried making the obvious repair?
It would be interesting to know whether the resulting resource loads.  If
you try it, make a backup first.


> Since the size of the corrupt portion of the class name seems to be 4
bytes
> I suspect it may have something to do with a Long value, FYI:
(LargeInteger
> fromBytes: #[132 81 243 11]) = 200495492.  Does this number ring any
bells?

I'm afraid that it does not sound familar (if you get 3.141592654..., then
give me a call<g>).  Are you saying that the number is always the same?

Most problems that I've had with the view composer have been related to
comlexity of the edited view.  On 9x, I once reached a situation in which
changing a style affecting the Shell's menu bar (max/min/close stuff) would
crash Dolphin every time.  The workaround was to cut the "guts" of the view
and paste it into another shell view with the desired settings.  IIRC, the
problem looked like it was occuring in the #recreate (or something like
that) method.  Often things like this are resource starvation problems,
though it could be a bad API call too.

One of the worst scenarios I can think of is that the problem is due to
different behavior in NT.  Of course, it might also be that NT is tough
enough to survive something that crashed 9x, and spared me the corruption.

Do you have any external interfacing and/or finalizable classes of your own
making?  If so, maybe one of them is doing some bad pointer arithmetic and
clobbering the data?

Another thing that comes to mind is ReferenceView>>filerProxy.  Some time
ago, I noted that Dolphin was crashing when I tried to save a particular
view.  Prior to that, I had noticed that saving it got to be quite
sloooooooooooooow.  Suspecting resource starvation, I tracked it back to
reference views and suggested a patch that is still in the image.  I mention
this not to take credit, but, to accept blame :(   It occurs to me that the
patch is probably not entirely thread safe.  While it's unlikely that it's
causing your problem, this is something to consider for a better implemetion
in a future release.


> Unfortunately I can't move entirely to Windows 2000 yet, so this
corruption
> problem is a bit of an issue.  I am also concerned about what impact this
> issue may have in deployed applications on NT.

My suspicion is that you'd be ok.  Of course, if you're not, then you'll
either get runtime errors or crash dumps, and on NT, these are likely to be
informative.


> I am considering using STB
> as an application data format, but I am not sure if I can trust it after
> these issues.

I'm doing fairly well with it.  Fortunately, the buffer+1 bug struck me and
not my users.


> So far it only seems to apply to views, but I do not
> understand why.

The view composer is (IMHO) one of the more complex parts of Dolphin.
That's understandable, because it tries to make OO sense of Windows' highly
non-OO GUI.  Along with that complexity, there have been some problems, and
there could easily be some more that we haven't yet uncovered.

One other thing to consider: do you have any old (V2, maybe V3) view
resources that might be doing lots of conversions?  I sometimes find the
need to start an old image to export a view and then import it into the new
version.  The export from an old version does an STB conversion using older
code rather than letting the newer code do it, and this sometimes helps.
However, I should mention that the errors that occur are obvious walkbacks
when trying to load a view resource.

Another thing that I find keeps me out of trouble is to treat errors on
presenter creation as being _really_ bad things.  By that I mean, that I
avoid saving the image after something like this happens.  If I get
surprised by a problem and did a lot of work since my last save, and know
that I have good and recent backup, then I might risk it.  Otherwise, I try
to get everything ready for "the test", save, and then jump into the tweaked
code.  If it quits, I note where, exit w/o saving, reload, (try to)fix it,
save, and repeat as needed.   Some of this comes from Dolphin's early days;
no doubt, some of my precautions could be relaxed.


> I am currently using Dolphin 4.01.1.  If anyone has any thoughts about
this
> I would love to hear them.

Sorry that none of this is likely to be useful.

Have a good one,

Bill

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

Bill Schwab <[hidden email]> wrote in message
news:9bmvsm$a28rp$[hidden email]...
>
> I'm assuming the other OS is 2k as opposed to 9x?  Do you ever work on 9x
> boxes?

Yes, the othe primary machine is 2k.  I have used it on ME, but not to a
great extent, and possably not with views.

> Not that this is a solution, but, have you tried making the obvious
repair?
> It would be interesting to know whether the resulting resource loads.  If
> you try it, make a backup first.

Yep, I used a binary editor and changed the eroneous bytes, then loaded the
view back in and it worked fine.  If I can't determin the cause of this
error then I might just rig up some kind of "just in time" error auto
correction in my NT image.  I guess I would have it try to guess the class
if it is corupt, or prompt me if it can't figure it out.  I had to do
something like this in another environment (Actor) due to a very odd object
mutation problem.

> (LargeInteger
> > fromBytes: #[132 81 243 11]) = 200495492.  Does this number ring any
> bells?
>
> I'm afraid that it does not sound familar (if you get 3.141592654..., then
> give me a call<g>).  Are you saying that the number is always the same?

No, I don't think the number is always the same.  I just wondered if it
looked like it was in some kind of address range or something.  It was a
long shot, but this whole issue seems odd so who knows.  Maybe intelligent
beings from Mars are trying to communicate with me by putting strange
numbers in my Dolphin views. ;)

> Do you have any external interfacing and/or finalizable classes of your
own
> making?  If so, maybe one of them is doing some bad pointer arithmetic and
> clobbering the data?

I don't think this is the case in the problem view.  I do have some blocks
in the view that use some of my own objects, but there is nothing really far
out about that.

> > I am considering using STB
> > as an application data format, but I am not sure if I can trust it after
> > these issues.
>
> I'm doing fairly well with it.  Fortunately, the buffer+1 bug struck me
and
> not my users.

The nice thing is that I believe I can use STB very easily.  I will test the
hell out of it before I decide to use it for real.  If it does not suite my
needs I will then code my own approach.  At least it looks like I can try
STB out without investing much effort so there is not much lost if I opt not
to use it.

I am glad you found that buffer bug as well.  That is not something I would
look forward to debugging, and I would not have been expecting the bug where
it was either. ;)

> Sorry that none of this is likely to be useful.

Actually at this point any feedback is useful.  Thanks for taking the time
to respond.

Chris