Moderator: OpenTTD Developers
Code: Select all
4>..\src\newgrf_debug_gui.cpp(627) : warning C4018: '<' : signed/unsigned mismatch
and Chill! 
The warning should be gone in 19738.ColdIce wrote: you`re right.. the problem is in trunk
clean r19736, I still get this
Enjoy.wtfspiff wrote: Thanks a lot ColdIce
Sometimes it works sometimes it doesn't. I do not yet know what triggers the failing on pasting the loaded template.deamonhunter11 wrote: The only problem is that there is a problem with saving and loading templates.
Below image is not the error. Just me and the copy and paste.
Ouch ... Do not use waypoints ...nighthawk_c_m wrote: Ok, I am having a crash of the game for a yet unknow reason ...
Thank you for the information. I will have to do some reading ...peebee wrote: There is a problem with waypoints and auto seperation in the last build. If the schedule contains a waypiont trains will no longer be seperated. I think that I've read about this problem in another thread.
Calvin Hsia's WebLog wrote: This is called a Buffer Overrun error. If the memory accessed beyond the string is not allocated to the process, then a C0000005 exception (Access Violation) will result. If this exception is unhandled by the process, then the ‘unhandled exception handler” of the OS will be invoked. This is typically Dr. Watson. (However, the memory may be legitimately accessed, but may be overwritten by a virus that takes advantage of a buffer overrun on a strcpy Standard Library function).
In the old days of Win3.11, there was no memory protection enforcement: Accessing any memory in the process address space was fair game. strlen would just cruise merrily through the process memory, even through non-owned memory, until it found a null byte. Thus, old code may run fine on old OS’s, but when run on a new OS, it might crash.
The C Standard Library (also known as the runtime library) is not part of the C language, but it is assumed by all C development environments (particularly the linker) to be available. Microsoft’s versions have “MSVCRT” in their names. When the string functions were defined, the strings were assumed to be character arrays with a terminating null byte. This implies possible buffer overruns, as well as that no strings can have embedded nulls (like binary data).
The C++ language has just as much accessibility to the C Standard library, although string classes and objects can be used. Thus buffer overruns are still around. Most processes that run on your computer today are primarily written in C or C++.
Using managed code in .NET, a string is an object that has a length property. No null terminating byte is assumed.
What are the consequences of a crash? If it occurs in a User mode application, then that process is no longer running, but all other running processes on the machine are still valid. If it occurs in a kernel mode application, such as a device driver, all bets are off because the erroneous code had much higher access rights to the machine than a user mode program.
Except for video driver crashes, I haven’t rebooted my machines in years due to a crash.
Most of the security bulletins and Windows Updates are due to buffer overruns. If the standard library had been defined to pass in a maximum length parameter along with every string buffer, many of these security patches would never exist.
Published Wednesday, June 30, 2004 4:36 PM by Calvin_Hsia
Filed under: Programming, C++, Windows API, Debugging
Wednesday, June 30, 2004 11:51 PM by josh wrote: std::string doesn't use a terminating nul, unless you're converting it from/to a C string. But you can't really pass std::strings between binaries compiled with different compilers, or even linked against different instances of the runtime library.
So according to Jeff, checking for a null pointer somewhere will solve it.Monday, May 03, 2010 5:09 PM by Jeff wrote: I just got it will a null pointer exception. Add to your code a check if your input is null.
Thank you for the link and the explanation Rubidium.Rubidium wrote: C0000005 is "just" what is called segmentation fault in Unices.
There is (or was) a small tool somewhere on the Microsoft website that could give you a function name (or file name) and line number given the executable and the crash location 004DD9F2. For anything more useful than that you need the .pdb from the compilation and the .dmp from the crash and load those in MSVC. That will usually give you a stack trace.
That savegame is better nighthawk_c_m.nighthawk_c_m wrote: Here is a savegame paused shortly before the crash occurs
Users browsing this forum: Bing [Bot] and 39 guests
