Re: [Freeciv-Dev] (PR#39344) Crash in 2.1beta4, SIGSEGV with 0x0fe16fec in strlen () from /lib/libc.so.6
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 2007/4/17, Jason Dorje Short [EMAIL PROTECTED]: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 Ulrik Sverdrup wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 Attached a savegame that crashes freeciv 2.1 beta 4 (compiled myself from linux source on Ubuntu 6.10/ppc) Steps to reproduce: Load the attached savegame, and play as the hittites (username nn). Press end turn at once, and the game crashes. gdb backtrace is really short: Program received signal SIGSEGV, Segmentation fault. 0x0fe16fec in strlen () from /lib/libc.so.6 Seems like some string error/ null pointer thing. I suspect this is the same as a bug I fixed yesterday (which I can't reproduce myself anyway since it depends on your version of libc). If you're compiling from source you could consider getting the SVN version of the 2.1 branch: svn co svn://svn.gna.org/svn/freeciv/branches/S2_1 otherwise, if you can show a full backtrace that will confirm if it's the same problem. Take the core file and run gdb civserver core then type bt. -jason Thanks for the pointers. I tried compiling current svn and trying the civserver with the same savegame, and it still crashes! I can't get it to produce a core file, but with gdb online, this is the bt backtrace: (gdb) bt #0 0x0fe16fec in strlen () from /lib/libc.so.6 #1 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #2 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #3 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #4 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #5 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #6 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #7 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #8 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #9 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #10 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #11 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #12 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #13 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #14 0x0fde38d0 in vfprintf () from /lib/libc.so.6 #15 0x0fde38d0 in vfprintf () from /lib/libc.so.6 (which doesn't tell me much.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39328) Reproducible Crash When Changing Tech Goal (2.1.0-b4 and SVN Head)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39328
Hi again,
Jason Short wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39328
The current code is clearly wrong. The va_arg may be implemented as a
pointer rather than an inline array and so passing it multiple times to
vsnprintf will generate garbage results on some platforms while working
on others.
I doubt it matters whether there is an array of varargs structs or a
linked list of them. With an array, if you use an index too far beyond
the end, you will also get a segfault. The real problem is that the
array index or linked list current pointer is not reset to the beginning
after vsprintf et al. are used.
Nothing I've read indicates that va_start can be called multiple times
within the same function, though.
Allow me to requote from the man pages for the GNU libc implementation
of va_start(3):
Each invocation of va_start() must be matched by a corresponding
invocation of va_end() in the same function. After
the call va_end(ap) the variable ap is undefined. Multiple
transversals of the list, each bracketed by va_start() and
va_end() are possible.
So I'm applying the patch as-is.
You apparently applied the original patch and not the modified one that
I later submitted. The modified one had an additional fix for an
identical problem in another place in the same source file. That problem
also caused crashes. Attached to this message is a patch for that problem.
Eric
Index: server/plrhand.c
===
--- server/plrhand.c(revision 12924)
+++ server/plrhand.c(working copy)
@@ -768,14 +768,14 @@
{
va_list args;
- va_start(args, format);
players_iterate(other_player) {
+va_start(args, format);
if (!players_on_same_team(pplayer, other_player)) {
continue;
}
vnotify_conn(other_player-connections, ptile, event, format, args);
+va_end(args);
} players_iterate_end;
- va_end(args);
}
/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39344) Crash in 2.1beta4, SIGSEGV with 0x0fe16fec in strlen () from /lib/libc.so.6
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 Ulrik Sverdrup wrote: I tried compiling current svn and trying the civserver with the same savegame, and it still crashes! Oops, seems there was another instance of the bug (PR#39328). Can you still reproduce the crash (with SVN 2.1) now? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39344) Crash in 2.1beta4, SIGSEGV with 0x0fe16fec in strlen () from /lib/libc.so.6
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 2007/4/17, Jason Dorje Short [EMAIL PROTECTED]: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39344 Ulrik Sverdrup wrote: I tried compiling current svn and trying the civserver with the same savegame, and it still crashes! Oops, seems there was another instance of the bug (PR#39328). Can you still reproduce the crash (with SVN 2.1) now? -jason It seems to be fixed now. The crash is not reproducible by the former 100% crashing save. Now it doesn't crash and I can advance to the next turn (every time I try.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39346) Dithering and smooth graphics should be toggleable
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39346 Comparing 2.1 beta 4 to 2.0, 2.1 looks better because of changed drawing code. 2.1 has smoohter edges and looks better. Significan is however the big regression in drawing performance between 2.0 and 2.1. In 2.1, right-clicking around to move the map is painfully slow compared to 2.0 (where it is adequately quick!). I think this should be treated like a regression. Just like we have a checkbox for Better for of war drawing, please instate a toggle for dithering (or otherwise smooth graphics), if that can improve drawing performance. it would be greatly appreciated. For me 2.1 is a great step forward, also in usability all around. Graphics is nothing compared to this, and because of that I would like 2.1 to be as snappy as 2.0 (with amplio) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39346) Dithering and smooth graphics should be toggleable
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39346 Ulrik Sverdrup wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39346 Comparing 2.1 beta 4 to 2.0, 2.1 looks better because of changed drawing code. 2.1 has smoohter edges and looks better. Significan is however the big regression in drawing performance between 2.0 and 2.1. In 2.1, right-clicking around to move the map is painfully slow compared to 2.0 (where it is adequately quick!). I think this should be treated like a regression. Just like we have a checkbox for Better for of war drawing, please instate a toggle for dithering (or otherwise smooth graphics), if that can improve drawing performance. it would be greatly appreciated. For me 2.1 is a great step forward, also in usability all around. Graphics is nothing compared to this, and because of that I would like 2.1 to be as snappy as 2.0 (with amplio) Amplio is not gonna be as fast as trident or isotrident; this is unavoidable. There ARE a lot of configurable options in the graphics section. Does playing with them improve things at all? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
