Segfaulting on OSX
jasperbok opened this issue · 17 comments
I compiled mtm with CURSESLIB=curses and whenever I run it, it segfaults.
If I compile with debugging info and run it the following backtrace is what lldb shows me:
* thread #1: tid = 0xf377c7, 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x58)
* frame #0: 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237
frame #1: 0x00007fff91c9b4d1 libncurses.5.4.dylib`wrefresh + 68
frame #2: 0x0000000100001927 mtm`doripoff(w=0x0000000100201770, i=<unavailable>) + 39 at mtm.c:853 [opt]
frame #3: 0x00007fff91c9cf49 libncurses.5.4.dylib`_nc_setupscreen + 1610
frame #4: 0x00007fff91c995a6 libncurses.5.4.dylib`newterm + 191
frame #5: 0x00007fff91c96581 libncurses.5.4.dylib`initscr + 83
frame #6: 0x0000000100001b80 mtm`main(argc=<unavailable>, argv=<unavailable>) + 592 at mtm.c:894 [opt]
frame #7: 0x00007fff8a5a75ad libdyld.dylib`start + 1
frame #8: 0x00007fff8a5a75ad libdyld.dylib`start + 1
Don't know how useful this is? I just started learning C the other day, so I can't really imagine what you'd need :) If you need anything else, please tell me :)
Hi @boterpoes
Please try the latest code in master. It probably won't fix the issue, but it should hopefully tell you why it's segfaulting. Please let me know what happens. Thanks.
Ok, I tried the latest code, and get some strange behavior. mtm now works when I run it from within a tmux session, but not when ran from a bare shell. It crashes on the exact same point as in my post above :(
Checking out your code changes, I'd expect to see an error message when it crashes, but it simply says segfault: 11.
Hi @boterpoes
Two things to try. I don't have a Mac, so I can't try them myself. :)
- You're running the master branch, right? There's a bug in ncurses that's tickled by the "sun-color" branch, so if you're using the "sun-color" branch, please switch back to master.
- Does macOS differentiate between ncurses and ncursesw? Please try linking against ncursesw and not ncurses (or vice versa, depending on how macOS does it).
Hey @deadpixi :)
I'm definitely using the master branch, so no problems there.
After Googling around, it appears that OSX comes with a curses library that handles wide characters by default, but does not explicitly provide an ncursesw lib. Thus, trying to link against ncursesw fails as expected.
I searched MacPorts for ncurses, but it doesn't seem to provide an ncursesw version. If you think it might help I could try to built it from source and link it? That would be tomorrow, though, as it is already past bedtime for me ;)
mtm should work with the default macOS curses implementation; I wouldn't want to mess with getting ncurses on there.
It looks like it's failing during setup and I'm wondering if it's because of a missing terminfo entry. Could you compile mtm as you were, and then call it like this:
mtm -T ansi
And see what happens? Thanks.
Works like a charm!
@boterpoes That's really interesting.
When you're not in mtm, but just your regular shell, what does
echo $TERM
show?
xterm-256color is what it says :)
Thanks a lot for your help by the way! I was editing my reply above but saw you already replied again :)
What's weird is that implies that somehow ncurses can't find a terminfo entry for xterm-256color, which I would imagine is almost certainly present.
Either way, I'll fix it so it doesn't crash, but I can't imagine that macOS doesn't have a terminfo DB entry for that terminal...
@boterpoes can you run the tack command outside of mtm and tell me what it says on the "Using terminfo from" line? Thanks.
That command doesn't exist … Googling around for it also doesn't yield much. Macports doesn't seem to have it either. Googling for "tack linux equivalent osx" also doesn't find any relevant pages. I also can't find anything that seems equivalent using apropos … Not going to be of any help here, it seems :(
@boterpoes Looking around, it would appear as though Apple doesn't ship a terminfo entry for that. How surprising.
So yeah, just do
mtm -T xterm
and things should just work.
Would you mind testing the latest code in master without the "-T xterm" part and see if it fails cleanly? Thanks again.
If you meant mtm -T ansi then yeah, it seems to work pretty much (though I'm having some trouble with vim inside mtm). mtm -T xterm segfaults, as does mtm (without -T), no clean failing as of yet.
$ git pull
$ make clean
$ make CURSESLIB=curses
$ ./mtm
Segmentation fault: 11
$ ./mtm -T xterm
Segmentation fault: 11
$ ./mtm -T ansi
# works
Hi @jasperbok
I'm beginning to wonder if there's a bug in macOS's curses implementation. mtm actually found one in ncurses. :)
Would you mind compiling mtm like this:
make CFLAGS=-g clean all
And then running mtm -T xterm with lldb and letting me know what it reports?
Thank you.
Also, please let me know what trouble you're having with vim inside mtm.
Ok so I did the following (just stating exactly what I did in case I did something wrong):
$ lldb ./mtm
(lldb) process launch -- -T xterm
Then lldb outputs the following:
* thread #1: tid = 0x1246191, 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x58)
frame #0: 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237
libncurses.5.4.dylib`doupdate:
-> 0x7fff91ca748d <+237>: andl 0x58(%rdx), %ebx
0x7fff91ca7490 <+240>: movswl 0x70(%rax), %edx
0x7fff91ca7494 <+244>: movq (%r14), %rsi
0x7fff91ca7497 <+247>: movswl 0x4(%rsi), %r14d
The backtrace looks as follows:
(lldb) thread backtrace
* thread #1: tid = 0x1246191, 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x58)
* frame #0: 0x00007fff91ca748d libncurses.5.4.dylib`doupdate + 237
frame #1: 0x00007fff91c9b4d1 libncurses.5.4.dylib`wrefresh + 68
frame #2: 0x0000000100001e62 mtm`doripoff(w=0x00000001002018a0, i=193) + 66 at mtm.c:856
frame #3: 0x00007fff91c9cf49 libncurses.5.4.dylib`_nc_setupscreen + 1610
frame #4: 0x00007fff91c995a6 libncurses.5.4.dylib`newterm + 191
frame #5: 0x00007fff91c96581 libncurses.5.4.dylib`initscr + 83
frame #6: 0x0000000100002071 mtm`main(argc=3, argv=0x00007fff5fbff0f8) + 513 at mtm.c:897
frame #7: 0x00007fff8a5a75ad libdyld.dylib`start + 1
frame #8: 0x00007fff8a5a75ad libdyld.dylib`start + 1
As for the vim trouble, I'm not entirely sure whether this is a problem with mtm itself, or that it is vim having a problem with a different terminal environment. I made a gif to clarify:
What I notice are the following things:
- When starting, mtm draws my prompt next to the mtm title.
- While pressing enter, mtm draws my cursor at a wrong position.
- After running a command, mtm gets the cursor position right.
- Vim's initial window doesn't seem to have any linebreaks (the blue tildes are normally each at a separate line, and vim's status bar is drawn after the tildes, while it should be at the bottom of the screen).
- Inserting text works as expected, but when navigating the wrong lines are drawn at my cursor position.
- The line numbers are drawn correctly, though. I guess vim doesn't redraw then until I start navigation the file, which may explain why they aren't affected?
I guess the line numbers are only redrawn when moving around the file, but I'm not sure how this is implemented.
Another thing to note is that when I start mtm, at first it doesn't know where to put my cursor, and if I keep pressing enter, it will keep using the wrong position. Then when I run a command it suddenly gets the position right :)
on mac os x compiling
$ make CURSESLIB=curses CFLAGS=-g clean all
and running $ ./mtm -T xterm
bash-3.2$ ls
Makefile config.def.h mtm mtm.c mtm.ti screenshot2.png vtparser.h
README.rst config.h mtm.1 mtm.dSYM screenshot.png vtparser.c
bash-3.2$
bash-3.2$
bash-3.2$ mc
Error opening terminal: eterm-color.
bash-3.2$
normaly mc run ok.
You'll need to install the terminfo for eterm-color or for mtm; see the documentation here on how to install the mtm terminfo.
Closing this ticket since it hasn't seen any movement since April. Anyone feel free to reopen it if things still don't work on OSX.