search

fcitx / libime

40 stars 21 forks source link

testpinyindictionary segfault with boost 1.81.0 #40

Closed sgn closed 1 year ago

sgn commented 1 year ago

The segfault caused by nullptr-dereference in line 381

https://github.com/fcitx/libime/blob/e199ce44fd85b86e0a906819fa93d4fadda3a2ca/src/libime/pinyin/pinyindictionary.cpp#L376-L381

libime finds the path by Compatible{Key,Hash,Predicate}: https://github.com/fcitx/libime/blob/e199ce44fd85b86e0a906819fa93d4fadda3a2ca/src/libime/core/lrucache.h#L75-L80 but the insert check by key_type: https://github.com/fcitx/libime/blob/e199ce44fd85b86e0a906819fa93d4fadda3a2ca/src/libime/core/lrucache.h#L43-L44

wengxt commented 1 year ago

This is called heterogeneous lookup. You can do the look up without create an actual key type.

I think the key issue is that boost changes the way it hashes std::string, that breaks the assumption of hasher.

sgn commented 1 year ago

Their release notes seems to indicate there is a major change in Boost.Unordered.

wengxt commented 1 year ago

I'd suggest it's about boost::hash specifically.

wengxt commented 1 year ago

I can see there's a major update of "container hash" in 1.81. I guess that changes how hash against std::string works.

The fix should be use our own string hash implementation to we won't be break by upstream change in the future.

@sgn can you check if master fixes the issue?

sgn commented 1 year ago

Yes, the change fixed libime for boost 1.81.0