| Summary: | hexedit crashes with ncurses | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Nicolas Pomarède <npomarede> |
| Component: | RPM Packages | Assignee: | All Packagers <pkg-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | anaselli, ouaurelien, pterjan |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | ncurses-6.0-2.mga6.i586.rpm | CVE: | |
| Status comment: | |||
Assigning to packagers collectively as neither ncurses nor hexedit have an official maintainer right now. Assignee:
bugsquad =>
pkg-bugs I updated ncurses to a newer snapshot after this report was filed, please advise if the bug is still valid. Summary:
hexedit crashes with ncurse =>
hexedit crashes with ncurses Hi problem still there with ncurses-6.0-3.mga6. Same crash with same backtrace. Nicolas (In reply to Nicolas Pomarède from comment #0) > (gdb) print oline->text[src_col] > value has been optimized out > (gdb) print oline->text > $4 = (chtype *) 0x0 > As can be seen, src_col can't be printed, so maybe we have an access beyond > the memory allocated to oline->text (which points to an empty string, so out > of limit access is quite likely) > > hmm to be honest, it seems more in oline->text the problem, since it is null and the instruction oline->text[src_col] is illegal CC:
(none) =>
anaselli Hi while inadvertently using hexedit as root on the same machine, I noticed that I got no segfault in that case and everything worked fine. segfault happens only when using my own user account. Is there a config file for ncurse in my own directory that should be removed ? Any idea on what could conflict with my user account ? (I have the same problem on 2 cauldron PC, both having different user settings) Nicolas It seems I found a cause for the segfault ; after reading https://github.com/hishamhm/htop/issues/241 , some problem were mentionned regarding character encoding. In my case, I use KDE and konsole which is set to unicode / utf8 encoding. By default, I have TERM=xterm. If I run : TERM=linux hexedit file.txt -> it works, no crash but TERM=xterm hexedit file.txt -> crash, segfault I don't know if the problem is UTF8 related, but at least it seems linked to the TERM used. I still can't reproduce with TERM=xterm but I am not under X. CC:
(none) =>
pterjan This was against Mageia 6 era. Does this still valid? CC:
(none) =>
ouaurelien didn't see the problem with mageia 7 or 8/cauldron, might be fixed in updated curses lib. bug can be closed I think (In reply to Nicolas Pomarède from comment #9) > didn't see the problem with mageia 7 or 8/cauldron, might be fixed in > updated curses lib. > bug can be closed I think Status:
NEW =>
RESOLVED |
Hi when opening a file with hexedit, I get a seg fault under cauldron 32 bit. packages used : hexedit-1.2.13-6.mga6 ncurses-6.0-2.mga6 ncurses-debuginfo-6.0-2.mga6 This is the result from gdb : Program received signal SIGSEGV, Segmentation fault. wnoutrefresh (win=0x806a918) at ../../ncurses/base/lib_refresh.c:258 258 if (!CharEq(oline->text[src_col], nline->text[dst_col])) { (gdb) bt #0 wnoutrefresh (win=0x806a918) at ../../ncurses/base/lib_refresh.c:258 #1 0xb7fa3f12 in wrefresh (win=0x806a918) at ../../ncurses/base/lib_refresh.c:62 #2 0xb7f9cf11 in recur_wrefresh (win=win@entry=0x806a918) at ../../ncurses/base/lib_getch.c:384 #3 0xb7f9d107 in _nc_wgetch (win=0x806a918, result=0xbfffeb7c, use_meta=1) at ../../ncurses/base/lib_getch.c:491 #4 0xb7f9ddf6 in wgetch (win=0x806a918) at ../../ncurses/base/lib_getch.c:672 #5 0x080491f3 in main () (gdb) print nline $1 = (struct ldat *) 0x8058338 (gdb) print nline->text[dst_col] $2 = 32 (gdb) print oline $3 = (struct ldat *) 0x806a980 (gdb) print oline->text[src_col] value has been optimized out (gdb) print oline->text $4 = (chtype *) 0x0 (gdb) print src_col $5 = <optimized out> (gdb) print dst_col $6 = 0 As can be seen, src_col can't be printed, so maybe we have an access beyond the memory allocated to oline->text (which points to an empty string, so out of limit access is quite likely) Reproducible: Steps to Reproduce: