Created attachment 845427 [details]
File: backtrace

Created attachment 845428 [details]
File: cgroup

Created attachment 845429 [details]
File: core_backtrace

Created attachment 845430 [details]
File: dso_list

Created attachment 845431 [details]
File: environ

Created attachment 845432 [details]
File: exploitable

Created attachment 845433 [details]
File: limits

Created attachment 845434 [details]
File: maps

Created attachment 845435 [details]
File: open_fds

Created attachment 845436 [details]
File: proc_pid_status

Created attachment 845437 [details]
File: var_log_messages

0) Still reproducible with liferea-1.10.5-1.fc20.x86_64

1) I installed liferea-debuginfo, ran liferea from gdb and peeked and poked liferea a bit. It turns out this seems to be enough to work around this segmentation fault:

    l itemview_select_item
    break 188 if ivp->enclosureView == 0
    commands
    jump 193
    end
    r

Ie, set this conditional breakpoint:
    (gdb) info break
    Num     Type           Disp Enb Address            What
    1       breakpoint     keep y   0x0000000000441cbd in itemview_select_item 
                                                   at itemview.c:188
    	stop only if ivp->enclosureView == 0
	breakpoint already hit 1 time
        jump 193

2) See, somehow we end up with a NULL ivp->enclosureView in itemview_select_item(). I haven't investigated whether that means something went awry before or that we have to add a
    if (ivp->enclosureView) 

test here somewhere. To be continued, perhaps ...

I've filed an upstream report although I can't reproduce it.
https://sourceforge.net/p/liferea/bugs/1137/

(In reply to Yanko Kaneti from comment #13)
> I've filed an upstream report although I can't reproduce it.

Neither can I anymore. Now that I've passed this bump using gdb liferea runs just fine. Maybe there's still an item in one of the feeds that triggers this bug, maybe not. This might be hard to trigger from now on. We'll see...

(In reply to Paul Bolle from comment #14)
> Neither can I anymore.

0) The crash is back!

1) So let's look at the code I fiddled with when using gdb:

void
itemview_select_item (itemPtr item)
{
        [...]

        if (item)
                enclosure_list_view_load (ivp->enclosureView, item);
        else
                enclosure_list_view_hide (ivp->enclosureView);

        item_history_add (item->id);
}

But the "if (item)" test is bogus, because all callers of itemview_select_item() test for a non-NULL item beforehand. So that test will always evaluate to true. Moreover, if a NULL item would have been passed to this function we'd crashed at "item_history_add (item->id)" (NULL dereference).

2) So, it's quite likely the code should actually read:

void
itemview_select_item (itemPtr item)
{
        [...]

        if (ivp->enclosureView)
                enclosure_list_view_load (ivp->enclosureView, item);

        item_history_add (item->id);
}

Which is what my gdb breakpoint and command basically did.

3) Does upstream track updates to this report?

(In reply to Paul Bolle from comment #15) 
> 2) So, it's quite likely the code should actually read:
> 
> void
> itemview_select_item (itemPtr item)
> {
>         [...]
> 
>         if (ivp->enclosureView)
>                 enclosure_list_view_load (ivp->enclosureView, item);
> 
>         item_history_add (item->id);
> }
> 
> Which is what my gdb breakpoint and command basically did.

To which I should add that it's obviously wrong to call enclosure_list_view_load() with a NULL first argument (ie, to call it with a NULL ivp->enclosureView). So now I'm certain itemview_select_item() should be changed this way.

Unless, of course, this all indicates there's a more basic problem here. In that case someone may figure out how we can ensure itemview_select_item() isn't called while ivp->enclosureView is NULL.

Anyhow, in the mean time we have a clearly correct fix for a crash that seems to be regularly hit. Do I need to submit the trivial patch to - at least for the mean time - fix this in Fedora?

liferea-1.10.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/liferea-1.10.6-1.fc20

Package liferea-1.10.6-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing liferea-1.10.6-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3117/liferea-1.10.6-1.fc20
then log in and leave karma (feedback).

liferea-1.10.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.