Any hint on how to identify this problem ? Thanks in advance.

Arno

You could try running the program with filemon (from 
sysinternals.com) running, and see if it reads some config file you 
forgot about...

if Gtk-Wimp is doing something similar as I've just done in 
gdk_screen_get_setting() to support using the default
font with gtk-apps, you can change it via the UI (on win98
the default menu font is 'MS Sans Serif', which appears
to be a bitmap font not used by Pango (any idea how to
get this info from the LOGFONT ?)

[...]
  else if (strcmp ("gtk-font-name", name) == 0)
    {
      NONCLIENTMETRICS ncm;
      ncm.cbSize = sizeof(NONCLIENTMETRICS);
      if (SystemParametersInfo (SPI_GETNONCLIENTMETRICS, ncm.cbSize,
&ncm, FALSE))
        {
          /* Pango finally uses GetDeviceCaps to scale, we use simple
approximation here */
          int nHeight = (0 > ncm.lfMenuFont.lfHeight ?
-3*ncm.lfMenuFont.lfHeight/4 : 10);
          if (OUT_STRING_PRECIS == ncm.lfMenuFont.lfOutPrecision)
            g_warning("Bitmap font");
          g_print ("precis %d qualiy %d\n", ncm.lfMenuFont.lfOutPrecision,
                                            ncm.lfMenuFont.lfQuality);

          if (ncm.lfMenuFont.lfFaceName &&
strlen(ncm.lfMenuFont.lfFaceName) > 0)
            {
              char* s = g_strdup_printf ("%s %d",
ncm.lfMenuFont.lfFaceName, nHeight);
              g_value_set_string (value, s);

              g_free(s);
              return TRUE;
            }
        }
    }

As noted above this is probably no gtk bu, setting NEEDSINFO

So this should actually be worked around in gtk-wimp?

no, this, in my opinion, shouldn't be worked around in gtk-wimp. 

pango shouldn't g_warning() (or worse...) when it can't load a particular font
by name. wimp only knows what windows tells it is the default font's name. i'm
not going to load fonts just to find out if they're bitmap or truetype. that's
pango-win32-fontmap's job. 

if pango returns null (preferably with a GError set), that's fine. if pango
returns another font in its place, that's fine. warnings, error dialogs, and
whatnot aren't.

reopening

Is this related to bug 142579?

Yes the lack of support for non-TrueType fonts, bug 142579, is the cause of the
problem.

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

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

See also bug #163740, in which the problem not only causes warnings (as reported
here and in the duplicates) but also causes a crash (abort with recursed error
message).  Just ignore the flames from the reporter when you read that bug...

I suspect that the problem in bug #163740 was caused by the fact that the
"Message Box" font was set to Sans Serif (mapped to a bitmap font), which
prevented the error dialog box from being displayed, which in turn caused glib
to give up.

As this can cause a crash, I think that it is appropriate to raise the severity
of this bug report.

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

Shouldn't this be easily fixable by providing a reasonable font configuration
with the GTK+ installer? AFAIK, GTK+ relies on fonts being available for the
"Sans", "Serif" and "Monospace" aliases. So it would be up to the installation
routines (or the user) to fulfill this requirement.

The fact that a library like Pango should avoid to ever call exit() is a
different, although related, aspect...

I am not sure that a font configuration in the installer would help, because the
GTK+ installer could see a "safe" configuration when it is started, but it could
be ruined later if the user switches to another Windows theme.  The user might not
even be aware of that, because some actions such as booting Windows in "safe" mode
or upgrading the driver for the video card could automatically reset the fonts
used.

The ideal solution would be to fix bug #142579 and allow bitmap fonts.  A
short-term solution would be to provide more than one fallback font for error
dialogs, or even to revert to the old console display ("DOS box" as some of them
called it) in case a font cannot be allocated for the error message.

> A short-term solution would be to provide more than one fallback
> font for error dialogs, or even to revert to the old console
> display ("DOS box" as some of them called it) in case a font
> cannot be allocated for the error message.

