Re: [Pan-users] Bug 756458 pan 0.139 crashes on start

[Zan Lynx]

On January 5, 2016 12:12:19 PM MST, Detlef Graef <address@hidden> wrote:
>Am 29.12.2015 um 03:39 schrieb Duncan:
>
>> Detlef Graef posted on Mon, 28 Dec 2015 15:53:59 +0100 as excerpted:
>> 
>>> I've some update to this bug:
>>>
>>> https://bugzilla.gnome.org/show_bug.cgi?id=756458
>>>
>>> I've done some (very simple) debugging.
>>>
>>> At startup Pan reads the value from the string "last-visited-group"
>from
>>> the preferences.xml file. Due to the new ABI it doesn't work as
>>> expected.
>> 
>> While I understand you're actually working on a proper patch, not
>just a 
>> workaround, and thanks for that, I can say that the suggested
>workaround, 
>> building pan with -D_GLIBCXX_USE_CXX11_ABI=0 in CXXFLAGS, seems to
>work 
>> well enough here -- I'm using pan (from git so it already has the
>current 
>> dir fix of bug 754698) built with gcc 5.3.0 and that in my CXXFLAGS
>here 
>> on gentoo, to type this reply, and haven't seen any bugs from the
>gcc5 
>> rebuild yet. =:^)
>> 
>> But getting the bugs actually fixed so CXX11_ABI could be used would 
>> indeed be a good thing. =:^)
>
>I think fixing the source is the best solution.
>
>I think the problem is in the file prefs.cc at this place:
>
>/***
>****  STRINGS
>***/
>
>std::string
>Prefs :: get_string (const StringView& key, const StringView& fallback)
>const
>{
>  if (!_strings.count (key))
>    _strings[key] = fallback;
>  return _strings[key];
>}
>
>When I look at the diff from the patch for "get_pan_home()":
>
>https://bugzilla.gnome.org/attachment.cgi?id=310852&action=diff
>
>it looks similar to me.
>
>The function above is invoked at least with these keys:
>
>prefs.cc key: header-pane-show-matching
>prefs.cc key: header-pane-columns
>prefs.cc key: body-pane-font
>prefs.cc key: pane-layout
>prefs.cc key: pane-orient
>prefs.cc key: last-visited-group
>
>
>At the moment I don't know if the problem can be fixed in a similar way
>as the patch for "get_pan_home()" does.

Returning a reference to an internal map and then taking c_str is the wrong 
thing to do. What happens if it is an unordered map and it recalculates its 
hash buckets?

It should return a string and keep the string, not assign it as a C char*.