From: LRN <lr...@gm...> - 2010-01-12 21:25:14
Attachments:
test.po
|
$ /mingw/bin/msgfmt -c --statistics -o test.gmo test.po ; echo $? 5 older msgfmt from gnuwin32 doesn't fail (just warns that older versions might give errors on files with fuzzy headers) .po file attached msgfmt doesn't fail without -c or --check-header msgfmt that i built myself failed too (althought it could be caused by one of the supporting libraries which i did not rebuild) Should i send that to gnu mailing list? |
From: Tor L. <tm...@ik...> - 2010-01-13 08:44:29
|
> Should i send that to gnu mailing list? Yes. Sounds to me as if msgfmt works as expected, as you tell it to check headers, so why are you then surprised that it does? How does the *same version* of msgfmt behave on a Unix system in the same situation? --tml |
From: LRN <lr...@gm...> - 2010-01-13 16:47:03
|
On 13.01.2010 11:44, Tor Lillqvist wrote: >> Should i send that to gnu mailing list? >> > Yes. OK, i will. > Sounds to me as if msgfmt works as expected, as you tell it to > check headers, so why are you then surprised that it does? Because: $ gdb --args /mingw/bin/msgfmt -c --statistics -o test.gmo test.po GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mingw32". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from %MINGWDISK%/mingw/bin/msgfmt.exe...(no debugging symbols found)...done. (gdb) r Starting program: %MINGWDISK%/mingw/bin/msgfmt.exe -c --statistics -o test.gmo test.po [New Thread 1848.0xc38] Error: dll starting at 0x77d40000 not found. Error: dll starting at 0x77d40000 not found. Error: dll starting at 0x77c20000 not found. Error while mapping shared library sections: %WINDIR%\SysWOW64\ntdll32.dll: No such file or directory. Program received signal SIGSEGV, Segmentation fault. 0x77bd8790 in strlen () from %WINDIR%\syswow64\msvcrt.dll (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x77bd8790 in strlen () from %WINDIR%\syswow64\msvcrt.dll (gdb) Continuing. Program exited with code 0200. I assume that this is not normal. > 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. It would be safe to assume that there is at least one person on Linux with msgfmt from gettext-0.17, who processes such files (it's not like gettext updates often...). At least, people were surprised when i mentioned that i have such problems. > --tml > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Tor L. <tm...@ik...> - 2010-01-13 20:05:59
|
> 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 |