#17 Crash in magick/utility.c:LocaleCompare()

closed-fixed
None
5
2010-02-17
2010-02-17
No

GraphicsMagick crashes in LocaleCompare when working with files which names contains non-English (in my case, Russian) letters. I've firstly noticed it with 1.3.8, but 1.3.10 crashes as well. I've done some investigation and discovered that LocaleCompare() and LocaleNCompare() (and all other functions for processing the character sequences) work with pointers to char, while char type is signed in many platforms by default. Quick and dirty solution is to replace char with unsigned char.
I wonder whether all char sequences processing functions in magick/utility.c should work with unsigned char instead of char.
I use x86_64 platform if it matters. I currently cannot test if it fails on x86.

Steps to repruduce:
1. % gm identify test.png
test.png PNG 320x240+0+0 DirectClass 16-bit 1.3K 0.000u 0:01
2. % gm identify проверка.png
zsh: segmentation fault (core dumped) gm identify проверка.png

Backtrace and test files are to come.

Discussion

  • - 2010-02-17

    % gdb $(which gm) -core=core --batch --quiet -ex "thread apply all bt full" -ex "quit" > backtrace.txt

     
  • - 2010-02-17

    Attached backtrace is probably useless, but test shows that the patch addresses guilty code correctly.

     
  • - 2010-02-17

    Simple image file which name consists of Latin letters only

     
  • - 2010-02-17

    cp test.png проверка.png

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17

    What type of OS and filesystem are you using? When I go to save your russian-named file in the web browser, the filesystem only shows ? for the extended characters. This makes it difficult to test.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17

    Ok, I am able to reproduce this on AMD_64 Linux.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17
    • assigned_to: nobody --> bfriesen
    • status: open --> open-accepted
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17

    Smaller patch I decided to use.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17

    Thank you very much for your bug report. I decided to use a smaller patch (attached as a file) which only addresses the specific underflow problem. The various ANSI C function interfaces all use 'char *' so it is too invasive to try to use 'unsigned char *' everywhere that character data can appear.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17
    • status: open-accepted --> open-fixed
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2010-02-17
    • status: open-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks