Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
On Sat, Apr 25, 2009 at 8:23 PM, Mark Miesfeld wrote: > 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. Good thing I said "seems to be." I was 100% wrong on this, it was not the compiler at all but the programmers. ReadFile() takes a pointer to a 32-bit value to return actual count of bytes read. In the code clean up / move to 64-bit / conversion to the new API, the variable was changed to a size_t. In ReadFile() the variable was cast as a pointer to a 32-bit variable. Well, that's no good on 64-bit Windows. Anyhow, sorry I blamed the compiler, it wasn't a compiler bug at all. -- 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
On Sun, Apr 26, 2009 at 6:58 AM, Rick McGuire wrote: > Did you forget to paste the link? http://msdn.microsoft.com/en-us/library/ms246609.aspx Didn't have my coffee yet. -- 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
Did you forget to paste the link? On Sun, Apr 26, 2009 at 9:45 AM, Mark Miesfeld wrote: > On Sun, Apr 26, 2009 at 4:49 AM, Rick McGuire wrote: > >> It's starting to look like upgrading to VS 2008 might be a winner for >> this. I'm more willing to make this change than switch to the new >> version of SysFile. Can the two version coexist on the same machine, >> or do I need to uninstall 2005 first? > > Here's a link that says you can and has some info on things to do / > watch out for. > > I did'nt think you could, but I guess you can since the source is Microsoft. > > -- > 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
On Sun, Apr 26, 2009 at 4:49 AM, Rick McGuire wrote: > It's starting to look like upgrading to VS 2008 might be a winner for > this. I'm more willing to make this change than switch to the new > version of SysFile. Can the two version coexist on the same machine, > or do I need to uninstall 2005 first? Here's a link that says you can and has some info on things to do / watch out for. I did'nt think you could, but I guess you can since the source is Microsoft. -- 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
On Sun, Apr 26, 2009 at 4:49 AM, Rick McGuire wrote: > It's starting to look like upgrading to VS 2008 might be a winner for > this. I'm more willing to make this change than switch to the new > version of SysFile. I think upgrading to VS 2008 has less potential for letting a bug slip through to the release than switching to SysFile. I've been working with builds from both VS 2008 and VS 2005, it would just depend on which system I was on at the time -- 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
It's starting to look like upgrading to VS 2008 might be a winner for
this. I'm more willing to make this change than switch to the new
version of SysFile. Can the two version coexist on the same machine,
or do I need to uninstall 2005 first?
Rick
On Sat, Apr 25, 2009 at 11:23 PM, Mark Miesfeld 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=001E9FDC filedata->data=0 residual=0
> filedata->data == 0 ? 0
> GetLine: size=31452 scan=001EE48D 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
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 reloadingbut 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 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=001E9FDC filedata->data=0 residual=0
> filedata->data == 0 ? 0
> GetLine: size=31452 scan=001EE48D 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
Re: [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
Interesting ... would be interesting to see the asm generated in the
good/bad cases (/FAs option, I think)...
Only 64-bit Vista is a bit strange though (I'm on Vista 32, and Rick also
saw the problem on XP).
However, I think you may well be right about something bad in the 2005
compiler or libraries -- ran with the 2008 version for Friday evening, all
of yesterday, and a hour or so this morning -- no pesky 'r' seen.
Will switch to Rick's new version later this morning.
Mike
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
http://bit.ly/mfc
IBM UK (MP8), PO Box 31, Birmingham Road, Warwick, CV34 5JL
Mark Miesfeld wrote on 26/04/2009 04:23:04:
> Mark Miesfeld
> 26/04/2009 04:23
>
> Please respond to
> Open Object Rexx Developer Mailing List
>
> To
>
> ooRexx Dev List
>
> cc
>
> Subject
>
> [Oorexx-devel] Tracked down problem with: compiler, Vista, ?
>
> 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=001E9FDC filedata->data=0 residual=0
> filedata->data == 0 ? 0
> GetLine: size=31452 scan=001EE48D 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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
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
se
