invalid memory access / crash

[ossi]

mc crashes for me on startup. the backtrace indicates a memory corruption, just like the valgrind traces do:

Program received signal SIGABRT, Aborted.
#0 0x6ffe2424 in kernel_vsyscall ()
#1 0x6fcb0751 in *GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x6fcb3b82 in *GI_abort () at abort.c:92
#3 0x6fce722d in libc_message (do_abort=2, fmt=0x6fdab998 "* glibc detected * %s: %s: 0x%s *\n")

at ../sysdeps/unix/sysv/linux/libc_fatal.c:189

#4 0x6fcf1321 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>,

ptr=0x81b2ce2) at malloc.c:6267

#5 0x6fcf2b78 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4795
#6 0x6fcf5c5d in *GI_libc_free (mem=0x81b2ce2) at malloc.c:3739
#7 0x6fe29c56 in g_free () from /lib/libglib-2.0.so.0
#8 0x080aeec2 in str_8bit_release_key (key=0x81b2ce2 "", case_sen=0) at strutil8bit.c:777
#9 0x0809b670 in str_release_key (key=0x81b2ce2 "", case_sen=0) at strutil.c:779
#10 0x0807d866 in clean_sort_keys (list=0x81abc38, sort=0x807dfa8 <sort_name>, top=45, reverse_f=0,

case_sensitive_f=0, exec_first_f=0) at dir.c:218

#11 do_sort (list=0x81abc38, sort=0x807dfa8 <sort_name>, top=45, reverse_f=0, case_sensitive_f=0,

exec_first_f=0) at dir.c:245

#12 0x0807dea3 in do_load_dir (path=0x81abc48 "/usr/local/src/mc-new", list=0x81abc38,

sort=0x807dfa8 <sort_name>, lc_reverse=0, lc_case_sensitive=0, exec_ff=0, fltr=0x0) at dir.c:457

#13 0x08068ef1 in panel_new_with_dir (panel_name=0x80e7c11 "New Left Panel", wpath=0x0) at screen.c:1399
#14 0x08068f2a in panel_new (panel_name=0x80e7c11 "New Left Panel") at screen.c:1313
#15 0x0808b21f in set_display_type (num=0, type=view_listing) at layout.c:953
#16 0x0808c98f in create_panels () at main.c:981
#17 0x0808dea2 in create_panels_and_run_mc (argc=1, argv=0x77fff854) at main.c:1863
#18 do_nc (argc=1, argv=0x77fff854) at main.c:1961
#19 main (argc=1, argv=0x77fff854) at main.c:2211

==30608== Invalid read of size 4
==30608== at 0x42AF57B: GI_strlen (strlen.S:115)
==30608== by 0x425CE2F: setlocale (setlocale.c:332)
==30608== by 0x808D95B: main (main.c:2103)
==30608== Address 0x45d109c is 4 bytes inside a block of size 6 alloc'd
==30608== at 0x4023B82: malloc (vg_replace_malloc.c:195)
==30608== by 0x42AF1EF: strdup (strdup.c:43)
==30608== by 0x425E42A: _nl_load_locale_from_archive (loadarchive.c:460)
==30608== by 0x425D336: _nl_find_locale (findlocale.c:107)
==30608== by 0x425CD08: setlocale (setlocale.c:303)
==30608== by 0x808D95B: main (main.c:2103)

