#186 Seg Faults when x-sjis chars given as search string

closed-fixed
None
7
2003-07-05
2003-03-19
No

I was trying to see if I could find some info on a
Japanese band, and tried cutting and pasting this
phrase (which I think is the band name) as a search
string とは 一体なにか

Each time after I paste this in, and hit return, I get
a segmentation fault.

I tried a couple other x-sjis strings and they all seg
faulted. Other wide charsets didn't (although I only
tried a few)

I am running gtk-gnutella 0.92b2 on Redhat 7.3

ps. I know wide character support isn't a listed
feature or anything, but I assumed that if gtk-gnutella
couldn't handle it, it would just echo a gobbledy-gook
search string (which it does with other wide char
formats) I'm only posting this bug because of the seg
fault.

Discussion

  • Raphael Manfredi

    Logged In: YES
    user_id=13887

    Can you show the stack trace? (make sure you recompile with -g)

     
  • Raphael Manfredi

    • priority: 5 --> 7
     
  • Jeremy Bauer

    Jeremy Bauer - 2003-03-19

    Logged In: YES
    user_id=708648

    I recompiled it with -g and ran it from within gdb. The
    last thing it said before it died was:

    ** ERROR **: file zalloc.c: line 170 (zfree): assertion
    failed: (zone->zn_cnt > 0)
    aborting...

    Program received signal SIGABRT, Aborted.
    0x42029331 in kill () from /lib/i686/libc.so.6

    the stack backtrace resulted in:

    #0 0x42029331 in kill () from /lib/i686/libc.so.6
    #1 0x4202911a in raise () from /lib/i686/libc.so.6
    #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6
    #3 0x401a809c in g_logv () from /usr/lib/libglib-1.2.so.0
    #4 0x401a8147 in g_log () from /usr/lib/libglib-1.2.so.0
    #5 0x080f7bb1 in zfree (zone=0x847d450, ptr=0xbfffced8) at
    zalloc.c:170
    #6 0x080c83eb in _search_send_packet (sch=0x8871878, n=0x0)
    at search.c:962
    #7 0x080c8714 in search_send_packet (sch=0x8871878) at
    search.c:1075
    #8 0x080c8f6c in search_start (sh=6) at search.c:1515
    #9 0x080a47af in search_gui_new_search_full
    (querystr=0x8871790 "????????",
    speed=0, reissue_timeout=600, flags=0, search=0xbfffd218)
    at search_gui.c:622
    #10 0x080a431f in search_gui_new_search (query=0x8871790
    "????????", flags=0,
    search=0xbfffd218) at search_gui.c:451
    #11 0x080a716d in on_button_search_clicked (button=0x0,
    user_data=0x0)
    at search_cb.c:205
    #12 0x400c2d91 in gtk_marshal_NONE__NONE () from
    /usr/lib/libgtk-1.2.so.0
    #13 0x400f63e6 in gtk_handlers_run () from
    /usr/lib/libgtk-1.2.so.0
    #14 0x400f571d in gtk_signal_real_emit () from
    /usr/lib/libgtk-1.2.so.0
    #15 0x400f34d5 in gtk_signal_emit () from
    /usr/lib/libgtk-1.2.so.0
    #16 0x4012dc90 in gtk_widget_activate () from
    /usr/lib/libgtk-1.2.so.0
    #17 0x400967d8 in gtk_entry_key_press () from
    /usr/lib/libgtk-1.2.so.0
    #18 0x400c2a9c in gtk_marshal_BOOL__POINTER () from
    /usr/lib/libgtk-1.2.so.0

    The actual byte string that causes the segfault is:
    130 198 130 205 129 64 136 234 145 204 130 200 130 201 130 169
    although I tried several x-sjis strings and they all
    segfaulted, this is the first one I found.
    I don't know anything about wide character encodings, but
    this is supposed to be 8
    characters here, so it looks like a pretty simple 16 bit
    character set. When I tried to
    replicate the segfault from an EU-JP encoded string of text,
    I just got the expected
    nonsense string. Apparently ony certain kinds of input will
    make it crash.

    I cut and pasted the string from mozilla. I don't know if
    it matters, but I am running
    openbox as my window manager, and have both KDE an gnome
    installed, so if the fault
    lies in the clipboard between gtk-gnutella and mozilla, or
    if the fault just lies in the way
    mozilla loads the string into the clipboard in the first
    place... I don't know. I have no
    idea how cutting and pasting work under X. I did putthe
    string in question into a file,
    opened it in KWrite, and pasted it into gtk-gnutella, and
    the result was an 8 character
    string of nonsense "@ɩ" but no crash, so I guess
    different applications have
    different ways of handling multibyte strings and the clipboard.

     
  • Christian Biere

    Christian Biere - 2003-03-23

    Logged In: YES
    user_id=643728

    Which locale settings do you use?
    What's the output of "env|grep LC_"?

     
  • Jeremy Bauer

    Jeremy Bauer - 2003-03-23

    Logged In: YES
    user_id=708648

    Nothing. I have no locale enviornment variables set.

     
  • Stephane Corbe

    Stephane Corbe - 2003-06-02

    Logged In: YES
    user_id=317529

    Jeremy, I have one box with Redhat 7.3 too,
    I tried the string that you give with a french, an english and a
    japanese account and never gtk-gnutella crash.

    Is it the same with EUC encoding for you ?

    Can you show us the ouput of a ldd on the executable and your env,
    please ?

     
  • Raphael Manfredi

    Logged In: YES
    user_id=13887

    Fixed in CVS. It was a duplicate free problem.

     
  • Raphael Manfredi

    • assigned_to: nobody --> rmanfredi
    • status: open --> closed-fixed
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks