This looks like a classic optimizer bug to me. For some reason, the
code generator has obviously decided it can used a cached version of
the data pointer for the if test rather than reloading....but it
appears to make that decision only for the if test. It might be
interesting to try declaring that value as volatile and see if things
change.
Rick
On Sat, Apr 25, 2009 at 11:23 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> Rick,
>
> In working on the SysFileSearch bug, I tracked down what seems to be a
> case where the VS 2005 compiler produces wrong code and the VS 2008
> produces code that works.
>
> It's bizarre, so it takes a bit to explain it. On Vista 64-bit, the
> GetLine() function causes a memory exception here:
>
> scan = (char *)memchr(filedata->scan, CH_NL, filedata->data);
>
> The exception comes because it has gone past the end of the file
> buffer. The check for the end of the buffer is right before, and the
> whole thing looks like:
>
> if (!(filedata->data)) { /* if out of current buffer */
> if (filedata->residual) { /* may be another buffer */
> ReadNextBuffer(filedata); /* try to read one */
> if (!filedata->data) /* nothing more? */
> return true; /* all done */
> }
> else
> return true; /* return EOF condition */
> }
> /* look for a carriage return */
> scan = (char *)memchr(filedata->scan, CH_NL, filedata->data);
>
> filedata->data keeps track of where in the buffer we are and when it
> is 0, we've used up the buffer.
>
> The bizarre thing is, when I compile with Visual Studio 2005, when
> filedata->data == 0, the if !(filedata->data) test passes and the
> function keeps going on past the end of the buffer. Eventually,
> memchr goes to compare memory it can't access.
>
> If I compile with Visual Studio 2008, then things work as they should.
> This is with the no debug build only. The debug build works fine
> when compiled with either VS 2005 or VS 2008.
>
> I sent you a text file with a lot output. It is easier to read when
> the lines don't wrap.
>
> I used this printf to show this behaviour:
>
> printf("GetLine: size=%u scan=%p filedata->data=%u residual=%u
> filedata->data == 0 ? %d\n",
> filedata->size, filedata->scan, filedata->data,
> filedata->residual, (filedata->data == 0));
>
>
> For the build that crashes you see this:
>
> GetLine: size=31452 scan=00000000001E9FDC filedata->data=0 residual=0
> filedata->data == 0 ? 0
> GetLine: size=31452 scan=00000000001EE48D filedata->data=4294949711
> residual=0 filedata->data == 0 ? 0
>
> You see that even though filedata->data does equal 0, (filedata->data
> == 0) returns 0.
>
> So, SysFileSearch keeps calling GetLine() until you finally reach
> memory that is not accessible.
>
> This only happens on Vista 64-bit, only on a no debug build, and only
> when the compiler is VS 2005. On XP 64-bit it works fine with either
> compiler. Also on 32-bit Vista it works fine with either compiler.
>
> If there was the same problem on Vista 32 bit, i.e. it crashed with
> the VS 2005 compiled version but worked with the VS 2008, then I was
> thinking maybe a similar thing is happening with Mike's problem.
> Still, if Mike can not reproduce his problem using the VS 2008
> compiled version, then maybe it is a similar thing.
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
