Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2003:
[Freeciv-Dev] Re: (PR#6831) [CVS 2003-11-10] GTK+ Client Memory Allocati
Home

[Freeciv-Dev] Re: (PR#6831) [CVS 2003-11-10] GTK+ Client Memory Allocati

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: awilkins@xxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#6831) [CVS 2003-11-10] GTK+ Client Memory Allocation failure
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Tue, 11 Nov 2003 04:49:50 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6831 >

On Mon, Nov 10, 2003 at 11:09:28PM -0800, awilkins@xxxxxxxxxxxx wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6831 >
> 
> Platform information:
> 
> linux 2.4.20-20.7 i686
> gtk+ 2.0.2
> imlib 1.9.13
> glib 2.0.1
> gcc 2.9.6 and 3.3
> 
> I have a fairly large saved game (around 1600 cities; 2700 units).  I 
> start the server using this saved game, start the client, connect, and 
> then start the game.  The output from the client is as follows:
> 
> 1: Cannot find sound spec-file "stdsounds".
> 1: To get sound you need to download a sound set!
> 1: Get sound sets from 
> <ftp://ftp.freeciv.org/freeciv/contrib/sounds/sets>.
> 1: Will continue with disabled sounds.
> 2: LANGUAGE="en-us"
> 0: Detected fatal error in mem.c line 41:
> 0: Out of memory trying to malloc 1684370035 bytes at line 226 of 
> attribute.c.
> civclient: shared.c:665: real_die: Assertion `0' failed.
> Aborted
> 
> The back trace is:
> 
> #0  0x42029331 in kill () from /lib/i686/libc.so.6
> #1  0x4047bbdb in raise () from /lib/i686/libpthread.so.0
> #2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
> #3  0x42022ecb in __assert_fail () from /lib/i686/libc.so.6
> #4  0x080cbc06 in real_die () at shared.c:665
> #5  0x080c824e in handle_alloc_failure (size=0, called_as=0x0, line=0, 
>     file=0x0) at mem.c:41
> #6  0x080c82b0 in fc_real_malloc (size=1684370035, 
>     called_as=0x80e4eb2 "malloc", line=226, file=0x80d641d "attribute.c")
>     at mem.c:60
> #7  0x08052eab in unserialize_hash (hash=0x834abe8, data=0x0, 
>     data_length=1684370035) at attribute.c:226
> #8  0x08053072 in attribute_restore () at attribute.c:276
> #9  0x0805615d in handle_packet_input (packet=0x0, type=0) at 
> civclient.c:453
> #10 0x080596eb in input_from_server (fd=6) at clinet.c:330
> #11 0x40233e26 in gdk_get_show_events () from 
> /usr/lib/libgdk-x11-2.0.so.0
> #12 0x403ae831 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
> #13 0x4038fdd3 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
> #14 0x40390c51 in g_main_context_dispatch () from 
> /usr/lib/libglib-2.0.so.0
> #15 0x40391011 in g_main_context_iterate () from 
> /usr/lib/libglib-2.0.so.0
> #16 0x40391720 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #17 0x400cd2b3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #18 0x0808d8a8 in ui_main (argc=1, argv=0xbfffde14) at gui_main.c:1190
> #19 0x08055856 in main (argc=1, argv=0xbfffde14) at civclient.c:244
> #20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
> 
> The save file is located at:
> 
> http://www.stanford.edu/~awilkins/game-09-+0987a.sav.gz
> 
> For comparison purposes, I also have a slightly earlier version of the 
> save file which doesn't cause the client to immediately crash on 
> connecting; it is at:
> 
> http://www.stanford.edu/~awilkins/game-09-+0987.sav.gz 
> 
> It strikes me that the amount of memory that the client is attempting to 
> allocate here (over 1 1/2 GB!) is excessive, to say the least, 
> especially given that I was able to play up to the point of generating 
> the save file.  However, I don't know enough about the specifics of what 
> FreeCiv is allocating memory for to determine exactly why this is 
> occuring.

What a monster game!

The serialized attributes are corrupt. Attributes are used by CMA to
store the settings. This corruption causes the funny effect of wanting
a very large amount of memory at the deserialization.

It looks similar to PR#2838. Also in the current case the savegame
looks wrong after part 44.

I have no idea what caused this.

Can you reproduce this? Can you list everything which is not-normal in
your usage? Like multiple clients.

The most likely cause I can imagine is that the client got
disconnected during the attribute sending. And since attribute sending
isn't atomic you end up with a mix of old a new data in the savegame.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 checking for the vaidity of the Maxwell laws on this machine... ok
 checking if e=mc^2... ok
 checking if we can safely swap on /dev/fd0... yes
    -- kvirc 2.0.0's configure 




[Prev in Thread] Current Thread [Next in Thread]