esteban.tester@gmail.com :

Could you let us know if, while running "gnobots2" from a console, you see this
error message:
" /dev/dsp: no such device "

If so, we will be able to resolve this bug as #162086.

(Side note for Callum: I'd trace back my guess about Ubuntu doing something
wrong to Bug #19602 . Pehaps libgnome deserves a bug about this anyway? We
shouldn't be crashing. I'll try to make an Ubuntu LiveCD crash on me this week
and see what I can make out of all this.)

no, i dont see this error message " /dev/dsp: no such device "

My system have sound card device and it's ok.

regards
Esteban

Esteban: Thanks for the report and reply, it helps... Since this is a live CD, 
you probably can't do any more debugging on your end. 

Others:
I'm feeling a bit of regret, as this may also be the case in Bug #19602 (the 
dsp message and crash may be unrelated)... it doesn't help when more than one 
thing can go wrong at a time.

I can reproduce this with my Warty Live CD and my old Toshiba laptop. The crash
occurs in draw_tile_pixmap while it is constructing the arguments for
gdk_draw_pixbuf. This means either the area or the pno variables are bad or the
pixbufs aren't loaded correctly. Given that the background has already been
drawn (this crash is quite late during start-up) I am pretty certain the area is
OK. My bet is on a pixbuf loader not doing the right thing.

I'll look at it closer tomorrow night. Once I remember my x86 assembler and
stack formats.

Another quick note, but no resolution. The program is definitely failing when it
is trying to reference game_graphics[pno]->pixbuf. pno is sane (=1) but
game_graphics[1] is 0, so naturally it segfaults when trying to get to the
pixbuf  element. This indicates that the pixbufs have failed to load. Using eog
on the live CD to look at the same file succeeds (it also uses gdk-pixbuf), so
it is likely that gnobots is doing something subtely wrong. 

The error checking is bad. It assumes that if it can find one of the files it
wants then everything is OK. This obviously detects the case where the
installation hasn't happened, but doesn't pick up the case where individual
files have gone bad. Worse still we load files from two different places using
two different pieces of code to construct filenames and the like. Naturally the
one that is failing is not the one that is checked. This problem is of course
unrelated to the real one: why can't we load the graphics on the live CD.

I have stopped it crashing. However I haven't removed the root cause, just been
gracious about not finding the graphics. I am not entirely sure what is going
on, the program should scan the graphics directory to see how many likely
candidates there are and then rewind the directory and rescan, this time trying
to load the likely candidates. Unfortunately the first call to g_dir_read_name
returns NULL and nothing gets loaded. Since g_dir_rewind is one of those
functions that "never fails" I assume that there is an error with the
g_dir_read_name call. Which is strange given that it worked the first time. Go
figure.

The directory rewinding problem is not gnobots fault. The following code when
run almost anywhere outside of /home on the Warty Live CD only prints one
version of the directory listing:

#!/usr/bin/perl

opendir DIR, ".";
print join(", ",readdir(DIR)), "\n";
rewinddir(DIR);
print join(", ",readdir(DIR)), "\n";
closedir(DIR);

I've fixed the GNOME end, the rest is being marked as NOTGNOME. I'll file a bug
with Ubuntu tomorrow, but I hear they have completely revised their live CD
system for Hoary. In any event, there ain't any way to update the Live CD.