| View previous topic :: View next topic |
| Author |
Message |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8283
Location: Salford, UK
|
 Posted: Thu Mar 17, 2011 11:30 am Post subject: |
 |
|
I don't know why the program does not simply crash on all machines with this OS.
The memory is allocated internally but the internal initialisation to zero fails suggesting that the memory is locked. But why does it recover and continue on some machines but not on others? Strange. Might the default exception handling be different or is something else? |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8283
Location: Salford, UK
|
| Posted: Thu Mar 17, 2011 6:03 pm Post subject: |
|
|
| I have fixed this bug within salflibc.dll but it is too late to include this in the impending release. I can send you a test DLL after the release of 6.05. |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Thu Mar 17, 2011 7:03 pm Post subject: |
|
|
Thanks for tracking this down.
| Quote: |
| I can send you a test DLL after the release of 6.05. |
That would be nice, though maybe you can even add the DLL to the release package as additional file somewhere, should it be of use for other people or for testing purposes.
Also maybe you can elaborate a bit on whether the fix does strictly affect the CHECKMATE build only, or if the allocate of a release or debug build can cause such a strange abort of the drawing routine as well. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8283
Location: Salford, UK
|
| Posted: Fri Mar 18, 2011 8:48 am Post subject: |
|
|
| I have identified and fixed a bug that only relates to /check (and any switch that implies /check). I have had no reports of failure with /debug or release mode. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
