Description of problem: Version-Release number of selected component: opencc-tools-1.1.7-2.fc41 Additional info: reporter: libreport-2.17.15 executable: /usr/bin/opencc rootdir: / kernel: 6.13.7-200.fc41.x86_64 journald_cursor: s=d85d4e6a420649199e9c9ed3c18b1efe;i=40b186;b=53a804a57e754aa181ae91e4d1e87479;m=27be71613e;t=6310b332142e5;x=9d6f8186c808ef6d cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-52c5034c-9c56-4e6f-9404-1835f17873aa.scope runlevel: N 5 uid: 1000 backtrace_rating: 4 cmdline: opencc -c s2t type: CCpp reason: opencc killed by SIGABRT package: opencc-tools-1.1.7-2.fc41 comment: crash_function: std::__throw_ios_failure Truncated backtrace: Thread no. 1 (10 frames) #8 std::__throw_ios_failure at ../../../../../libstdc++-v3/src/c++11/cxx11-ios_failure.cc:135 #9 std::basic_filebuf<char, std::char_traits<char> >::underflow at /usr/src/debug/gcc-14.2.1-7.fc41.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/fstream.tcc:473 #10 std::basic_streambuf<char, std::char_traits<char> >::sgetc at /usr/include/c++/14/streambuf:345 #12 std::istreambuf_iterator<char, std::char_traits<char> >::_M_get at /usr/include/c++/14/bits/streambuf_iterator.h:207 #13 std::istreambuf_iterator<char, std::char_traits<char> >::_M_at_eof at /usr/include/c++/14/bits/streambuf_iterator.h:214 #14 std::istreambuf_iterator<char, std::char_traits<char> >::equal at /usr/include/c++/14/bits/streambuf_iterator.h:200 #15 std::operator!=<char, std::char_traits<char> > at /usr/include/c++/14/bits/streambuf_iterator.h:244 #16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<std::istreambuf_iterator<char, std::char_traits<char> > > at /usr/include/c++/14/bits/basic_string.tcc:179 #17 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::istreambuf_iterator<char, std::char_traits<char> >, void> at /usr/include/c++/14/bits/basic_string.h:770 #18 opencc::Config::NewFromFile at /usr/src/debug/opencc-1.1.7-2.fc41.x86_64/src/Config.cpp:226 Potential duplicate: bug 2307731
Created attachment 2081564 [details] File: mountinfo
Created attachment 2081565 [details] File: maps
Created attachment 2081566 [details] File: backtrace
Created attachment 2081567 [details] File: cpuinfo
Created attachment 2081568 [details] File: limits
Created attachment 2081569 [details] File: dso_list
Created attachment 2081570 [details] File: core_backtrace
Created attachment 2081571 [details] File: proc_pid_status
Created attachment 2081572 [details] File: environ
Created attachment 2081573 [details] File: os_info
Created attachment 2081574 [details] File: open_fds
Ah, description of problem does not seem to include this - I did type most of this in the description above: I was running: echo '书剑恩仇录' | opencc -c s2t And that gives a message on the console: $ echo '书剑恩仇录' | opencc -c s2t terminate called after throwing an instance of 'std::__ios_failure' what(): basic_filebuf::underflow error reading the file: Is a directory Aborted (core dumped) using "-c s2tw" or "-c s2hk" succeed. abrt-cli report ... claims that https://bugzilla.redhat.com/show_bug.cgi?id=2307731 which was closed as insufficient data, might be a duplicate. Please check. It is possible. Hope this is better than the last time.
Interesting - doing that as root (in a separate window, after "su -", which dis-inherit env's) works; doing that as myself (the current gnome-shell login user) coredump. So it might be one of the GUI env variables. What env variable is opencc sensitive to?
Ha, I found the cause - It depends on what my current directory is. /tmp seems to be a problem i.e. cd /tmp echo '书剑恩仇录' | opencc -c s2t in both root or my user gives a coredump. if I do mkdir /tmp/a cd /tmp/a echo '书剑恩仇录' | opencc -c s2t command runs without problems. "opencc -c s2t" Argh, shit. I just realised. I have a /tmp/s2t directory in /tmp/ at the moment (just as a collection of recently converted files before I move them elsewhere)!!! So opencc -c is reading from the current directory and getting confused. It should read config from /usr/share/opencc/ rather than trying to read from current directory? I just did not expect config files to be read from current directory... I mean, "s2t" is really "/usr/share/opencc/s2t.json", as far as I understand it.
It is likely I was doing the same thing in https://bugzilla.redhat.com/show_bug.cgi?id=2307731 - i.e. in my current directory then, I had sub-directory "s2t". as in, I was probably having a s2t sub-directory, and doing "opencc -i name -o s2t/name -c s2t" at some stage.
I just created some pull request in OpenCC upstream. URL: https://github.com/BYVoid/OpenCC/pull/952
This bug is fixed in upstream and Fedora 43.