Bug 2354375

Summary: [abrt] opencc-tools: std::__throw_ios_failure(): opencc killed by SIGABRT
Product: [Fedora] Fedora Reporter: Hin-Tak Leung <htl10>
Component: openccAssignee: Peng Wu <pwu>
Status: POST --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 41CC: htl10, pwu
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/222c54993280dc2e8133c927aa9ebff4404ac76
Whiteboard: abrt_hash:382560dcb837ac78dc165194b9bfa93ec68184d8;VARIANT_ID=workstation;
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: mountinfo
none
File: maps
none
File: backtrace
none
File: cpuinfo
none
File: limits
none
File: dso_list
none
File: core_backtrace
none
File: proc_pid_status
none
File: environ
none
File: os_info
none
File: open_fds none

Description Hin-Tak Leung 2025-03-23 23:58:37 UTC 
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
Comment 1 Hin-Tak Leung 2025-03-23 23:58:40 UTC 
Created attachment 2081564 [details]
File: mountinfo
Comment 2 Hin-Tak Leung 2025-03-23 23:58:41 UTC 
Created attachment 2081565 [details]
File: maps
Comment 3 Hin-Tak Leung 2025-03-23 23:58:43 UTC 
Created attachment 2081566 [details]
File: backtrace
Comment 4 Hin-Tak Leung 2025-03-23 23:58:44 UTC 
Created attachment 2081567 [details]
File: cpuinfo
Comment 5 Hin-Tak Leung 2025-03-23 23:58:45 UTC 
Created attachment 2081568 [details]
File: limits
Comment 6 Hin-Tak Leung 2025-03-23 23:58:46 UTC 
Created attachment 2081569 [details]
File: dso_list
Comment 7 Hin-Tak Leung 2025-03-23 23:58:47 UTC 
Created attachment 2081570 [details]
File: core_backtrace
Comment 8 Hin-Tak Leung 2025-03-23 23:58:49 UTC 
Created attachment 2081571 [details]
File: proc_pid_status
Comment 9 Hin-Tak Leung 2025-03-23 23:58:51 UTC 
Created attachment 2081572 [details]
File: environ
Comment 10 Hin-Tak Leung 2025-03-23 23:58:52 UTC 
Created attachment 2081573 [details]
File: os_info
Comment 11 Hin-Tak Leung 2025-03-23 23:58:53 UTC 
Created attachment 2081574 [details]
File: open_fds
Comment 12 Hin-Tak Leung 2025-03-24 00:05:35 UTC 
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.
Comment 13 Hin-Tak Leung 2025-03-24 00:12:37 UTC 
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?
Comment 14 Hin-Tak Leung 2025-03-24 00:37:12 UTC 
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.
Comment 15 Hin-Tak Leung 2025-03-24 00:39:58 UTC 
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.
Comment 16 Peng Wu 2025-03-25 06:41:34 UTC 
I just created some pull request in OpenCC upstream.

URL: https://github.com/BYVoid/OpenCC/pull/952