Update of bug #22180 (project freeciv):
Planned Release: = 2.6.0
___
Reply to this item at:
http://gna.org/bugs/?22180
___
Message sent
Follow-up Comment #26, bug #22180 (project freeciv):
Uh, that freeciv-web patch makes 1 to be returned as trait value for such
broken players. That's certainly going to make such player, if ever under AI
control, to behave strangely. Returning TRAIT_DEFAULT_VALUE (50) would make
much more sense.
Follow-up Comment #23, bug #22180 (project freeciv):
The same crash also occurs very often on the Freeciv-web servers running on
http://play.freeciv.org. It's running Freeciv server revision 25147. It
happens very often now, so a quick fix would be nice.
Here's a backtrace from a coredump:
#0
Follow-up Comment #24, bug #22180 (project freeciv):
I have created a patch which I'm currently running on the Freeciv-web server,
and it seems to have stopped all the segmentation-faults. It checks if
plr-ai_common.traits is NULL. I'm not sure if it is the perfect solution, but
it seems to solve
Follow-up Comment #25, bug #22180 (project freeciv):
There's a reason minimally tested development versions are usually not used in
production...
I'm not sure if it is the perfect solution
It probably works as workaround, but obviously it's not the correct solution
to get traits correctly
On Mon, 16 Jun 2014, Marko Lindqvist wrote:
Follow-up Comment #25, bug #22180 (project freeciv):
There's a reason minimally tested development versions are usually not used in
production...
True. However, the server isn't segfaulting any more, and a workaround was
created within a few hours.
Follow-up Comment #22, bug #22180 (project freeciv):
Hattusilis was a human player that I picked from the Hittite nation. Is
freeciv config information stored anywhere other than in ~/.freeciv?
___
Reply to this item at:
Follow-up Comment #18, bug #22180 (project freeciv):
Could this linked with bug #22126?
___
Reply to this item at:
http://gna.org/bugs/?22180
___
Message posté via/par Gna!
Follow-up Comment #19, bug #22180 (project freeciv):
Could this linked with bug #22126?
More probably to the original trait ranges change that was causing also bug
#22126. It changed when the traits get allocated, and this seems like they are
not correctly allocated (though why it then doesn't
Follow-up Comment #20, bug #22180 (project freeciv):
Here are the requested values except tr which didn't seem to be available in
the context I was in after the crash:
(lldb) print plr
(player *) $0 = 0x000102037200
(lldb) print player_name(plr)
(const char *) $1 = 0x000102037208
Follow-up Comment #21, bug #22180 (project freeciv):
Is Hattusilis human or AI player?
Obviously he has no traits allocated. There must be something special in how
he gets created (as I cannot easily reproduce this crash).
The message about using .freeciv-client-rc-2.4 just means that there's
URL:
http://gna.org/bugs/?22180
Summary: Server crashes after first turn in a new game.
Project: Freeciv
Submitted by: dhall555
Submitted on: Wed 11 Jun 2014 03:09:47 PM UTC
Category: None
Severity: 4 -
Follow-up Comment #1, bug #22180 (project freeciv):
Thank you for your bug report, Dennis. It would be nice if you could give some
additional information.
How often do it crash? Unless it always crashes it would be nice if you could
upload a savegame that will crash when pressing turn done. If
Follow-up Comment #2, bug #22180 (project freeciv):
Thanks for the reply Sveinung,
I have some immediate answers, the rest I will answer when I’ve had a chance
to run the server and client separately from the command line as you’ve
instructed.
I did build from source using the svn revision
Follow-up Comment #3, bug #22180 (project freeciv):
1: in get_flag() [plrdlg.c::599]: assertion 'x0 != -1' failed.
Just a quick note that these are known to happen in gtk3-client, and are
likely unrelated to the crash (especially as these are from the client and you
say that it's the server
Follow-up Comment #4, bug #22180 (project freeciv):
With the two separate command line windows I see a Segmentation fault: 11
message in the server window. The client output is the same as what was in my
initial bug report. I've attached a file with the contents from both output
windows.
This
Follow-up Comment #5, bug #22180 (project freeciv):
Response to Marko...
Yes the client keeps running and returns to the main menu.
___
Reply to this item at:
http://gna.org/bugs/?22180
___
Follow-up Comment #6, bug #22180 (project freeciv):
Unfortunately server seems to report no kind of errors or problems before it
crashes.
./configure --disable-nls --with-sdl-prefix=/usr/local --prefix=/usr/local
--enable-client=gtk3 --with-libiconv-prefix=/opt/local
Follow-up Comment #7, bug #22180 (project freeciv):
./configure [blahblah] --no-create --no-recursion
Then I notice that you have --no-create. Why is that? [...]
I don't even know what --no-recursion is supposed to do
FWIW, I get --no-create no-recursion in config.log when I go there to look
Follow-up Comment #8, bug #22180 (project freeciv):
Took the configure line from what was in configure.log. I don't remember
adding that either the -no-create or -no-recursion options and in my command
line history I have:
471 ./configure --disable-nls --with-sdl-prefix=/usr/local
Follow-up Comment #9, bug #22180 (project freeciv):
FWIW, I get --no-create no-recursion in config.log when I go there to look
what settings I used previously
FWIW^2 proper way to get that information is ./config.status --config
___
Follow-up Comment #10, bug #22180 (project freeciv):
Ok..
./config.status --config
'--disable-nls' '--with-sdl-prefix=/usr/local' '--prefix=/usr/local'
'--enable-client=gtk3' '--with-libiconv-prefix=/opt/local'
'--with-sdl-exec-prefix=/opt/local'
Follow-up Comment #11, bug #22180 (project freeciv):
Thank you for the extra information, Dennis.
_One other detail...the same build works fine with an existing/loaded game._
Just a suspicion: Do each new game look different or do you have the same
starting position on the same map etc? If they
Follow-up Comment #12, bug #22180 (project freeciv):
If they games look the same you have probably accidentally
stored a seed for the random number generator that produce a
game that triggers the bug.
Indeed, freeciv used to have a bug that seeds got saved with client settings
(I'm sure
Follow-up Comment #13, bug #22180 (project freeciv):
I'm starting from a different place each time. I've tried saving from the
command line and from the GUI before pressing turn done but both methods cause
a server fault:
...
Starting game.
2: Dido rules the Carthaginians.
...
2: Purandokht
Follow-up Comment #14, bug #22180 (project freeciv):
I don't think we can get any further with the information we have. If you can
provide us backtrace, that would be huge help. By default the core -file is
not generated, but as you have reproducible crash, just run the server in gdb
debugger.
Follow-up Comment #15, bug #22180 (project freeciv):
OS X Mavericks doesn't seem to be using GDB anymore so I used LLDB with a
different command to produce the backtrace:
dhall: '/save'
Process 57532 stopped
* thread #1: tid = 0x234bc, 0x000100062eb8 freeciv-server`sg_save_players
[inlined]
Follow-up Comment #16, bug #22180 (project freeciv):
Thanks. This crash is happened when you tried to save the game.
Could you do a sanity check that this is also your original problem (autosave
at turn change). Set server setting autosaves to empty value (set autosaves
) and test if you can
Follow-up Comment #17, bug #22180 (project freeciv):
With autosaves set to an empty value I was able to continue for several turns
in a new game and crashed only when I manually saved the game.
___
Reply to this item at:
29 matches
Mail list logo
