Bug 4141

I entered openttd at a terminal several minutes ago.

Using strace on the process shows ...
Trace of process 30225 - openttd
stat64("/home/dave/data/.operabackup/images/templates.services.openoffice.org.idx", {st_mode=S_IFREG|0664, st_size=
stat64("/home/dave/data/.operabackup/images/http%3A%2F%2F66.252.134.231%2Ffavicon.ico", {st_mode=S_IFREG|0664, st_s

It seems to be recursively running stat64 on every directory/file under
my home directory.

With a little over 40GB on an encrypted file system, that is going
to take far too long.

Oh. It just put out some text on the konsole ...
$ openttd
dbg: [misc] The file '/home/dave/data/software/cleanfeed-20020501.tar' isn't a valid tar-file
dbg: [misc] The file '/home/dave/data/software/unix.admin.horror-1.1.tar.tar' isn't a valid tar-file

What is this "game" doing?  I've killed the process now.

CC: (none) => davidwhodgins

x86_64

# urpmi openttd
In order to satisfy the 'timidity-instruments[== 2]' dependency, one of the following packages is needed:
 1- timidity-patch-freepats-20060219-14.mga1.noarch: Patch set for MIDI audio synthesis (to install)
 2- timidity-patch-gravis-1.0-29.mga1.noarch: Instruments for the timidity midi->wave converter/player (to install)
 3- timidity-patch-fluid-3.1-6.mga1.noarch: Pro-quality General Midi soundfont in GUS patch format (to install)
What is your choice? (1-3) 3
To satisfy dependencies, the following packages are going to be installed:
   Package                        Version      Release       Arch   
(medium "Core Release")
  TiMidity++                     2.13.2       30.mga1       x86_64  
  fluid-soundfont-common         3.1          6.mga1        noarch  
  openttd-opengfx                0.3.3        1.mga1        noarch  
(medium "Core Updates")
  openttd                        1.1.0        1.1.mga1      x86_64  
(medium "Core 32bit Release")
  openttd-openmsx                0.3.1        2.mga1        noarch  
  openttd-opensfx                0.2.3        3.mga1        noarch  
  timidity-patch-fluid           3.1          6.mga1        noarch  
225MB of additional disk space will be used.
115MB of packages will be retrieved.
Proceed with the installation of the 7 packages? (Y/n) y


My mirror is having a few troubles so will test x86_64 when it becomes available.

(In reply to comment #1)
> 
> What is this "game" doing?  I've killed the process now.

Dunno as I can't reproduce this. Works fine, at least on i586.

Testing the current version x86_64 I don't see the behaviour either. In fact I don't see any stat64. The only file stats are on /usr/share/games/openttd/ and ~/.openttd/

Still unable to test the update candidate, hopefully the mirror will sync overnight.

Very strange.  If I cd to /home, /, or /home/dave/tmp, before starting the game
it's fine.  It's only if the current directory is /home/dave that I'm seeing
the strange behaviour.

Skimming through the code, it looks like it's openttd-1.1.0/src/fileio.cpp
in TarScanner::DoScan that's doing the scan, although why it only happens
when I'm in my home directory, and doesn't happen if the current directory
is /home, is not clear.

Anyway, I don't consider this a blocker, as it works fine if started from
the menu.

As to waiting for the mirror to sync, might be a good idea to switch to
the  http://twiska.zarb.org mirror.

I've not been able to reproduce the behaviour you've seen Dave. I even removed ~/.openttd and reinstalled before starting and aside from a few X11 checks it isn't stat'ing anything outside those two directories for me. I dont see stat64 being used at all.

You can download addons for the game as tar files and the game scans for them at startup to catalogue them, apparently. It is odd that it scans your home directory, you'd think they would be in .openttd if anywhere. It appears to be normal though.

Gave up on linuxcabal so testing complete x86_64.

Are you happy to validate Dave or do you think it's worth reporting the odd behaviour you're seeing upstream?

It seems it looks in all directories in the current directory, but not
recursively.  I have 27 symlinks in my home directory, like ~/Documents
that link to directories in an encrypted filesystem with a little over
40GB of data.  Scanning all of those directories takes quite a while
on my system.

It isn't a regression. It only happens when you start it from the
command line, and you are in a directory where the combined
subdirectories have a lot of data, and doesn't happen when you
start it from the menu, so I'll go ahead and validate the update.

Could someone from the sysadmin team push the srpm
openttd-1.1.0-1.2.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory: This security update for openttd fixes CVE-2012-0049, 
A Denial of service (server) via slow read attack.

https://bugs.mageia.org/show_bug.cgi?id=4141

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

update pushed

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED