Re: [Mingw-users] msgfmt fails on .po files with fuzzy headers

[Tor L. <tm...@ik...>]

> Program received signal SIGSEGV, Segmentation fault.
> 0x77bd8790 in strlen () from %WINDIR%\syswow64\msvcrt.dll
> (gdb) c

It might have been useful to do a "bt" here.

> >  How does the *same version* of msgfmt behave on a Unix system in the same situation?

> I'm not sure about the *same version*, but .po files in question (with
> fuzzy header) are supposedly processed without problems on Linux on
> regular basis.

Yeah, but Linux is not the only Unix out there;)

Still, when I run a test case with a fuzzy header in a .po file on
Linux, with msgfmt from gettext 0.17, it says:

msgfmt: (null): warning: PO file header fuzzy
                warning: older versions of msgfmt will give an error on this

The "(null)" is a sign that a NULL pointer was passed to one of the
printf family of functions for a %s format specifier. It's a "useful"
extension in glibc that it doesn't crash in this case.

In my opinion, this is a totally counter-productive extension, as it
means that programming errors don't get fixed, and the code then
crashes when run against other printf implementations that aren't
equally forgiving. It's not just Microsoft's C library that crashes
when a NULL pointer is passed for %s, many (most?) proprietary Unix C
libraries do it, too. But good luck convincing the glibc maintainer
(and the whole Linux community) to change it;)

Anyway, repeating the test on Windows, I got this backtrace:

(gdb) bt
#0  0x756a43f9 in strlen () from C:\Windows\syswow64\msvcrt.dll
#1  0x6382095c in int_vasprintf () from c:\opt\gnu\bin\libgettextlib-0-17.dll
#2  0x638184bc in xvasprintf () from c:\opt\gnu\bin\libgettextlib-0-17.dll
#3  0x638184f8 in xasprintf () from c:\opt\gnu\bin\libgettextlib-0-17.dll
#4  0x00401a4d in msgfmt_parse_debrief ()
#5  0x6f9029da in catalog_reader_parse () from
c:\opt\gnu\bin\libgettextsrc-0-17.dll
#6  0x00402483 in main ()

Which shows that in this case it isn't actually the system C library's
printf implementation that is used (as on Linux, where presumably
glibc is used), but gettext's own. The heart of gettext's own internal
printf() family (the int_vasprintf() seen in the backtrace) also
crashes if a NULL pointer is passed for %s. Looking in the source file
gettext-tools/gnulib-lib/vasprintf.c you see:

	    case 's':
	      total_width += strlen (va_arg (ap, char *));
	      break;

So please file a bug against gettext. Either its int_vasprintf()
(which actually is from "gnulib") should be as forgiving as glibc is,
or msgfmt should check for a char * being NULL before trying to pass
it for a %s format specifier.

(It is fairly likely that somebody else has already reported this,
though, from running msgfmt on Solaris or some other non-Linux Unix.)

--tml