Segmentation Fault on execution

[Sufrostico]

The software (vifm 0.8.0) downloaded as sources from the vifm.info site; crashes (every time render it unusable) when executed due to a segmentation fault on my Debian installation.

After using the gdb to check for the error, the segmentation fault is presented in

    fileview.c line 355

        switch(view->dir_entry[pos].type)

due to dir_entry being null.

Backtrace:

(gdb) backtrace
#0  0x000000000044b69b in get_line_color (view=view@entry=0x6a96c0 <rwin>, pos=0) at fileview.c:355
#1  0x000000000044c31e in put_inactive_mark (view=0x6a96c0 <rwin>) at fileview.c:544
#2  0x0000000000429fc0 in redraw_lists () at ui/ui.c:866
#3  0x000000000040f2e1 in notify_option_update (opt=<optimized out>, val=..., op=OP_ON) at engine/options.c:732
#4  set_on (opt=0x6cf6b0) at engine/options.c:488
#5  process_option (arg=0x7fffffffbfd0 "sortnumbers") at engine/options.c:343
#6  set_options (args=0x6d076c "", args@entry=0x6d0761 "sortnumbers") at engine/options.c:279
#7  0x00000000004523ca in process_set_args (args=args@entry=0x6d0761 "sortnumbers") at opt_handlers.c:833
#8  0x0000000000407248 in read_info_file (reread=reread@entry=0) at cfg/info.c:129
#9  0x0000000000404ade in main (argc=<optimized out>, argv=<optimized out>) at vifm.c:165

[xaizek]

You're having options in vifminfo file and code is not ready for some consequences of that.

Are you doing this on purpose? (i.e. explicitly set 'vifminfo' option to have options.) I was going to remove some items from vifminfo in 0.8 (including options), but after experiencing inconvenience with incompatible changes in other software decided to keep things as is.

As for the issue, it seems to be old, judging from the code 0.6.3 might have it, so options probably not stored in vifminfo in most configurations.

Please use the patch below to fix 0.8 for you:

diff --git a/filelist.c b/filelist.c
index 0d378e5..d4635ea 100644
--- a/filelist.c
+++ b/filelist.c
@@ -172,7 +172,6 @@ init_view(FileView *view)
 static void
 init_flist(FileView *view)
 {
-   view->list_rows = 0;
    view->list_pos = 0;
    view->selected_filelist = NULL;
    view->history_num = 0;
@@ -186,6 +185,14 @@ init_flist(FileView *view)
    view->custom.entry_count = 0;
    view->custom.orig_dir = NULL;
    view->custom.title = NULL;
+
+   /* Load fake empty element to make dir_entry valid. */
+   view->dir_entry = calloc(1, sizeof(dir_entry_t));
+   view->dir_entry[0].name = strdup("");
+   view->dir_entry[0].type = FT_DIR;
+   view->dir_entry[0].hi_num = -1;
+   view->dir_entry[0].origin = &view->curr_dir[0];
+   view->list_rows = 1;
 }

 void
@@ -234,14 +241,6 @@ load_initial_directory(FileView *view, const char *dir)
        dir = view->curr_dir;
    }

-   view->dir_entry = calloc(1, sizeof(dir_entry_t));
-
-   view->dir_entry[0].name = strdup("");
-   view->dir_entry[0].type = FT_DIR;
-   view->dir_entry[0].hi_num = -1;
-   view->dir_entry[0].origin = &view->curr_dir[0];
-
-   view->list_rows = 1;
    if(!is_root_dir(view->curr_dir))
    {
        chosp(view->curr_dir);

[Sufrostico]

Hi,

You're having options in vifminfo file and code is not ready for some consequences of that.

Are you doing this on purpose? (i.e. explicitly set 'vifminfo' option to have options.) I was going to remove some items from vifminfo in 0.8 (including options), but after experiencing inconvenience with incompatible changes in other software decided to keep things as is.

Just checked, and yes. I have options in the vifmrc file

set vifminfo=options,dhistory,savedirs,chistory,state,tui,shistory,
    \phistory,fhistory,dirstack,registers,bookmarks

if options is removed, vifm won't crash.

As for the issue, it seems to be old, judging from the code 0.6.3 might have it, so options probably not stored in vifminfo in most configurations.

The previous version worked just fine.

$ vifm --version
Version: 0.7.7
Git commit hash: d340e30074ac2450679944814980e1a1181b6445
...

I'll try the patch, thanks

[xaizek]

The previous version worked just fine.

OK, thanks, then we can't make conclusions based on this behaviour. More recent changes just made the issue visible at least in this particular case of 'sortnumbers', which is a good thing overall.

And thanks for the bug report.

[xaizek]

As far as I can tell the patch works, so this can be closed.