Fwd: game "Knights and Merchants" deadlocks

[Andreas Mohr]

Hi,

On Sat, Feb 04, 2006 at 01:47:42PM +0100, James Trotter wrote:
> On 2/4/06, Joris Huizer <jorishuizer at planet.nl> wrote:
> > I have this question: I have a game called "Knights and Merchants" which
> >   I sometimes play; I find it deadlocks each time after playing for an
> > hour or so
> > it seems it isn't a complete deadlock, sometimes some of sound comes
> > through between intervals of minutes or so; harddisk activity seems
> > extreme - the light is burning constantly.
> > I then usually decide to kill the program; as it opens fullscreen I
> > can't get to the xterm that launched it, so I try to get to a console;
> > The system is so slow that it takes some time to get to a console
> > <ctrl-alt-f1>, and login in may time out a few times before finaly
> > getting in (the cure to that one is simple: login before starting the
> > game...) - then it takes another minute or so to run ps and kill the
> > wine process

> This really sounds like a memory leak to me. Usually I'd use valgrind (
> http://valgrind.org/) to find memory leaks and such. Valgrind 3.1.0 works
> with wine, but it produces alot of output you'd have to look through and the
> program will run insanely slow. It might be worth a try.

I'd bet this isn't a "deadlock". Instead, your program is consuming massive
amounts of memory that your system cannot cope with, thus quickly running
into swap and tearing the whole system performance down due to excessive
swap activity.
No deadlock at all, simply massive overload.

A normal memory leak sounds less plausible to me, too.

May I suggest that this is caused by a memory "allocation" of a pointer variable
instead of a memory size variable?
Pointers (memory addresses) usually are in the 0x40XXXXXX or 0x08XXXXXX range,
so if you take those values as amount of memory to allocate...

IOW, perhaps there is a function parameter count mismatch in .spec files or
some other random stack trashing that leads to such high memory allocation
due to accessing the wrong variable.

You should probably try a
ulimit -S -m 128000000
, that will most likely kill the process then when everything goes haywire,
thus supporting my theory at least halfway.

Andreas Mohr