May I ask - have any double free errors been fixed in the Standard code in the last year or so? I am trying to track down the cause of this (http://forum.simutrans.com/index.php?topic=11211.new#new) in Experimental, which is currently based on Standard from about February 2012. The error is a double free error, which does not arise directly in Experimental specific code, as I have not written any code with malloc/free as opposed to new/delete (or new[]/delete[]). However, it is possible that something in Experimental might indirectly cause an error to manifest itself in Standard code. If, however, double free errors have been fixed recently in Standard, a fix is likely to be effected simply by merging the latest Standard code (as in the current RC on which Bernd Gabriel has done much work), so it would be most useful to know what the position is.
Thank you in advance!
I am not aware of any double-free error fixes in the recent past.
The message you are pointing too is a free of something which was not alloced. Not a double free, which is something very different. The compiler also internall calls free to delete stuff. You should run your server at least with symbols, those would give you a better idea and do not cost much performance. (Just skip the "strip sim" step when compiling.)
Thank you - this is very helpful. How would I be sure of getting a backtrace each time? The backtrace that I got was seemingly at random (it just interrupted my SSH session with the text). Is there a way of writing backtraces to a log file automatically, do you know?
Just pipe it somewhere when starting the game. If I understand what you mean by "interupted my SSh session" correctly, you really ought to do so anyway.
Ahh - do you mean modify the simctrl script (the one that runs the command to start/restart Simutrans) to tell it to put its output somewhere? If I may ask a rather elementary question - what is the syntax for that?
Or run it via gdb in a screen session?
Quote from: kierongreen on January 05, 2013, 02:17:05 AM
Or run it via gdb in a screen session?
Might that not substantially impair performance? I know that running in debug mode in Windows makes it too slow to run the current Bridgewater-Brunel game acceptably, whereas it runs at acceptable speed when fully optimised.
Optimization is done only at compile and link time when compiling to machine code (which is normal for C and C++, but not Java and C#). The debugger can't change that at runtime. It is possible to debug an optimized build, especially if symbols are present, though stepping through the instructions can be confusing.
I've recently read that on Windows, the heap behaves differently when the process is started from a compatible debugger. It might or might not be similar on Linux or whatever. Such heap behaviour is likely slower, but Simutrans does a bit of it's own memory management for time critical stuff if I remember right.
Quote from: Ters on January 04, 2013, 06:52:43 PM
Just pipe it somewhere when starting the game. If I understand what you mean by "interupted my SSh session" correctly, you really ought to do so anyway.
May I ask - what is the syntax for doing this?
Edit: Hmm - I think that this is already done in the simctrl script:
# Start up the server
if [ $1 = "start" ]; then
/bin/sh -c "( $simpath -server $port -server_id $server_id -server_name $server_name -server_comment $server_comment -debug $debug -lang en -objects $objects -load $save 2>&1 & echo \$! >&3 ) 3>$pidfile | logger -i -t $tag &"
elif [ $1 = "restart" ]; then
/bin/sh -c "( $simpath -server $port -server_id $server_id -server_name $server_name -server_comment $server_comment -debug $debug -lang en -objects $objects 2>&1 & echo \$! >&3 ) 3>$pidfile | logger -i -t $tag &"
fi
The interruption of the ssh session was, I think, a characteristic of that particular type of free error, and not actually part of Simutrans-Experimental's stderr at all.
The plotting to the screen is already a backtrace, and is generated by the library (aka more like the system) and hence put to stderr of the current active console, not the simutrans stderr. Thus you saw it on ssh.