The four byte bug lives

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]... being
> copied to the stream ?

No, the current memory architecture does not move byte objects. However this
is an implementation detail that should not really be assumed. The code as
written is dangerous in that it is not future proof.

Regards

Blair

I wrote:

> Could you (when you have time) try rewriting the offending bit to:

Please don't bother after all -- my post crossed with the one where Blair
was saying that byte objects are never moved by the current GC.

    -- chris

Blair McGlashan <[hidden email]> wrote in message
news:aojnlc$n09c7$[hidden email]...
> We have identified a definite bug in WriteStream>>next:putAll:startingAt:,
> or more specifically the fact that FileStream does not override it. This
can
...

I will try this code.  However I don't believe that the example code that
causes the STB corruption problem that I posted uses a FileStream, I am
pretty sure it just uses a WriteStream as it is saving it in memory not to a
file.  Also I think Bill was using a SocketWriteStream when he encountered
the problem.

I don't guess there is any chance that the SP requirements for Dolphin 5 on
NT could be changed to a warning rather than forbidding the installation on
anything but the latest SP?  It would make it easier for me to trouble shoot
if I could have D5 running on my NT SP3 machine.

Chris

Chris,

> I don't guess there is any chance that the SP requirements for Dolphin 5
on
> NT could be changed to a warning rather than forbidding the installation
on
> anything but the latest SP?  It would make it easier for me to trouble
shoot
> if I could have D5 running on my NT SP3 machine.

Actually, until you mentioned it, I wasn't aware that the setup prevented
installing on anything less than SP6. However, looking at the MS
documentation it appears that SP6 is a requirement for the use of Windows
Installer 2.0 (which just happens to be what the latest version of
InstallShield uses).

http://www.microsoft.com/downloads/release.asp?releaseid=32832&NewList=1

I don't think there's much we can do about it I'm afraid.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Chris,

> > We have identified a definite bug in
WriteStream>>next:putAll:startingAt:,
> > or more specifically the fact that FileStream does not override it. This
> can
> ...
>
> I will try this code.  However I don't believe that the example code that
> causes the STB corruption problem that I posted uses a FileStream, I am
> pretty sure it just uses a WriteStream as it is saving it in memory not to
a
> file.  Also I think Bill was using a SocketWriteStream when he encountered
> the problem.

It was either SocketWriteStream or WriteStream that blew up.  Actually, it's
more likely WriteStream, as the binary filing typically gets done "long"
before anything is ever sent across the socket - encryption/etc.
requirements, combined with fear of and no small amount of lazyness
regarding integrating streams with cyphers and compression.  The approch I
use is a little inefficient, but it's easy to debug.

Just the same, I'll gladly accept any other bug fixes that happen to result
from the four byte hunt :)

Have a good one,

Bill

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

Blair McGlashan <[hidden email]> wrote in message
news:aojnlc$n09c7$[hidden email]...
>
> We have identified a definite bug in WriteStream>>next:putAll:startingAt:,
> or more specifically the fact that FileStream does not override it. This
can

Ok, I filed in the test, it failed, then I filed in the fix, retested, and
it passed.  I ran into an STB corruption before fileing in the new code, and
also after.  The fix does not seem to have any effect.  I got the D5
development environment working on NT by copying the files from a 2K
installation.

Interesting notes:  The location of the 4 byte corruption seems to at least
have a gravity for certain locations.  For example in my most recent test
with one particular dialog the corruption tends to happen  in a method name
( #''ÌÍLteAt:extent:' ).  In other views the corruption tended to be a
class name.  I am not sure if the corruption is always the same, it could
be, but it definitely has a tendency to corrupt the same location in a given
test object.

I have a zip file that contains three binary captures of the same corrupt
view STB.  It does seem to be happening in the same place so far, but with
different corrupt bytes.  I generated all of these corrupt files in the last
few minutes.  My code loops, and usually has a few successful iterations,
and then errors, so it is not always erroring on the first try.  Sometimes I
can reproduce these corruptions often in the course of a few minutes, and
sometimes I can go (running the test code every few minutes) for 10-20
minutes without a corruption.
http://www.mitchellscientific.com/temp/dolphin/4ByteSTBCoruptBin.ZIP

Perhaps this will assist you in seeing some sort of pattern.

Andy Bower <[hidden email]> wrote in message
news:aoks11$n7usg$[hidden email]...
>
> Actually, until you mentioned it, I wasn't aware that the setup prevented
> installing on anything less than SP6. However, looking at the MS
> documentation it appears that SP6 is a requirement for the use of Windows
> Installer 2.0 (which just happens to be what the latest version of
> InstallShield uses).

I had hoped it was as simple as an option you could uncheck.  Yet another
reason for me to "love" MSI.  It seems to be more about limiting than
empowering.  Perhaps I am just a cranky end user. ;)

> I don't think there's much we can do about it I'm afraid.

