I found the message:

Image resolution is out of bounds,
using the default resolution instead.

from: app/pdb/image_cmds.c:3778

Any image? Are you sure it happens with any image? This message is from 
the implementation of gimp_image_set_resolution() which only few image
plug-ins ever use. We refuse to change the image's resolution if a
plug-in attempts to set some ridiculous values. Obviously this happens
here or I've messed up the check when I changed the FINITE() stuff
lately. Could you please attach a (small) test images that triggers
the behaviour you describe.

BTW, who is adding those stupid keywords? GIMP is not a GNOME2
application. And we will try to fix any bug, no matter if the keywords
contain PLEASEFIX.in big bold letters or not. Since I've seen this
before, I suspect that you've used some script or an application like
bug-buggy to create this bug-report ?!
 

So yes i have tried to open png and jpeg images mainly 32bpp ones and
i gave this for any picture i have tried (even the garnome-0.10.png
shipped with garnome 0.10.6
(http://www.gnome.org/~jdub/garnome/download/garnome-0.10.6.tar.gz in
the gnome/gnome-session/download directory). All pics open correctly
in gimp-1.2 but not with 1.3. And all display correctly in the
thumbnail of the layer dialog box.

I've tried to remove all gimp config but it doesn't do anything.

I was wondering if it was a translation error and that the problem
come from the depth of the picture but it isn't.

btw sorry for the keyword, but i whas using the web system and don't
really know the rules.

Just a little addition: the 1.3.5 version of gimp gave me the same
result than the 1.3.7. 
For the sample you required (i don't saw it before) you have the file
from garnome as I pointed before, or one of the picture from greg
martin: ex
http://students.washington.edu/gregm82/landoplenty/giants2_1600.jpg.

I can open the file w/o problems. If gimp-1.3.5 gave you the same
problem, it's definitely not related to my latest changes. Could you 
please check config.h (in the toplevel source dir) for occurences of
HAVE_FINITE and HAVE_ISFINITE and report back.

Created attachment 9271 [details]
There is a screen capture of what happened whem i open a file

So yes i the HAVE_FINITE and HAVE_ISFINITE are set in the config.h of
the top level directory. I have also made a trace of a session while
opening a jpeg file (1600x1200x32bits) and it seems that the probleme
don't came directly from image_set_resolution_invoker but that the
arguments sent to this function aren't correct.

there are the gdb print of the arguments sent to the function: 
 gimp -> {parent_instance = {parent_instance = {g_type_instance = {
        g_class = 0x82b87d0}, ref_count = 1, qdata = 0x8888b98}, 
    name = 0x88d88e0
"file:///mnt/bordel/customize_xp/customize/giants2_1600.jpg"}, config
= 0x82b63b8, be_verbose = 1, no_data = 0, no_interface = 1600, 
  message_handler = 1200, stack_trace_mode = GIMP_STACK_TRACE_NEVER, 
  main_loops = 0x40520000, gui_main_loop_func = 0, 
  gui_main_loop_quit_func = 0x40520000 <__strtod_internal+2832>, 
  gui_create_display_func = 0x1, gui_set_busy_func = 0, 
  gui_unset_busy_func = 0, gui_message_func = 0, busy = 1,
busy_idle_id = 1, 
  user_units = 0x0, n_user_units = 0, parasites = 0x2, paint_info_list
= 0x0, 
  modules = 0x0, write_modulerc = 1, images = 0x0, next_image_ID = 0, 
  next_guide_ID = 0, image_table = 0x0, next_item_ID = 143416040, 
  item_table = 0x88ad040, displays = 0x88af688, next_display_ID = 0, 
  global_buffer = 0x0, named_buffers = 0x0, brush_factory = 0x0, 
  pattern_factory = 0x0, gradient_factory = 0x88c4ea0, 
  palette_factory = 0x88ae6b0, procedural_ht = 0x0, load_procs = 0x1, 
  save_procs = 0x1, tool_info_list = 0x1, standard_tool_info = 0x1, 
  documents = 0x1, image_new_last_values = {width = 1, height = 1, 
    unit = GIMP_UNIT_INCH, xresolution = 0, yresolution = 1, 
    res_unit = GIMP_UNIT_PIXEL, type = GIMP_RGB, 
    fill_type = GIMP_FOREGROUND_FILL}, have_current_cut_buffer = 0, 
  context_list = 0x0, standard_context = 0x3fe00000, default_context =
0x0, 
  user_context = 0x0, current_context = 0x0}

 args ->
 args[0] = {arg_type = GIMP_PDB_IMAGE, value = {pdb_int = 1, 
    pdb_float = 2.121995791459338e-314, pdb_pointer = 0x1, pdb_color = {
      r = 2.121995791459338e-314, g = 0, b = -nan(0xfffff00000003), 
      a = 2.1219957909652723e-314}}}
 args[1] = {arg_type = GIMP_PDB_FLOAT, value = {pdb_int = 955449279, 
    pdb_float = 4.7205466509768836e-315, pdb_pointer = 0x38f2ffbf, 
    pdb_color = {r = 4.7205466509768836e-315, g = 0, 
      b = 2.1219957909652723e-314, a = -nan(0xfffffffffffff)}}}
 args[2] = {arg_type = GIMP_PDB_FLOAT, value = {pdb_int = 955449279, 
    pdb_float = 4.7205466509768836e-315, pdb_pointer = 0x38f2ffbf, 
    pdb_color = {r = 4.7205466509768836e-315, g = 0, b = 0, a = 0}}}

there is the gimage get from gimp_image_get_by_ID in the function:
 gimage = {parent_instance = {parent_instance = {parent_instance = {
        g_type_instance = {g_class = 0x820a10e}, ref_count = 136472544, 
        qdata = 0x8226820}, name = 0x81f70a8 "Austin Donnelly"}}, 
  gimp = 0x81f70a8, ID = 136402724, save_proc = 0x0, width = 3, 
  height = 136682848, xresolution = 0, yresolution =
2.7653129593878086e-313, 
  unit = 136451270, base_type = 136420933, cmap = 0x0, num_cols =
136356254, 
  dirty = 136451592, undo_on = 0, instance_count = 0, disp_count = 0, 
  tattoo_state = 0, shadow = 0x0, construct_flag = 0, proj_type =
136356239, 
  proj_bytes = 136472800, proj_level = 136472864, projection = 0x81f74e3, 
  guides = 0x81f74e3, layers = 0x8215724, channels = 0x0, vectors = 0x1, 
  layer_stack = 0x8259dd0, active_layer = 0x1, active_channel =
0x8259ddc, 
  active_vectors = 0x81aeef0, floating_sel = 0xd, selection_mask =
0x82214c6, 
  parasites = 0x8219e45, paths = 0x0, visible = {136356254, 136451601,
0, 0}, 
  active = {0, 0, 0, 0}, qmask_state = 136356219, qmask_inverted =
136473120, 
  qmask_color = {r = 1.488591466314523e-269, g = 1.6411672399192865e-269, 
    b = 4.2439915819305446e-314, a = 6.7530402338195269e-316}, 
  undo_stack = 0x0, redo_stack = 0x81aef50, undo_bytes = 13, 
  undo_levels = 136451270, group_count = 136420933, 
  pushing_undo_group = NO_UNDO_GROUP, new_undo_stack = 0x820a54c, 
  new_redo_stack = 0x8226b80, comp_preview = 0xe, 
  comp_preview_valid = 136450878}

And there is most iportant part of the backtrace at this point:

+ Trace 23934

From your screenshot I see that you are using a french locale. You
should probably have mentioned that.

I've just tried to start gimp-1.3 with LC_ALL set to fr_FR and I see
strange things happening: Gimp warns that he's not able to open my
devicerc file. This is not supposed to happen. The code in
app/widgets/gimpdevices.c explicitely checks the error code from
gimp_config_deserialize() and only calls g_message() if the file was
found but couldn't be parsed. This doesn't happen with other locales
I've tried. I'm confused.

Could you please try to run GIMP with the locale set en_US ?

I've spent some more thought on it and I have a new guess for the
cause of the problem. Could you please check if all your plug-ins are
uptodate and compiled against gimp-1.3.7. Perhaps the JPEG and PNG
plug-ins have not been built or installed and you are calling older
versions that have been compiled against an outdated version of libgimp.

For the locale i already have done that but on v1.3.5, so i'll try
tonight and i'll check for the plugin version too. 
Just to be sure: i've the gimp-1.2 for the debian sid distribution
installed in /usr and the v1.3.7 compilled by hand on /opt/gnome2
could this be a source of conflict ? (i don't think so but since what
you said about the strange locale thing ...)

So i've made the check you requested: changing the locale to C or
en_US doesn't change anything, and the plugins files have the same
date/time than gimp-1.3 (which is really the 1.3.7, have checked).

The logging messages of startup correctly said that the plugins are
loaded from /opt/gnome2/lib/gimp/1.3/plug-ins (and a directoy in my
home, but i've checked that it is empty). And lsof confirm that.

And to be sure i've tried loading a small .bmp picture but it won't
neither.

I was thinking about something: i am using for a while now gcc-3.1
with athlon optimisation activated. 
Did you think it may have a impact/be the source of the whole thing ?

That could be a possible cause of the problem. I haven't tried gcc-3.1
myself yet but I plan do so soon.

So ... yes it's due to gcc-3.1 optimizations: I have build gimp (only
him) without any optimization (-O0 -g) and, now it work. 

The only strange thing left is that when dialog box are shown directly
on the picture dialog and then are closed without moving (ex the gimp
loading dialog which automticaly close at end) the picture dialog
isn't refreshed correctly, i just need to take any other dialog box
and drag it over the gray region of the picture to made them
refreshed. Maybe it's a gcc-3.1 bug to ?

Did you try to compile with -O2 but w/o special optimizations for Athlon?

The problem of image windows that are sometimes not redrawn correctly
is a known bug and has nothing to do with your compiler.

not now. Actualy athlon optimization are only special memory alignment
if i remember correctly, but i will try this WE (and the -O3/-O4 which
seems to be of use in gcc-3.1) and i will report back monday.

I found the same problem as described above. Jeff Waugh indicated on
the garnome-maillinglist it might be because of compiler optimizations.
I was playing with those already so I decided to check if this
prognosis would turn out to be true. And it seems at least in my case
to hold water.
When I compile with '-O2' and all the rest of my optimization flags,
the problem does not exist. But when I use '-O3' the problem does arise.
According to the gcc-3.1 docs '-O3' adds '-finline-functions' and
'-frename-registers' options. I have not check wich of these flags
cause s the problem.

Here some details of my setup :
Mandrake 8.2
Garnome 0.12.2
CFLAGS += -O2 -falign-functions=4 -fomit-frame-pointer -funroll-loops
-mfancy-math-387 -pipe -march=pentium3 -msse -mfpmath=sse

I recompiled with '-O2' and '-frename-registers' and 
'-finline-functions' seperately. It turns out '-frename-registers' is
causing these problems.
The flag '-finline-functions' can be safely used as can be assumed. I
don't know what '-frename-registers' actually does, but I hope one of
the gimp-developers does know the answer.

In fact for me it work very well now with -O9 BUT without any athlon
optimisation (ie -mcpu=i386 -march=i386)

*** Bug 89053 has been marked as a duplicate of this bug. ***

by using CVSGnome 0.2.7 (also earlier versions) the gimp causes the
same problems by using:

COMPILERFLAGS="-O4 -w -pipe -march=athlon-xp -mcpu=athlon-xp"

will cause the same problems for me, this is really bothersome after a
while since everything else works perfectly with these settings. no
wait even if i downgrade to:

COMPILERFLAGS="-O2 -w -pipe -march=athlon-xp -mcpu=athlon-xp"

i am getting the same crappy results. only disabling all this will
make the gimp work correctly.

tested with gcc 3.1, gcc 3.1.1

*** Bug 90472 has been marked as a duplicate of this bug. ***

As reported by jens@ja-web.de in bug #90472, the same bug occurs with
gcc-3.2_pre running on a PIIIm processor.  The GIMP was compiled with
"-march=i686 -O3 -pipe".  He does not get the errors on another
machine (Athlon) using "march=i686 -O2 -pipe -funroll-loops
-fomit-frame-pointer".

So this confirms what has been discovered by Aschwin van der Woude:
the problem is most likely related to '-frename-registers' which is
included in -O3 and higher optimization levels.  It also requires a
CPU class of i586 or i686 (Pentium or Athlon) because the problem
does not occur if one selects -mcpu=i386 -march=i386, as reported by
Benoit Plessis.

By the way, we know that the bug happens for the 686 optimizations and
not for the base 386 CPU.  But did anyone check if the bug is also
triggered by the flags "-mcpu=i586 -march=i586"?

Shouldn't this now be closed as NOTABUG and possibly be reported as a
bug against gcc?

Dave.

Theoretically yes. In fact I didn't close it because people tend not
to search among closed bug reports and this one comes up very often
lately. Not closing it is an attempt to avoid duplicates.

We need to verify the bug still exists in a current gcc 3.2, and if
so, come up with a simple test case for the gcc folk to work with.

Problem still exists with gcc 3.2: compiled with gcc 3.2 (Mandrake
9.0) and following flags:

"-O2 -pipe -march=athlon -mcpu=athlon -fomit-frame-pointer"

When compiling with "-O2 -pipe -fomit-frame-pointer" everything works
fine.

As an addition to my previous comment and for those who want to optimize:

"-O2 -pipe -march=i686 -mcpu=686 -fomit-frame-pointer"

Worked fine on my Athlon, using gcc 3.2. Haven't tried this yet with -O3.

Hmm it doesn't seem to be mentioned. 
But as the first comment explained there was no image shown, except
for the thumbnail in the layer-dialog.
This is actually untrue, the image is there but the 'Opacity' is set
to 0%. At least that is what I remember from when I was testing it. I
haven't played with this lately.

Turns out it was an aliasing bug.

2002-11-25  Manish Singh  <yosh@gimp.org>

        * libgimpbase/gimpwire.c: use a union instead of separate types to
        read/write doubles so we don't violate C's aliasing rules. Fixes
        bug #85249.

Woohoo!  Thanks for finding and fixing that, Yosh!  That was a nasty
bug.

It might be a good idea to mention the aliasing bugs on the developers
mailing list or maybe even in some docs, so that nobody re-introduces
similar bugs later.  One good description of the aliasing bugs can be
found in Mark Mitchell's article in Dr.Dobb's Journal:
  http://www.ddj.com/documents/ddj0010d/
This is also briefly described in the documentation of the GCC option
-fstrict-aliasing:
  http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Optimize-Options.html