==30608== Invalid read of size 8
==30608== at 0x42AF4E0: strlen_sse2 (strlen.S:99)
==30608== by 0x4183A94: g_build_path (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x80A8C1A: extfs_get_plugins (extfs.c:1433)
==30608== by 0x80A8EAB: extfs_init (extfs.c:1535)
==30608== by 0x8096A73: vfs_register_class (vfs.c:189)
==30608== by 0x80A6F4D: init_extfs (extfs.c:1614)
==30608== by 0x80989BE: vfs_init (vfs.c:1337)
==30608== by 0x808DA50: main (main.c:2114)
==30608== Address 0x45ddbc8 is 0 bytes after a block of size 16 alloc'd
==30608== at 0x4023C77: realloc (vg_replace_malloc.c:476)
==30608== by 0x419CC9E: g_realloc (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41B7BDE: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41B8757: g_string_insert_len (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41B8AF7: g_string_append_len (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41837CC: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x4183A94: g_build_path (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x80A8E9F: extfs_init (extfs.c:1534)
==30608== by 0x8096A73: vfs_register_class (vfs.c:189)
==30608== by 0x80A6F4D: init_extfs (extfs.c:1614)
==30608== by 0x80989BE: vfs_init (vfs.c:1337)
==30608== by 0x808DA50: main (main.c:2114)

==30608== Invalid read of size 8
==30608== at 0x42AF4E0: strlen_sse2 (strlen.S:99)
==30608== by 0x418F708: g_key_file_get_string (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x80B2B72: mc_config_get_string (get.c:102)
==30608== by 0x8073CC3: load_setup (setup.c:767)
==30608== by 0x808DB25: main (main.c:2153)
==30608== Address 0x468da10 is 0 bytes inside a block of size 1 alloc'd
==30608== at 0x4023B82: malloc (vg_replace_malloc.c:195)
==30608== by 0x419CED3: g_malloc (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41B5768: g_strdup (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x418CFB4: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x41901D0: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x4190786: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x4190968: ??? (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x419101A: g_key_file_load_from_file (in /lib/libglib-2.0.so.0.2400.1)
==30608== by 0x80B2796: mc_config_init (common.c:122)
==30608== by 0x8073B15: load_setup (setup.c:738)
==30608== by 0x808DB25: main (main.c:2153)

there is half a megabyte more, but i have no time now.

[andrew_b]

mc -V ?

[ossi]

GNU Midnight Commander 4.7.2-195-gf273138
Virtual File Systems: tarfs, extfs, cpiofs, ftpfs, fish, smbfs
With builtin Editor
Using system-installed S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With multiple codepages support
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

[andrew_b]

Replying to ossi:

#10 0x0807d866 in clean_sort_keys (list=0x81abc38, sort=0x807dfa8 <sort_name>, top=45, reverse_f=0,

case_sensitive_f=0, exec_first_f=0) at dir.c:218

I wonder why I can't find such function. The clean_sort_keys function is

    212 static void
    213 clean_sort_keys (dir_list *list, int start, int count)

[slyfox]

looks more like

src/dir.c:do_sort (dir_list *list, sortfn *sort, int top, int reverse_f, int case_sensitive_f, int exec_first_f)

[ossi]

the line numbers may be off due to local patches.
anyway ... i bisected it down to 7757527.

[ossi]

fix it!

[andrew_b]

I didn't mean line numbers. I meant arguments of clean_sort_keys().

[andrew_b]

Created 2249_mc_crash branch. Parent branch is master.
changeset:807ccb469c263899fc0a4366d71e07a102108124

[andrew_b]

Merged to master.
changeset:807ccb469c263899fc0a4366d71e07a102108124

[andrew_b]

Must be applied to 4.7.0-stable after #2085.

[zaytsev]

I don't like the proposed solution. Could somebody please explain me why we have to reinvent the wheel with the very own strdown function, while there's an 8-bit g_ascii_strdown function in Glib, and we already use g-ascii-strup where appropriate?

​http://library.gnome.org/devel/glib/stable/glib-String-Utility-Functions.html#g-ascii-strdown

[andrew_b]

Replying to zaytsev:

Could somebody please explain me why we have to reinvent the wheel with the very own strdown function, while there's an 8-bit g_ascii_strdown function in Glib

As described, g_ascii_strdown convertes all the upper case characters to lower case, with semantics that exactly match g_ascii_tolower().

g_ascii_tolower, unlike the standard C library tolower() function, only recognizes standard ASCII letters and ignores the locale, returning all non-ASCII characters unchanged, even if they are lower case letters in a particular character set.

Therefore g_ascii_tolower() cannot be used in 8-bit locales. Look at the code:

gchar
g_ascii_tolower (gchar c)
{
  return g_ascii_isupper (c) ? c - 'A' + 'a' : c;
}

and we already use g-ascii-strup where appropriate?

g-ascii-strup() is used only in lib/vfs/mc-vfs/ftpfs.c during login to FTP-server. I hope that reply of FTP-server is ASCII-only. No?

[zaytsev]

Aha, now I get it. We need it to work correctly on other 8-bit locales than C. Many thanks for the detailed explanation.

I hope that reply of FTP-server is ASCII-only. No?

Yes, you are right. This is specified in the protocol.