That's OK.  I got the D5 development environment working (I think) on NT by
copying the files from a 2K installation.  It is not a big deal since my NT
machine's days are numbered any way, and I don't really run Dolphin on it,
except for testing this STB stuff.

Chris

Blair McGlashan <[hidden email]> wrote in message
news:aoja9i$l82g0$[hidden email]...
...
> In summary I don't think we yet have enough to go on. A hotfix is
> undoubtedly useful, but I won't be satisfied until we can produce a
> reproduceable case that we can reliably correct, or failing that a
> reasonably explanation of what is wrong and why the fix works.

I will cooperate in any way that I can to further this investigation.  It is
too bad I can't just ship the computer there for analysis. ;)

I can't claim that my fix fixes anything more than the STB corruption on my
computer, which certainly may be a symptom of another real problem.  However
that problem/symptom was causing me to consider rewriting an application I
am developing to avoid using STB.  Now I feel comfortable using STB again.
Hopefully it is not false confidence. ;)

This bug seems to be very machine specific.  So if none of your machines
have a proclivity for STB corruptions you are not likely to ever be able to
reproduce it.  Let me know if you need any more info or want me to test
anything on my "problem machine".

Chris

rush <[hidden email]> wrote in message
news:aoj9bd$520t$[hidden email]...
> Chirs, do not get me wrong, I am, and I think also everyone else is very
> gratefull to your finding and effort you have putted into it. And certanly
> no one finds you obligated by any means to debug it any more. My writing
is
> more oriented towards OA, to provide them some information in hope that it
> can be of some help to them.

No problem.  Perhaps the limits of text expression have made my message
sound other than I intended.  I am happy to continue probing this issue
further.  However someone (OA, or anyone) else has to take the lead in
developing tests or fixes.  I will be glad to try them as my time permits.
I just have to get back to developing my application.  I offer my assistance
as OA cannot reproduce the problem on any of their machines.  If someone
else has easy access to a "problem" machine then perhaps they can test as
well.  At the moment it sounds like I have the most access to the most
problematic computer.

Chris

Chrisopher,

> Ok, I filed in the test, it failed, then I filed in the fix, retested, and
> it passed.  I ran into an STB corruption before fileing in the new code,
and
> also after.  The fix does not seem to have any effect.  I got the D5
> development environment working on NT by copying the files from a 2K
> installation.

I'd be interested to know if this was a "fresh" image that you used for the
test. It is possible that something happens to damage an image in such a way
that the bug will occur repeatedly in future. This might explain why we
never see it, because we haven't done what it takes to corrupt the image in
the same way (all the tests I've run have been from a fresh image). If it
wasn't a fresh image could you try your test under NT with one and let us
know what happens.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy Bower <[hidden email]> wrote in message
news:aolkm9$mp973$[hidden email]...
> I'd be interested to know if this was a "fresh" image that you used for
the
> test. It is possible that something happens to damage an image in such a
way

Yes, the image was quite fresh.  It is a virgin 5.0.1 image.  I use this
image (copies of it) to deploy D5 applications including my test EXE.  My
test EXE contains only my test code, none of my other code.  I do not get
STB corruptions with my D5 test EXE on my 2K machine, but I do on my NT
machine.  Also way back when I first encountered this problem I scrapped my
D4 image and moved my code back into a virgin D4 image hoping that it would
fix this issue, and the problem persisted.  Also the corruption happens in
both my D4 image and my D5 image but only on my NT machine.

And no I don't have any code in my image that overrides STB methods to
include an OS check, and a mechanism for randomly overwriting 4 bytes of
garbage. ;)

I don't think it is an image corruption because of above.  I don't think it
is a generic NT problem because some people with NT can not reproduce it,
and it can also happen on 2K (Bill's problem).  However it does seem to be
machine specific, and the OS among other things could be aggravating
factors.  I suspect that unless you have a machine that has a predisposition
for this problem you will never be able to reproduce it.

Chris

Andy,

> I don't think it is an image corruption because of above.  I don't think
it
> is a generic NT problem because some people with NT can not reproduce it,
> and it can also happen on 2K (Bill's problem).  However it does seem to be
> machine specific, and the OS among other things could be aggravating
> factors.  I suspect that unless you have a machine that has a
predisposition
> for this problem you will never be able to reproduce it.

I second Chris' read on this.  I do enough "damage" to an image that if it
were just me reporting it, I'd be very suspicious, but there is too much
independent evidence to pass it off as such.  I'm back from my trip, and
will try to get that "new" NT machine to reproduce the problem; if it does,
I *might* be able to ship it to you for a while (it does not belong to me).
In general, I strongly (emphatically even) urge you to collect a few junk
machines.  While you are quite correct that time is money, older machines
are more easily stressed to reveal bugs that won't show up under
silicon-rich conditions.  Remember that running a stress test on an old
machine wastes the _machine's_ time, not yours, and might reveal a bug that
you would not see any other way.

Have a good one,

Bill

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