You are maybe confusing something here. GLib (which used to open console windows
for g_log() messages if there was no stdout/stderr) doesn't select any font or
anything like that for its FATAL messages. It calls MessageBox(), a pure Win32
API, nothing to do with Pango or GTK+.

Thanks for the clarification.  So my guess about why the warning message recursed
and became fatal in comment #12 was probably wrong, then?  I thought that the
fatal error was caused by the fact that GLib could not display a normal error
dialog in somes cases (bug #163740).  Sorry if my guess was wrong.

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

Raphael, the fatal error occurs in Pango. It happens if a certain font can't be
loaded and the fallback font also fails to load. IIRC that's where recursed
comes from. A quick look at the Pango code should allow you to verify that.

You are right, I should have investigated this a bit deeper.  But it looks like
I am not totally wrong, since the recursed message comes from glib/gmessage.c,
not from Pango.  Both "(recursed)" and "aborting..." are added when
G_LOG_FLAG_RECURSION is set, and that one is in turn set when the private
g_log_depth is > 0.   I am not sure that I followed everything correctly, but
based on my limited understanding of the win32 case, here is how I think that
the problem occurs:
- The application (the GIMP or Ethereal or any other) wants to display a warning
  message, which eventually ends up in g_logv().
- GTK+ for the win32 platform has a specific handler that displays a window for
  these messages.  In order to display the message dialog, Pango needs to find a
  font, which fails.
- This causes Pango to issue its own g_warning() from pango-fontmap.c because it
  cannot find a suitable font and will try to use a fallback.
- Problem: this g_warning() goes through the message handler again, which
  requires Pango to find a font again, which triggers the same g_warning().
- The recursion is detected by GLib, which decides to abort.

So unless I got something completely wrong (please correct me in that case),
the fatal error is in GLib, not in Pango itself.  Or more exactly, it is due
to the interaction between GLib and Pango invoked through the error handler.
Or to be even more picky, it is due to the interaction between GLib, Pango and
the theme that causes gtk to attempt to use a system font for the error message.

If my analysis was correct, there may be some other ways to solve this
problem (better than my vague suggestion in comment #15, to which Tor replied):
it looks like Pango does not even get a chance to use a fallback font!

The first g_warning() saying that it will try another font is immediately
causing the recursion.  Either Pango or the message handler used by gtk-win32
could guard against this particular recursion (using a private flag) in order to
avoid the fatal error.  This would at least give Pango a chance to continue and
only fail in case it cannot find any of the fallback fonts and gives up with the
funny message "All font failbacks failed!!!!" (this is the place where Pango
calls exit() directly, which was also the subject of some discussion).
Currently, the recursion in g_warning() is causing GLib to abort on the first
failed attempt to use a font, which is definitely sub-optimal.

If my analysis was correct, then it also explains why the problem is fatal for
some users and simply an annoyance for some others.  In the original description
of this bug report and some of its duplicates, Pango cannot find a font used for
the menus, but can find the one used for the error messages.  This causes many
warnings and slows down the application but is not fatal.  In bug #163740 and some
others, Pango cannot find the font for the error message: this triggers the
recursion and aborts the application.

If your analysis is correct, then the way to fix this is rather simple. Just
remove the code that attempts to open a window to display the message. This code
just doesn't belong there. Opening a message dialog should be left to the
application and doesn't belong into the toolkit. There's no message dialog on
the X11 platform neither.

Looking at it again, it appears though that your analysis is flawed. If I
understood Tor correctly in bug #162187, only FATAL messages cause a message-box
to appear. A fatal message causes a call to abort() anyway. So we would have
lost already.

No, the window that I mentioned in comment #20 is a standard GTK+ window created
by the handler for error messages.  I could be completely wrong as I do not use
Windows and this analysis is based only on a quick look at the relevant parts of
the code and some guesses based on the bug reports mentioned here.  But if I am
not mistaken, what Tor mentioned in bug #162187 is a case in which GLib uses a
Windows MessageBox (not a GTK+ dialog) as a last resort for displaying a fatal
error.

Regarding your comment #22, I don't think that it would help: if the application
installs its own GLib error handler and tries to open a message dialog (GTK+),
it could lead to the exact same error if Pango issues a g_warning().  It would
immediately cause a recursion and lead to a fatal error.

Due to the lack of a default console in Window, I think that it is a good thing
that the toolkit attemts to display the warnings in their own window.  Using a
console window ("DOS box") caused many problems.  Using a modal MessageBox would
not work either.

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

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

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

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

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

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

There were a bunch of related bug reports that had been closed as NOTGNOME or
INVALID on the basis that a workaround was mentioned in the gimp-win FAQ but they
were all related to the problem described here.  For half of them, this was the
fatal "recursed" case that caused GLib to abort on Pango warnings.

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

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

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

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

I am only a relative newbie at this, but are you aware that the error only 
ocurrs in Win98 not in XP. 
Win98 uses bitmapped fonts for the various message windows, while XP users TT 
fonts, but I gues I am only telling you how to suck eggs, sorry.  It seems to 
ocurr at many errors, not just loading files, but also occassionally when 
moving around folders and some other times, but I am sorry I can't reliably 
duplicate the latter for you.  Would'nt forcing a known available font for any 
error, or even return a message and input screen to accept a key stroke to 
clear the last action avoid a crash? 
I teach a group in a club of 300 members and even if we could back out of the 
crash without losing the work it would be a stop gap fix. 

I do want to point out that the bug report, Bug 165334, (sorry can't get your
lovely little cross out font), I was using Win XP. so based on what was said in
post #36 my original bug report is not related. i have since uninstalled Gimp2.0
and reinstalled it which has successfully fixed my problem until it shows up
again. who know when that will be.

Thanks a lot for not giving the necessary help when I asked

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

I can easily reproduce the "recursed" error on Windows XP using gimp-2-2
(compiled against GTK+ 2.4), gtk-2-6 and glib-2-6 from anoncvs using the
following steps:

1. Change the "message box font" in the windows display properties to "MS Sans
Serif" and use the Default theme in GIMP.
2. In GIMP, choose File - Save as and try to save as a file with an invalid
extension, like test.asdf

Now I get the error dialog, "Pango-WARNING (recursed) **: Couldn't load font "MS
Sans Serif 8" falling back to "Sans 8"  aborting...

Comment #20 is almost correct regarding the reason the "recursed" error occurs,
but it isn't GTK+ that has an error handler that displays a dialog, it is GIMP.
What happens is this:

1. file_save_dialog_save_image calls g_message to indicate that saving failed
2. gui_message is called (via g_logv, gimp_message_log_func and gimp_message)
3. gui_message tries to present the GIMP error dialog
4. To get the size of a label in the dialog, the extents of a pango layout is
calculated, which makes Pango try to load the font, which fails and calls g_log.
5. g_logv sees that depth is > 0 and sets the recursed flag. 
6. Recursed messages are considered fatal, so a message is shown with MessageBox
and the application is abort():ed.

(To reproduce, simply set a breakpoint on the MessageBox line in gmessages.c and
provoke the error as described earlier)

An ugly workaround is to make sure that recursed errors from Pango aren't
considered fatal:

  g_log_set_always_fatal (G_LOG_LEVEL_ERROR);
  g_log_set_fatal_mask ("Pango", G_LOG_LEVEL_ERROR);

(I tested this by putting it in gui_libs_init in gimp/app/gui/gui.c and it seems
to work)

Created attachment 37371 [details]
Backtrace from "recursed" error message

Here's a backtrace. The interesting parts are frames #0-#10 and #90-#96

Hmm, the workaround doesn't work with Pango older than 1.8 since Pango didn't
set a log domain before that version.

A comment was added to bug #163740 (which is marked
invalid by some petulant child despite that it is a
valid report of a still open bug) to come here to
see a "correct diagnosis" of the bug. I came, I saw,
and "you collectively" are still somewhat missing
the point. The bug is a design error, and so far the
efforts to fix it are treating it as a code error.

THE bug is that an error report MUST be designed to
be always successful when evoked, and one here is
not.

In usual software development in the large, making
error reporting work failure free is pretty much
issue #1 to get correct.

    Until error reports work, fixing those reported
    errors is stymied; there is no way to indicate
    even what they are, beyond "software fall down
    go 'boom'".

In particular here, the message widget for the error
fails to keep its contract to display successfully.

There are many well known ways this can go wrong,
each with well known solutions.

    For one example, running out of memory for
    creating and displaying the error report when
    the error is an "out of memory" error is a very
    commonly seen issue, solved by pre-allocating
    sufficient error reporting memory when the
    application initializes.

Here the problem is that the error reporting
mechanism is trying to use a font which it is not
capable of using, due to failure to support the font
(which is the Win98 default for message boxes such as
the error report message box) used in reporting the
error.

The solution is very similar: have the needed
resource guaranteed to be in hand right at the start
of at run-time initiation, so that even errors at
initiation time are guaranteed to be successfully
reported.

If that means that this agglomeration of software
must embed its own font for error requestors, so be
it [and I suggest that should have been the design
from the beginning, since no other guarantee that a
font would be available for error reporting is
believable].

The _specific_ error as seen in "out of the box"
Win98 systems is that, in the process of handling
any of a wide variety of unrelated errors, the error
cascades due to encountering a call for an
unsupported font in producing the error message box.
The error report from Pango then tries to use,
recursively, in the message box for reporting an
unsupported font error, the same font whose
unsupported type _caused_ the error.

That is a failure to give sufficient attention to
the previously mentioned issue #1: error reporting
MUST work without fail.

In reply to comment #14, the "Sans" font _did_ exist
on the system reporting bug #163740; the OS kept its
side of the contract; the difficulty is that the
software calling for use of that font in an error
message box didn't cater for its being in bitmapped
format instead of TrueType format.

HTH

xanthian; yes, it's wordy. Cope; I'm not being paid
enough to make it terse.

And by the way, seen in the light of "issue #1 to
get right", the severity of this bug probably needs
to be increased to "critical" or whatever is the
next level up.

xanthian.

Thanks Robert for the debugging. BTW, what is it that marks recursive messsages
fatal in the first place? Maybe it's obvious in g_logv() but I don't see it.

Tor: It's these lines in gmessages.c, lines 420-425:

          if (depth)
            test_level |= G_LOG_FLAG_RECURSION;
          depth++;
          domain_fatal_mask = domain ? domain->fatal_mask : G_LOG_FATAL_MASK;
          if ((domain_fatal_mask | g_log_always_fatal) & test_level)
            test_level |= G_LOG_FLAG_FATAL;

g_log_always_fatal is set to G_LOG_FATAL_MASK by default, and G_LOG_FATAL_MASK
is (G_LOG_FLAG_RECURSION | G_LOG_LEVEL_ERROR).

By the way, to make the ugly workaround work with older pango as well, change
the fatal mask for the NULL domain as well:

  g_log_set_always_fatal (G_LOG_LEVEL_ERROR);
  g_log_set_fatal_mask ("Pango", G_LOG_LEVEL_ERROR); /* >= Pango 1.8 */
  g_log_set_fatal_mask (NULL, G_LOG_LEVEL_ERROR); /* Older */

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

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

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

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

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

Robert, do you suggest that we do the "ugly workaround" for GIMP 2.2.5? I'd
rather get rid of these crashes even if it means introducing this workaround in
GIMP even though it doesn't belong there in the first place.

There are many duplicates of this bug, so something should be done.

The downside of the workaround is if a non-fatal error occurs (in Pango or some
other component that logs to the NULL domain) during the handling of another
error, it will not be shown to the user as the fallback handler just prints it
to stdout/stderr which normally goes nowhere on Windows. Without the workaround
the application would be aborted, but the message would be shown to the user.

I suggest you use the workaround if you think this is an acceptable tradeoff.

One should take care not to break the --g-fatal-warnings flag if possible,
perhaps like this:

#ifdef G_OS_WIN32
  /* Workaround for bug #112401 - bringing up a GIMP error message dialog
   * can cause a recursed warning message from Pango, we don't want to abort */
  fatal_mask = g_log_set_always_fatal (G_LOG_FATAL_MASK);
  fatal_mask &= ~G_LOG_FLAG_RECURSION;
  g_log_set_always_fatal (fatal_mask);

  g_log_set_fatal_mask ("Pango", fatal_mask); /* >= Pango 1.8 */
  g_log_set_fatal_mask (NULL,    fatal_mask); /* Older Pango */
#endif G_OS_WIN32


Some ways I can think of to better fix the issue:
- Change the error handling logic in g_logv so that a recursed warning is not
considered fatal but a recursed error is
- Change Pango so it doesn't give warnings when a font cannot be found
- Change the "WIMP" (ms-windows) theme engine so it doesn't try to use bitmap fonts
- Add support for non-TrueType fonts in Pango on Win32 (bug #142579)

IMO the first option (change glib) would be easiest to do and would fix the
crash in the right location.

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

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

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

How do you get to the UI (on win98)?

Right-click on desktop -- Properties -- Appearance tab -- Click on the sample
window's title bar.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wow!  Waaaaaay so many dups.  Tor, any plan to fix this?

Hello, I think that the bug I found is very similar with this bug.
I use 
Gimp for Windows 2.2.10, 
GTK+ for Windows 2.8.9, 
OS is WinXP-SP2 Korean language edition.
I attach the error screen shot PNG image file.
After the message, Gimp terminates.
For Gimp for Windows 2.2.9, there was the same problem.
I tried a few older versions of Gimp and GTK+

Created attachment 64898 [details]
Error message screenshot PNG image for Gimp for Windows

This is the Error message screen shot.
It tells us that Pango module relation.

Created attachment 64899 [details]
Error message screenshot PNG image for Gimp for Windows

This is the Error message screen shot.
It tells us that Pango module relation.

Comment on attachment 64899 [details]
Error message screenshot PNG image for Gimp for Windows

DeleteMe attachment had wrongly duplicated.

Created attachment 64908 [details]
Making Picture with Creating Path

recreating error scene1

Created attachment 64909 [details]
remaking error scene2

after the first image as xcf format, and save as C format.
And re-read the C format file. Then, the error happens.

Created attachment 64910 [details]
the files that produced the error.

the files I ( and Gimp) made for the error.
Thanks in advance.

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

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

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

related to comment #42, could a patch be made to the win98/me version of GTK+ (gtk+-2.6.10-20050823-setup.exe)?  I am having the same 'Couldn't load font "MS Sans Serif 8" falling back to "Sans 8"' message box in the GIMP 2.2.10 when I create am image with text in it and try to save, which 2.2.10 is the only version available for win98/me.  it also crashes immediately afterwards and doesn't save the image..

> could a patch be made to the win98/me version of GTK+
> (gtk+-2.6.10-20050823-setup.exe)?

Sure, feel free to do that. It is all Free Software, you have the source code.

maybe I could try to piece things together, but the build process is not obvious.  I am not entirely used to NSIS or other such things.  I am just not that good of a developer yet with the Win32 API.  and it would need to be completely buildable with VS6 on an NT-family box.

If I were better I might take you up on it.

The only reason I'm requesting this is because as I repair pc's I keep running into people with win98/winme boxes that sometimes could use a good paint program like the GIMP, and that can't afford to get a new computer.
The executeable I mentioed is posted on WinGIMP as the win98/me version, and it's apparently quite broken.  the newer versions don't seem to have those  problems, but they are unfortunately NT-specific.

I won't say any more unless someone asks a question.

Is this one kept open for a reason?

I don't see a reason, no